Из инженера в лида: смена системы координат

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

Эта глава — про механику перехода. Не «каким надо быть», а что конкретно перестаёт работать, как это выглядит со стороны и по каким признакам ловится. Общая рамка — что происходит с контуром обратной связи и какие у роли рычаги — в карте трека; здесь мы спускаемся на уровень первых недель.

Единица работы поменялась

Инженерная работа измеряется изменениями в системе: коммит, ревью, релиз, починенный инцидент. Единица дискретна, авторство однозначно, качество проверяет автоматика. Управленческая работа измеряется изменениями в способности команды производить изменения — это тоже материальная вещь, просто с другой единицей: снятая зависимость, принятое решение, которое иначе висело бы месяц, человек, который теперь делает сам то, что раньше делали вы.

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

Ваши ошибки тоже стали невидимыми. Плохо сформулированное ожидание не падает с трейсбеком: оно всплывает через полгода как «он не понимал, чего от него хотят».

Работа перестала заканчиваться. У инженера есть состояние «сделано»; у руководителя задачи не завершаются, а переходят в другое состояние — разговор состоялся, появились три новых. Привычка мерить день закрытыми задачами толкает обратно к тикетам, где это ощущение ещё доступно.

Именно поэтому Энди Гроув в «High Output Management» (1983) вводит понятие управленческого рычага: результат руководителя — результат его организации плюс результат соседних организаций, на которые он повлиял. Экспериментом это не подтверждено, но как способ считать свою работу удобнее альтернатив: он хотя бы говорит, что считать — не ваши действия, а изменения в чужой работоспособности.

Честно про доказательную базу

Про переход в управление написано много и измерено мало. Что здесь есть на самом деле:

Качественное лонгитюдное исследование. Линда Хилл (Harvard Business School) наблюдала за новыми руководителями в течение первого года в роли — книга «Becoming a Manager» (1992, переиздание 2003) и статья Becoming the Boss (HBR, 2007). Наблюдения узнаваемые: новые руководители приходят с ожиданием полномочий, а обнаруживают зависимость от людей, которыми не управляют; ждут контроля, получают переговоры; около года живут с ощущением самозванца. Небольшая выборка и не эксперимент — но это про наблюдаемое поведение, а не про «десять качеств лидера».

Мета-анализ обучения руководителей. Lacerenza et al., JAP 2017: эффект заметен на знаниях и поведении, слабее — на бизнес-результатах. То есть управленческие навыки в принципе тренируемы, что не так очевидно, как кажется.

Количественная работа про сам факт повышения. Benson, Li, Shue, Promotions and the Peter Principle (QJE, 2019): лучших продавцов повышают в менеджеры чаще, и они оказываются худшими менеджерами. Механизм тот же — повышение как награда за прошлую работу, а не назначение на другую.

Чего нет вовсе. Данных о том, сколько кода должен писать тимлид, сколько человек оптимально в прямом подчинении, как правильно проводить первый месяц. Фурнье, Ларсон, Зуо, Лопп и Гроув описывают опыт, а не доказательство; всё конкретное ниже — практика с явно названным признаком нарушения, и проверять её надо на своей команде.

Восемь инженерных привычек, которые начинают вредить

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

Три из них чинятся не силой воли, а изменением схемы работы, и разобрать их стоит отдельно.

«Быстрее сделать самому»

Арифметика в моменте на вашей стороне: вы сделаете за два часа, инженер за день, плюс ревью. Ошибка в том, что величины разные: вы считаете стоимость одной задачи, а платите способностью команды делать такие задачи без вас. Проверяемо: если задачу типа X за три месяца делали только вы, через полгода она по-прежнему будет делаться только вами, и ваш отпуск станет событием для релиза. Признак уже случившейся поломки — вопросы по подсистеме идут к вам, хотя владелец другой. Способы отдавать разбирает Делегирование.

«Молчание — значит всё нормально»

У кода нет мотива умолчать. У человека есть, вполне рациональный: сказать «я третью неделю не понимаю этот легаси» дороже, чем промолчать и надеяться, что разберётся. Инженерная интуиция «нет сообщений об ошибках — система здорова» здесь даёт систематически неверный ответ. Отсутствие плохих новостей — не данные; данные появляются, только если вы построили канал, где честность дешевле молчания. Отсюда формат один на один и правило спрашивать про эпизоды, а не про самочувствие.

«Прямота, как в код-ревью»

Фраза «это неправильный подход» от равного коллеги — приглашение к спору. Та же фраза от руководителя — закрытие темы: спорить с человеком, влияющим на вашу оценку, дорого. Вы не меняли тон, изменился вес. Признак нарушения: за последний месяц никто публично не возразил вашему техническому мнению. Это не значит, что вы правы, — это значит, что вам перестали говорить. Что делать: высказываться последним, отделять «это решение» от «это гипотеза, ищите дырки» и просить возражения у конкретного человека, а не у комнаты. Формулировки — Обратная связь, техника обсуждения — фасилитация.

Ваша реплика теперь весит больше

Самый недооценённый эффект первых месяцев. Вы произносите «а может, стоит посмотреть в сторону событийной модели» — для вас это мысль вслух, для команды либо решение, либо намёк, который безопаснее выполнить.

Механику ловят два правила, у обоих есть наблюдаемое нарушение. Говорите последним в техническом обсуждении. Нарушение: вы открываете обсуждение своей версией решения, дальше все обсуждают её. Вы получите отшлифованный вариант собственной идеи вместо перебора альтернатив — и будете уверены, что команда согласна.

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

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

Что происходит с календарём

Инженерная работа требует связных блоков: контекст собирается медленно и рассыпается от любого прерывания. Управленческая состоит из коротких синхронизаций. Два режима плохо совмещаются в одной неделе — эссе Пола Грэма Maker’s Schedule, Manager’s Schedule (2009) не исследование, но точное описание конфликта; косвенная эмпирика про цену прерываний есть у Mark, Gudith, Klocke, The Cost of Interrupted Work (CHI 2008). Главное про новый календарь: считать надо не занятые часы, а связные.

На картинке занятость выросла с 5 до 20 часов в неделю — казалось бы, 25 часов ещё свободны. Но блоков длиннее 90 минут осталось три, суммарно меньше пяти часов, и это весь ваш ресурс на работу, требующую непрерывного думания: дизайн-документ, разбор архитектурного спора, подготовка к тяжёлому разговору, план найма. Считать это стоит не на глаз: разметка прошлой недели занимает двадцать минут и даёт число, которое можно предъявить себе и руководителю.

"""Свободные окна не короче min_len внутри рабочих дней.

Вход — занятые интервалы в минутах от начала недели.
Сложность: O(n log n) по времени на сортировку, O(n) по памяти.
"""
Slot = tuple[int, int]  # (начало, конец) в минутах от начала недели


def free_blocks(busy: list[Slot], day_len: int = 540, days: int = 5,
                min_len: int = 90) -> list[Slot]:
    blocks: list[Slot] = []
    for day in range(days):
        day_start, day_end = day * day_len, (day + 1) * day_len
        todays = sorted(s for s in busy if s[0] < day_end and s[1] > day_start)
        cursor = day_start
        for start, end in todays:               # интервалы могут пересекаться
            if start - cursor >= min_len:
                blocks.append((cursor, start))
            cursor = max(cursor, end)
        if day_end - cursor >= min_len:
            blocks.append((cursor, day_end))
    return blocks


def report(busy: list[Slot]) -> None:
    deep = sum(e - s for s, e in free_blocks(busy))
    busy_min = sum(e - s for s, e in busy)
    print(f"встреч {busy_min / 60:.1f} ч · свободно "
          f"{(5 * 540 - busy_min) / 60:.1f} ч · связного {deep / 60:.1f} ч")

Смысл не в цифре, а в выводе: вы не можете взять задачу, требующую восьми часов связного времени, если у вас его пять. Не «надо лучше организоваться» — просто не можете. Честных ходов три: отдать задачу, вычистить встречи (см. Встречи и Календари) или договориться с руководителем, что часть недели защищена. Нечестный один — делать её вечерами; работает месяц-другой и заканчивается выгоранием. И отдельная деталь: фрагментация дороже занятости. Час встреч в середине дня стоит не час, а два соседних блока по 90 минут, переставших быть блоками. Поэтому первое разумное действие с календарём — не сокращать встречи, а сдвигать их к одному краю дня.

Сколько кода писать

Универсального ответа нет, а вредных советов два: «лид не должен писать код вообще» (выбрасывает вашу способность понимать систему) и «лид должен оставаться сильнейшим инженером» (ставит вас на критический путь). Работающая формулировка: пишите то, чья задержка не создаёт проблем другим. Это проверяется тремя вопросами.

Что попадает в правую нижнюю ветку: внутренние инструменты, автоматизация рутины, прототип для проверки гипотезы, некритичный багфикс, тестовая инфраструктура. Что не попадает почти никогда: фича из релиза, интеграция со смежниками, всё, чего кто-то ждёт к дате. Признак ошибки с выбором: на стендапе вы третий день подряд говорите «доделываю то же самое», и на этой же неделе у вас отменились два разговора. Менее очевидный признак: PR команды лежат по два дня, потому что вы единственный обязательный ревьюер — тот же критический путь, в профиль.

Деградация навыков реальна и лечится не героизмом, а сменой формата участия: чтение чужих PR, дизайн-обсуждения, парная работа раз в спринт, разбор инцидентов. Ветвление карьеры разобрано в карьерных треках; формулировка про маятник «инженер — менеджер — инженер» принадлежит Черити Мэйджорс (The Engineer/Manager Pendulum, 2017) — эссе, не данные, но оно избавляет от ложной развилки «выбери раз и навсегда».

Бывшие коллеги, ставшие подчинёнными

Самая частая конфигурация: лидом назначают изнутри команды. И самая частая ошибка — вести себя так, будто ничего не изменилось. Изменилось, причём для них раньше, чем для вас: вы всё ещё чувствуете себя своим, а они уже пересчитывают, что можно вам говорить. Что поменялось, стоит назвать вслух и по пунктам:

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

Разговор, который стоит провести с каждым в первые две недели

Не объявление на командной встрече, а отдельный разговор с каждым: объявление снимает вопрос статуса, но не отвечает на главный — что лично этот человек теряет и получает.

Каркас разговора (порядок важнее формулировок)

1. Что изменилось фактически: что теперь решаю я, что решают они, что никто.
2. Что не изменилось: техническое уважение, право спорить, доступ ко мне.
3. Чего я больше не смогу: обсуждать других людей, пересказывать разговоры
   с руководством, быть просто коллегой в конфликте.
4. Прямой вопрос: «Что тебя в этом назначении настораживает?» Дальше молчать.
5. Что обещаю на первый месяц: не менять процессы, пока не пойму, зачем они
   такие, и не принимать решений о людях в одиночку.

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

Три случая, которые ломают общую схему

Тот, кто тоже претендовал на роль. Худшее — притвориться, что этого не было. Честный вариант: назвать ситуацию, сказать, что решение принимали не вы (если это правда), и обсудить конкретику — чего он хочет дальше и что вы можете сделать. Обещать «в следующий раз будешь ты» нельзя, это не ваше решение. Если он уйдёт — иногда это лучший исход для обоих, и делать вид, что такого варианта нет, наивно.

Близкий друг в команде. Дружба не запрещена, но стала наблюдаемой: совместные обеды читаются командой как доступ к вам. Граница — не сокращать общение, а выравнивать доступ: обсуждаете рабочее в баре с одним — у остальных должен быть равноценный канал. Нарушение: в команде завелось мнение, что решения принимаются «до встречи».

Более опытный инженер, чем вы. Нормальная ситуация, которая становится проблемой, только когда лид доказывает превосходство. Рамка: у вас разные предметы ответственности — вы не обязаны быть сильнейшим инженером, вы обязаны обеспечивать, чтобы сильнейшие решения принимались и исполнялись. Признак поломки: с ним вы спорите публично чаще, чем со всеми остальными вместе.

«Я просто останусь техлидом»

Соблазн понятный: техническая часть роли знакома и даёт быструю обратную связь, управленческая не даёт. Схема выглядит рабочей первые месяцы и ломается предсказуемым образом.

Цикл устойчив, потому что каждый переход рационален в моменте: взять задачу вместо разговора разумно, когда горит релиз; перенести один на один разумно, когда инцидент. Всё откладываемое имеет длинный контур обратной связи и потому не выглядит срочным до момента, когда становится необратимым. Что происходит с частями роли, если их не делать:

Есть и легальный вариант «остаться техлидом» — когда роль разделена и людьми занимается отдельный менеджер. Это не отказ от части работы, а другая работа с другими критериями; развилка описана в карте трека. Проверить свою конфигурацию можно одним вопросом: кто пишет и защищает оценку ваших инженеров. Не знаете ответа — вы в гибриде и просто ещё не столкнулись с этим.

Первые 90 дней: сначала выяснить, потом менять

Первые 90 дней со стороны сотрудника разобраны в отдельной главе, у Scrum-мастера — в своей. Ниже специфика лида, и главный принцип: первый месяц вы собираете информацию, которой у вас не было, пока вы смотрели на систему снизу.

Три пункта важнее остальных.

Контракт с руководителем — в первые дни. Что считается успехом команды в этом полугодии, что он хочет узнавать от вас и как часто, какие решения вы принимаете сами. Признак, что контракта нет: вы не можете назвать, за что вас будут оценивать. Детально — Вверх по цепочке.

Одно изменение, а не пять. Не из вежливости, а из наблюдаемости: поменяв пять вещей сразу, вы не узнаете, какая сработала. Плюс пакет из пяти читается как «новый начальник наводит порядок».

Странное правило почти всегда имеет причину. Прежде чем отменять никем не читаемый отчёт, узнайте, кто его завёл и что случилось до него: в половине случаев причина внешняя и до сих пор жива. Нарушение выглядит так — через месяц после отмены приходит вопрос от смежников, который этот отчёт закрывал.

Как заменить сломанный контур обратной связи

Раз результат приходит через квартал, нужен искусственный короткий контур. Единственная практика, которая надёжно это даёт (отраслевая, но с проверяемым нарушением) — журнал решений с предсказанием и датой проверки.

## 2026-07-16 — отдаю миграцию биллинга Ане, не делаю сам

Контекст. Срок — конец сентября. Я сделал бы за 3 недели, Аня — за 5–6,
и это её первая задача такого масштаба. Чего боюсь: застрянет
на согласовании с платформой и не скажет.

Ожидаю увидеть к 2026-08-15:
- схема согласована со смежниками без моего участия;
- Аня сама принесла два риска, о которых я не знал;
- я потратил на задачу не больше 2 часов в неделю.

Проверка 2026-08-15. Схема согласована, риск принесла один — про
идемпотентность, я про него не думал. Потратил 4 часа в неделю, из них 2 —
на чужой отказ согласовывать. Вывод: недооценил внешние согласования,
в следующий раз беру их на себя явно, а не «если что, помогу».

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

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

Что ломается чаще всего

Сбои в порядке частоты, симптом → последствие.

1. Задача с дедлайном осталась за вами. Дописываете вечерами → к разговорам не готовитесь, они вырождаются в статус (Один на один).
2. Отношения с бывшими коллегами не переопределены. Всё держится на «мы же свои» → первое непопулярное решение читается как предательство.
3. Мысль вслух воспринята как приказ. Вы не заметили → команда неделю делает не то.
4. Процессы перестроены в первый месяц. Причины были внешние → через квартал приходит проблема, связь с вашим изменением уже не восстановить.
5. Роль не выяснена. Вы считаете себя техлидом, компания — менеджером → на ревью выясняется, что оценивали вас по другой работе.
6. Календарь заполнен чужими встречами. Связного времени ноль → техдолг и планирование не делаются вовсе.
7. Обратная связь откладывается. Подходящего момента не бывает → к ревью накоплен список, для человека это внезапный приговор (Обратная связь).
8. Вы единственный обязательный ревьюер. Очередь PR растёт → узкое место вы, а выглядит это как «команда медленная».

Признаки, что переход состоялся

Формальных метрик нет; ниже наблюдаемые признаки с видом нарушения. Два-три нарушения сразу означают, что вы всё ещё работаете инженером с расширенными обязанностями.

Про сроки: первый год в роли ощущается как некомпетентность — это описано во всех наблюдениях за новыми руководителями, включая работу Хилл. Ощущение неинформативно: оно одинаково у тех, кто справляется, и у тех, кто нет. Информативна только таблица.

Мини-итог

• Единица работы — изменение в способности команды производить изменения; ваш вклад стал косвенным, ошибки — отложенными, а «сделано» исчезло как состояние.
• Самые дорогие инженерные привычки: «быстрее сделать самому», «молчание значит норму» и прямота, вес которой вы больше не контролируете.
• Ваша реплика весит больше чужой: говорите последним, помечайте, где решение, а где гипотеза.
• Считайте не занятые часы, а связные блоки; код писать можно, но только тот, чья задержка никого не блокирует.
• С бывшими коллегами — отдельный разговор в первые две недели, вслух о том, что изменилось.
• «Останусь просто техлидом» — устойчивый цикл, заканчивающийся кризисом; конфигурация роли проверяется вопросом «кто защищает оценку моих инженеров».
• Первый месяц — сбор информации и одно изменение, а не пять; искусственный контур обратной связи — журнал решений с предсказанием и датой проверки.

Источники

• Linda A. Hill. Becoming a Manager (HBS Press, 1992/2003) и Becoming the Boss (HBR, 2007) — наблюдение за первым годом новых руководителей.
• Lacerenza et al. Leadership training: a meta-analysis (JAP, 2017) — psycnet.apa.org.
• Benson, Li, Shue. Promotions and the Peter Principle (QJE, 2019) — academic.oup.com.
• Mark, Gudith, Klocke. The Cost of Interrupted Work (CHI 2008) — цена прерываний.
• Paul Graham. Maker’s Schedule, Manager’s Schedule (2009); Charity Majors. The Engineer/Manager Pendulum (2017) — эссе, не данные.
• Andy Grove. High Output Management (1983); Camille Fournier. The Manager’s Path (2017); Julie Zhuo. The Making of a Manager (2019); Michael Lopp. Managing Humans; Will Larson, Work on what matters — отраслевой опыт.

Что дальше

Первый инструмент, в котором смена системы координат становится осязаемой, — регулярный разговор с каждым человеком: там вы узнаёте то, что не проходит через публичные каналы, и именно он деградирует в статус-митинг быстрее всего.

Один на один: как вести, чтобы это не стало статусом