Как-то, когда я был лидом и ходил по собеседованиям на эту роль, я часто натыкался на один и тот же разговор: мы ждём, что лид будет писать код. И дальше начинались игры с цифрами — где-то говорили 30 на 70, где-то 50 на 50, где-то вообще 70 на 30.

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

Я писал код, когда был разработчиком, писал код, когда был лидом, и даже когда был на позиции CTO, всё равно иногда что-то пописывал. Мы всё-таки инженеры, и если нужно засучить рукава, расчехлить клавиатуру и порешать проблему кодом, то очень странно в этом случае говорить: извините, я теперь руководитель, у меня лапки и я могу только на созвоне с вами посидеть, пока вы тут код пишете 😎

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

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

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

Лиду, как по мне, и без продуктовых задач есть чем заняться в команде, он может:
👉 чинить маленькие баги и технический долг;
👉 выполнять R&D по архитектуре, библиотекам и инструментам;
👉 делать прототипы для будущих решений.

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

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

Но для этого нужно пройти техническое собеседование: код, архитектура, trade-off’ы, технологии, системный дизайн. И если ты несколько лет руководил так, что вообще не открывал IDE, то будет довольно больно.

Я поэтому с большим удивлением отношусь к позиции «я код писать не буду». Ну окей, если ты только пришёл в новую команду, тебе может быть вообще не до кода: найм, процессы, смежники, ожидания руководителя... Но эта работа конечна, и в какой-то момент команда уже собрана, процессы работают, люди вошли в рабочий ритм.

И если после этого лид всё ещё занимается только процессами, и не смотрит в код и архитектуру, то он постепенно перестаёт понимать, чем на самом деле живут его инженеры.

А дальше всё довольно просто: сегодня ты просто не пишешь код, завтра уже хуже понимаешь технические решения, послезавтра руководишь разработкой по рассказам бывалых, внутренним легендам и кофейной гуще 😎