Когда тимлиды начинают воевать - пора нанимать хеда.

Команд три, приоритетов пять, а сроки у каждого "самые важные". Бюджет улетел куда-то в космос, архитектура держится на костылях, техдолг растет быстрее, чем фичи.

Кажется логичным нанять ещё одного тимлида? Спойлер: не поможет.

Хед (Head of X) - это менеджер домена (dev / data / ML / что угодно), который видит всю картину сверху и собирает хаос в систему. Он уже не тонет в коде. Он про другое:
• приоритизация между командами: кто делает что, кто отдает ресурсы, кто получает.
• архитектура и инфраструктура: не как написать эту фичу, а как нам вообще не развалиться через полгода.
• найм и рост людей: единые стандарты, онбординг, карьерные треки, дорожная карта на месяцы, а не недели.

Сигналы, что нужен именно хед, а не очередной тимлид:
• Команд несколько, приоритеты конфликтуют, все дергают всех.
• Война за ресурсы стала нормой.
• Упираетесь в архитектуру/инфраструктуру постоянно, техдолг копится быстрее, чем его закрываете.
• Нужны найм, единые стандарты и дорожная карта на кварталы вперед, а не спринты.
• Бюджет на инструменты расползается, никто не видит общую картину. Счета растут, а толку нет.

Не нужно больше исполнителей. Нужен тот, кто остановит хаос на уровне системы.

Что меняется после хорошего хеда:
• системность: релизы идут по графику, а не как получится;
• прозрачность: все знают, кто что делает и почему именно сейчас;
• техдолг начинает снижаться, потому что появляется тот, кто отвечает за него на уровне всей разработки, а не одной команды.

Тимлид рулит одной командой. Хед - рулит войной между командами и превращает ее в оркестр.

CTO - это не главный программист. Это человек, который переводит технологии на язык денег, рисков и выживания бизнеса.

Когда CEO спрашивает: «Почему мы не можем сделать это за неделю?», а команда отвечает: «Потому что архитектура», и дальше тишина, это - это большая проблема.

Не техническая. Организационная.

Важно разделять роли.
Founding engineer / tech founder - может быть отличным разработчиком, который умеет быстро собрать продукт, написать код, довести MVP до жизни.

Но это не делает его автоматически CTO. CTO - это уже не про код и не про спринты. Это про всю технологическую систему компании - разработка, данные, инфраструктура, безопасность, масштабирование - и то, как все это влияет на деньги, скорость и риски.

И да, CTO по-хорошему нужен не “когда прижало”, а как минимум с момента product–market fit. Дальше прототипа без этой роли компания начинает накапливать дорогие ошибки.

Типичная ситуация:
• продукт, данные и инфраструктура живут как три параллельные вселенные;
• технические решения принимаются локально, а платит за них бизнес;
• впереди дорогие и необратимые выборы — архитектура, аналитика, безопасность;
• между CEO и инженерами нет моста, только переводчик в виде слайдов.

Что меняется, когда появляется нормальный CTO:
• появляется честный аудит - где дыры, где риски, где можно выиграть;
• архитектура становится понятной не только инженерам, но и бизнесу;
• костыли не “чинят”, а последовательно убирают;
• возникает план «сейчас / потом / никогда», который экономит реальные деньги.

Важно: первый технический человек в компании не обязан быть CTO навсегда. Спокойно можно начать с сильного founding engineer, а после PMF - пригласить полноценного CTO, иногда даже введя его как кофаундера.

Тимлид управляет людьми.
Хед - командами.
CTO - связкой «технологии - бизнес» и ценой ошибок на этом уровне.

Самый дорогой специалист не спасет бизнес, если проблема не в человеке.

Наняли звезду, а через полгода получили выгоревшего невротика и команду, которая пишет заявления на увольнение? Промахнуться с наймом легко не потому, что кандидат плохой, а потому что не разобрались, где он реально работает.

Где это обычно ломается:
Тимлид → Head. Человека тянут выше, но его реальная сила - в работе с одной командой. В итоге он начинает микроменеджить, лезет в детали, душит процессы и выгорает за полгода.

Head → CTO. Кажется логичным следующим шагом. На практике - это другой уровень задач: стратегия, политика, разговоры с бизнесом и инвесторами. Если человеку это не комфортно, он тонет и быстро теряет эффективность.

Тимлид с сильным продуктовым и стратегическим мышлением - он отлично видит картину, чувствует продукт, думает наперед, но не кайфует от операционного контроля и микроменеджмента. Это не «плохой тимлид», это сигнал, что человек перерос роль и, возможно, готов к уровню Head - но не туда, где нужно просто двигать таски.

Важно помнить порядок ролей: Individual Contributor → Team Lead → Head → VP / Director → CTO. И еще важнее - понимать, что рост не обязан быть линейным и не каждый сильный инженер или менеджер хочет и должен идти до CTO.

Вопрос почти никогда не в том, «кого ещё нанять». Вопрос в другом: не держим ли мы людей в ролях, где им тесно, душно или просто не по размеру?

И главное - самый дорогой найм не спасёт, если у компании размытый фокус, нет чётких метрик успеха, культура «делаем фичи ради фич» без гипотез и приоритетов. Новый человек может улучшить исполнение. Но если проблема в целях - он просто поможет быстрее добежать до тупика.

Стройка без прораба - это не дом, а набор ошибок.

Звучит смешно, пока не становится понятно, что половина стартапов живёт именно так. Представим стройку, где всем рулит дизайнер интерьеров - он про свет, плитку, диваны. Картинка - отличная. А дальше начинается реальность - электрик тянет провода через ванную, потому что «так быстрее», маляр красит поверх выключателей, потому что «так удобнее», шумоизоляции нет, потому что ее не было на рендерах.

Каждый занят делом. Каждый старается. А дом трещит по швам. Ровно так выглядел один стартап, с которым удалось поработать.

Бизнес-фаундеры сильные - рынок чувствуют, стратегия понятная, питчи заходят. Но техфаундера нет. Денег нет → времени нет → «Возьмем мидла на фронт, мидла на бэк - и поехали».

Дальше - классические симптомы стройки без прораба:
• фичи по отдельности нормальные, вместе конфликтуют;
• решения без схемы: сегодня так, завтра иначе;
• код на костылях, потому что «потом перепишем»;
• ночные релизы под мантру «лишь бы не упало»;
• никакой аналитики, мышление от таски к таске.

Команда не слабая. Проблема не в людях. Просто нет человека, который держит всю систему в голове. Им был нужен не герой-разработчик. Им был нужен носитель архитектуры.

CTO, fractional CTO, архитектор — название не принципиально. Человек, который знает:
• что строится;
• зачем именно так;
• как это складывается в одну систему;
• где границы ответственности.

Один такой человек меняет все. У решений появляется «почему». У продукта появляется шанс расти, а не разваливаться от следующей фичи.

Когда продукт выглядит как «пристройка к пристройке», проблема обычно не разработчиках. Это симптом отсутствия системного владельца.

В кейсе о котором я писал в прошлом посте, был подключён Fractional CTO. Не для «помочь команде», а чтобы вернуть управляемость. Первое, что он сделал - перестал обсуждать фичи. Начал обсуждать систему, что есть продукт, где границы доменов, как решения сегодня влияют на масштаб через полгода, какие компромиссы осознанные, а какие - просто случайные.

Дальше - базовая, скучная, но критически важная работа:
• единая карта архитектуры вместо знаний «в головах»;
• связь продукта, данных и инфраструктуры в одну цепочку;
• четкие зоны ответственности, без серых областей;
• простые правила принятия решений - чтобы не изобретать их каждый спринт.

Результат проявился быстро:
• фичи перестали конфликтовать между собой;
• релизы стали планируемыми, а не героическими;
• архитектурные решения начали жить дольше одного квартала;
• команда перестала бояться трогать код.

Никакой магии, просто появился человек, который держит всю конструкцию в голове. Бизнес-фаундеры без техфаундера почти всегда действуют рационально - нанимают тех, кого можно себе позволить здесь и сейчас. Так появляется набор сильных специалистов. И одновременно - технологический долг, который никто не контролирует.

Один системный CTO, даже fractional, стоит дешевле, чем:
• год жизни продукта в хаосе;
• переписывание ключевых частей под давлением;
• выгорание команды и смена разработчиков «пачками»;
• потерянное время, когда рынок уже ушёл дальше.

Fractional CTO - это не про роскошь. Это про ограничение ущерба. Самострой всегда кажется дешевле. Пока не приходит счёт на этапе роста.

Неудобная правда:
Дейтинг-приложениям невыгодно мэтчить действительно подходящих друг другу людей, так как тогда уходят сразу два платящих пользователя.
Поэтому, в рекомендательных системах существую сразу два алгоритма. Первый оценивает вероятность мэтча. Второй - вероятность того, что, если мэтч произойдет, это будет надолго. Показывают тех, у кого результаты первого высокие, а второго - низкие.
Поверьте человеку, который сам писал эти алгоритмы.

Очень не люблю фразу «выйти из зоны комфорта».

Зон на самом деле три - комфорта, дискомфорта, и серая зона (ни то ни другое). Выйти из зоны комфорта в серую зону - это про пресловутый внутренний рост. Но насильно запихивать себя в зону дискомфорта - прямой путь к выгоранию и поехавшей кукухе.

Для меня серая зона - публичные выступления: волнуюсь, но в результате норм. Зона же дискомфорта - холодный аутрич: даже написав нескольким людям, хожу весь день без сил, как будто оплеванный.

Если сотрудник косячит в 1 задаче из 10, мы микроменеджим.
В 1 из 100 - мониторим и проверяем.
В 1 из 1000 - встраиваем guardrails в систему.

Но, если в 1 из 10000 - зачастую, безоговорочно доверяем и даём полную автономию. Именно тогда, эти косяки накапливаются и, вдруг, обрушивают всю систему.

С AI-агентами также. И это гораздо опаснее, чем вероятность условного SkyNet.

Пока условный Claude Code регулярно тупит на сколь-нибудь сложных задачах, мы держим руку на пульсе. Но вопрос времени, когда отношения с агентом перейдут из формата тимлид-джун в формат PM-разработчики.

И тут уже будут продовые системы с неотслеживаемыми косяками, которые могут стать причиной чего-то типа ноябрьского обрушения Cloudflare, но более глобального и без возможности оперативно пофиксить.  

Программирую больше 10 лет. Сегодня, начитавшись Threads, решил впервые в жизни посмотреть, что это за 1С, о котором там вещают из каждого утюга.

АААААААААААА! Пожалуйста, скажите мне, что это пранк.
Или люди на полном серьезе пишут что-то типа «Если ТипЗнч(ТекОбъект) = Тип("Строка") Тогда», и не возникает даже намёк на улыбку?

Не ожидали меня слова услышать?

А я устал слушать, как AI «меняет шопинг».

Поэтому в ob.session (это наш новый проект, если кто-то пропустил) решили проверить довольно простую вещь: а люди вообще пользуются LLM, когда покупают одежду?

Не «представьте будущее e-commerce», а буквально:
«Что надеть с этой юбкой?»
«Найди мне такую же куртку».
«Мне на свадьбу, я понятия не имею, что хочу».

Где-то AI уже работает подозрительно хорошо. Где-то разваливается на самом простом запросе.

Сейчас собираем реальные сценарии использования.

Опрос на 2 минуты.

Если вы хоть раз пытались купить одежду с помощью ChatGPT / Claude / Gemini / чего-то ещё - расскажите, что из этого вышло👇
Опрос