Файл со слайдами: module-1.md
Слайд 1. Модуль 1. Переход от Senior к Lead
В этом модуле мы разбираем переход от роли Senior Developer к роли Lead.
Важно сразу снять одно частое ожидание: этот переход не про то, что человек стал важнее, получил больше статуса или теперь должен меньше писать код. Это более глубокое изменение.
Главная тема модуля — как меняется единица ответственности. Senior чаще всего отвечает за сложную задачу или сложную часть работы. Lead начинает отвечать за то, чтобы сложная работа стала выполнимой для команды.
Слайд 2. Lead — это не повышение важности
Когда человека называют Lead, легко начать воспринимать это как повышение статуса: теперь он главный, теперь все должны к нему приходить, теперь он принимает финальные решения.
Но в нормальной инженерной культуре Lead — это не про важность. Это про ответственность.
Lead не становится ценнее остальных людей. У него меняется фокус. Он смотрит не только на свою задачу, свой код и свой результат. Он начинает смотреть на то, как устроена работа команды вокруг сложной задачи.
Поэтому ключевая формулировка здесь такая: переход к Lead — это смена единицы ответственности.
Слайд 3. Главный переход
Вот центральное различие всего модуля.
Senior держит сложную задачу. Это значит, что он может разобраться в неочевидной проблеме, принять техническое решение, написать сложный код, довести свой участок до качества.
Lead держит систему выполнения сложной работы. Это уже другой масштаб. Его интересует не только ответ на вопрос “как решить задачу”, но и то, как сделать так, чтобы команда смогла эту работу понять, разделить, выполнить, проверить и довести до результата.
Если запомнить из первого модуля только одну мысль, то вот она: Lead отвечает не за то, чтобы лично решить все сложное, а за то, чтобы сложная работа стала выполнимой командой.
Слайд 4. Как мыслит Senior
Senior часто мыслит через личное инженерное владение задачей.
Есть сложная задача. Нужно понять, что происходит, найти решение, написать код, покрыть тестами, пройти ревью, довести свой участок до нормального качества.
Это сильная и нужная позиция. Без нее невозможно быть хорошим инженером. Более того, Lead не должен потерять эту способность.
Но сама по себе способность решать сложные задачи еще не делает человека Lead. Потому что команда может оставаться зависимой от одного сильного человека. Он все понимает, он все решает, но вокруг него работа не становится яснее и устойчивее.
Слайд 5. Как мыслит Lead
Lead смотрит на ту же ситуацию шире.
Он видит не просто задачу, а работу, которую должна выполнить команда. Эта работа должна стать понятной: люди должны понимать, что именно нужно сделать и зачем.
Она должна стать выполнимой: задача не должна быть огромным мутным комом, который страшно трогать.
Она должна быть распределенной: понятно, кто за что отвечает.
Она должна быть проверяемой: команда должна понимать, как выглядит готовый результат и как заметить, что качество просело.
И в конце эта работа должна быть доведена до результата не героизмом одного человека, а нормальной командной системой.
Слайд 6. Два разных вопроса
Разницу удобно увидеть через вопросы.
Senior чаще всего спрашивает: “Как мне это сделать?” Это хороший вопрос для исполнителя сложной инженерной задачи.
Lead задает другой вопрос: “Как сделать так, чтобы это было сделано командой и не развалило систему?”
Здесь появляется несколько дополнительных слоев. Кто должен участвовать? Какой контекст им нужен? Что пока непонятно? Где риск? Где зависимость? Что нужно зафиксировать, чтобы решение не осталось только в голове одного человека?
То есть Lead не просто решает задачу. Он проектирует способ выполнения работы.
Слайд 7. Что попадает в поле зрения Lead
У Lead расширяется поле зрения.
Senior может быть глубоко внутри кода, API, бага, алгоритма, теста или pull request. Lead тоже должен это понимать, особенно если это Tech Lead.
Но к этому добавляется более широкий контур: требование, пользовательский сценарий, архитектурное последствие, декомпозиция, риски, зависимости, коммуникация, качество, production, срок и delivery.
Это не значит, что Lead лично контролирует каждую мелочь. Это значит, что он обязан замечать, где работа может развалиться, и вовремя делать ее более ясной, управляемой и проверяемой.
Слайд 8. Ошибка перехода
Самая частая ошибка перехода — стать еще более сильным Senior.
Человек думает: если меня сделали Lead, значит, я должен брать самые сложные задачи, быстрее всех отвечать, все проверять, все спасать и быть главным техническим мозгом команды.
Проблема в том, что сначала это даже выглядит эффективно. Работа действительно может двигаться быстрее, если один сильный человек все тащит на себе.
Но через некоторое время команда начинает слабеть. Люди меньше принимают решений, меньше держат контекст, меньше растут. А Lead оказывается перегружен и становится центральным узким местом.
Слайд 9. Так появляется bottleneck
Bottleneck появляется не только тогда, когда человек ничего не делает. Иногда наоборот: он появляется потому, что человек делает слишком много за всех.
Без него не принимаются решения. Все вопросы идут к нему. Все сложные задачи автоматически падают на него. Контекст хранится у него в голове. Команда ждет, пока он посмотрит, разрешит, объяснит или спасет.
Внешне это может выглядеть как сильное лидерство. Но системно это слабая конструкция.
Работа держится не на понятном процессе, не на распределенной ответственности и не на зрелости команды, а на постоянной компенсации одним человеком.
Слайд 10. Что меняется
При переходе к Lead меняются три вещи.
Первое — объект внимания. Раньше основным объектом была задача: код, баг, модуль, реализация. Теперь объектом внимания становится система работы: как задача проходит через команду от непонятного запроса до результата.
Второе — отношение к задаче. Не просто “взять и сделать”, а сделать задачу понятной, разделимой, выполнимой и проверяемой.
Третье — способ влияния. Senior часто влияет личной силой: сам разобрался, сам сделал, сам продавил. Lead должен влиять так, чтобы после его участия команда становилась способнее, а не зависимее.
Слайд 11. Что значит держать delivery
Держать delivery — это не просто спрашивать “когда будет готово”.
Это видеть, что именно должно быть сделано, кто это делает, хватает ли человеку контекста, не слишком ли большая задача, есть ли внешние зависимости, где может всплыть риск.
Еще важно понимать, как отличить реальное движение от имитации движения. Команда может много обсуждать, ходить на встречи, писать сообщения, но при этом не приближаться к результату.
Lead должен помогать работе становиться наблюдаемой: понятно, где мы сейчас, что блокирует движение, какой следующий шаг и как мы поймем, что результат достигнут.
Слайд 12. Мини-кейс
Представим простую ситуацию: в команду приходит мутная feature. Требования неполные, технические последствия неясны, сроки уже кто-то примерно пообещал.
Senior-реакция может быть такой: “Я разберусь и сделаю”. Иногда это действительно помогает, особенно если задача срочная.
Но Lead-реакция должна быть шире. Что именно непонятно? Кто нужен для уточнения? Как разделить работу? Где риски? Какие решения нужно принять до начала реализации? Как мы проверим, что результат правильный?
Это и есть разница: Lead не просто входит в туман сам. Он помогает команде выйти из тумана вместе.
Слайд 13. Практика
Практика для этого модуля простая: возьмите одну текущую задачу своей команды и попробуйте разложить ее не как Senior, а как Lead.
Не начинайте с вопроса “как я это сделаю?”. Начните с других вопросов.
Что именно нужно сделать? Зачем это нужно? Кто вовлечен? Где есть риски и зависимости? Что нужно зафиксировать письменно? Как команда поймет, что задача действительно дошла до результата?
Эта практика важна не как формальность. Она тренирует новый способ смотреть на работу: не только через личное исполнение, но через выполнимость для команды.
Слайд 14. Формула модуля
Финальная формула такая.
Senior отвечает за сложность внутри задачи. Он может взять трудный кусок, разобраться, сделать и довести до качества.
Lead отвечает за выполнимость сложной работы командой. Его задача — сделать так, чтобы работа стала понятной, распределенной, проверяемой и доведенной до результата не за счет постоянного героизма, а за счет нормальной командной системы.
И это главный переход первого модуля: от личной инженерной силы к ответственности за систему работы.
