Жизненный цикл CTO
Startup Coder → Engineering Manager → All-in-one → разделение роли
Leadership
Когда использовать
Когда нужно договориться, какой CTO нужен компании на текущей фазе роста.
В исходной модели жизненный цикл организации состоит из пяти этапов. На старте CTO — Startup Coder; на росте — Engineering Manager; при формализации появляется All-in-one CTO; при усложнении структуры эта роль разделяется на CIO, CTO и VP Engineering. На этапе спада доклад не назначает новую роль CTO.
Channel → Product → Platform
Эволюция большого финтеха в три такта
PlatformArchitecture
Когда использовать
Когда продуктовая и платформенная стратегии начинают конфликтовать из-за разной фазы эволюции.
Таймлайн кейса начинается с основания компании в 2006 году и интернет-банка в 2008-м. В 2011-м мобильный банк появляется как дополнительный канал, в 2015-м становится самостоятельным продуктом, в 2019-м — платформой, а 2022-й ставит вопрос о следующем переходе.
Senior+ развилка
Management-ветка vs IC-ветка
Leadership
Когда использовать
Когда инженер выбирает следующий шаг после Senior, а компания проектирует двойную карьерную лестницу.
После Senior карьера может разделиться на management- и IC-ветку. Leadership в исходной схеме обозначает переход к управлению, а не отдельный грейд. Конкретные ступени — Engineering Manager или Director, Staff или Principal — зависят от оргдизайна и не образуют универсальную лестницу.
Engineering Productivity
DORA + DevEx + SPACE — три линзы одной картины
ProductivityLeadership
Когда использовать
Когда разговор о продуктивности разработки надо вывести из одного счётчика в систему метрик.
DORA, DevEx и SPACE — не три взаимозаменяемых набора и не буквальные пересекающиеся множества, а дополняющие линзы. DORA читает поставку через пять актуальных метрик: change lead time, deployment frequency, failed deployment recovery time, change fail rate и deployment rework rate.
Карта агентного стека
Три независимых решения → восемь опорных паттернов → портфель
AI-nativePlatformArchitecture
Когда использовать
Когда нужно решить, какой агентный стек разрешить компании, и выйти из спора «своё против чужого».
Спор «свой клиент на своей модели против вендорского агента по API» смешивает независимые решения. Обвязка, модель и инструменты выбираются по отдельности: у каждой оси свой путь данных, своя стоимость, своя точка отказа и своя зависимость от поставщика.
Воспроизводимый эпизод
Состояние → контракт → скрытая проверка → траектория → гейт выпуска
AI-nativeProductivity
Когда использовать
Когда реальную рабочую задачу нужно превратить в проверку агента, на которой можно основывать решение о выпуске.
Минимальная единица оценки агента — не вопрос из бенчмарка, а воспроизводимый эпизод: маленькая копия реальной работы. Для кода исходное состояние — коммит до пул-реквеста, для инцидента — система в момент T0, для данных — снимок данных, каталога и происхождения.
Граница владения стеком
Скорость изменения × уникальность → арендовать · адаптировать · владеть
AI-nativePlatformLeadership
Когда использовать
Когда решаете, что в AI-стеке арендовать, что адаптировать под себя, а что держать своим.
Для технического руководителя вопрос не в том, чей логотип выбрать, а в том, где провести границу владения. Ответ задают две оси: скорость изменения компонента и его уникальность для вашей среды.
Граф архитектурной памяти
6 узлов · 7 полей связи · одно изменение в обе стороны
ArchitectureAI-native
Когда использовать
Когда нужно понять, готова ли организация к AI-помощнику архитектора и где рвётся цепочка решений.
Артефакты обычно есть: требования, ADR, модели, код, SLO и сигналы эксплуатации. Нет цепочки между ними — документы лежат в шести разных системах, а непрерывность держится на людях.
Переход в роль CTO
−30 → 00 → 30 → 90: переход начинается до первого дня
Leadership
Когда использовать
Когда входите в топ-роль или нанимаете руководителя и хотите видеть рубежи перехода заранее.
Переход обычно считают с первого рабочего дня. Для CTO это поздно: к этому моменту уже выбраны компания, задача и люди. Четыре фазы связаны — слабое исследование ослабляет контракт, слабый контракт мешает диагностике, а поспешная диагностика ведёт к неверным изменениям.