CTO против Tech Lead: на каком уровне должны приниматься технологические решения
В растущем бизнесе постоянно возникает вопрос: какие технологические решения принимает основатель или CEO, какие — CTO, какие — Tech Lead команды. Этот текст разбирает разделение уровней решений, типичные ошибки и подход к зрелой технологической организации.
Обсудить задачуАвторская позиция: CTO и Tech Lead — это не уровни ранга, это разные роли с разными ответственностями. Без явного разделения уровней технологических решений компания получает либо хаос, либо тормоз согласований.
Как это проявляется в жизни
В стартапе или растущей компании каждое технологическое решение принимается основателем или одним сильным разработчиком. По мере роста появляются новые роли — CTO, тимлиды, head of engineering — и возникает путаница. Тимлид принимает решения о стеке, которые потом сложно отменить. Основатель вмешивается в архитектурные детали отдельных модулей. CTO либо погружён в код и не видит стратегической картины, либо живёт в презентациях и оторван от технических реалий. Решения принимаются с опозданием или, наоборот, без должной зрелости.
Почему так получается
В большинстве растущих компаний технологическая организация формируется по мере необходимости, без проектирования. Сначала появляется CTO как «лучший из разработчиков», потом — тимлиды как «опытные среди джунов», потом — Head of Engineering как «организационный CTO». Никто не определял заранее, какие решения принимаются на каком уровне. Каждый новый человек берёт на себя то, что считает важным, и упирается в зону ответственности коллеги. Конфликты воспринимаются как личные, хотя источник — отсутствие архитектуры ролей.
Что обычно пробуют — и почему это не помогает
- Назначают CTO с надеждой, что он сам определит свою роль — обычно роль формируется хаотично через 6-12 месяцев
- Делают CTO рангом «первый среди разработчиков» — без стратегической дистанции технологическое видение не формируется
- Передают тимлидам полную свободу выбора стека — через год получают зоопарк технологий, который сложно поддерживать
- Привлекают внешнего консультанта по архитектуре — он даёт ответ, но без внутреннего собственника решение не приживается
- Создают архитектурный комитет — он становится медленным согласовательным органом, тормозящим решения
Что реально нужно
Нужно явное разделение уровней технологических решений с привязкой к ролям. Уровень компании (выбор основной платформы, отношение к облаку, политика безопасности, архитектурные принципы) — CTO или CEO с участием CTO. Уровень продукта (стек продукта, паттерны интеграций, выбор баз данных) — CTO или Head of Engineering с участием Tech Lead. Уровень модуля (архитектура отдельного модуля, выбор библиотек) — Tech Lead. Уровень кода — разработчик. Каждый уровень имеет своих стейкхолдеров для согласования и свой ритм пересмотра.
Что проверить до старта
- Кто в компании имеет право сказать «нет» команде на выбор нового стека
- Какие технологические решения требуют согласования, какие принимаются автономно
- Сколько разных стеков и баз данных используется в компании, и оправдано ли это разнообразие
- Как часто меняется технологическое решение через 6-12 месяцев после принятия (признак неправильного уровня решения)
- Кто отвечает за формулирование архитектурных принципов компании, и существуют ли они вообще в зафиксированном виде
Как двигаться шаг за шагом
- Сформулировать архитектурные принципы компании — обычно 5-10 пунктов о выборе технологий, паттернов, отношения к рискам
- Определить уровни технологических решений и роли, ответственные за каждый уровень
- Объявить эти уровни и роли публично внутри команды — без объявления никто не знает правил
- Запустить ритм пересмотра — каждый уровень имеет своё расписание ревизии (компания — раз в год, продукт — раз в полгода)
- Дать командам автономию в рамках их уровня — без автономии любая иерархия превращается в тормоз
- Через 6 месяцев — пересмотр модели на основе реальных конфликтов и решений
Что ещё стоит изучить
Темы из этой же области, которые часто разбираем вместе с этой
CRM
Не коробочный CRM, а правильно выстроенный контур управления клиентами — от первого контакта до лояльности.
→РешениеBI
Аналитика — не красивые графики на стене. Это ответ на вопрос 'почему?' до того, как проблема станет убытком.
→РешениеКонтакт-центр
Контакт-центр — не телефонная станция, а точка, где клиент решает: остаться с вами или уйти. Вопрос в том, как он устроен внутри.
→РешениеОнбординг
Онбординг — первое впечатление клиента о вашей компании. Если оно занимает 5 дней и 12 бумажных форм, второго впечатления не будет.
→Об этом не просто пишу — могу прийти, разобрать вашу ситуацию и спроектировать решение под ваш контур.
Обсудить применение →Готовы обсудить вашу задачу?
Расскажите, что не работает или что нужно построить. Первый разговор — без обязательств.
Обычно отвечаю в течение нескольких часов