#заметка дня

Я обещал про нытьё тимлида. Ну давайте поноем.

Технически, я engineering manager, что чуть больше, но то такое.

Итак, должен ли тимлид/менеджер кодить?

Короткий ответ: да. Но вот что и когда? И вот тут я начинаю сыпаться.

Почему люди (ну, кодеры) становятся тимлидами (или менеджерами)? Потому что, внезапно, они были достаточно хороши в своей работе по мнению вышестоящих менеджеров и/или инженеров.

Что это значит? Что они достигли максимального уровня комфорта, компетентности, если хотите.

Ещё можно сказать, что они освободили место для кодеров получше.

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

Болото кода может засосать глубоко и надолго. А проблемы клиентов, митинги, планирование — никто не отменял. В итоге не получается нормально ни там, ни там.

Совсем без планирования тоже нельзя, можно в итоге упустить нечто важное. Потому, нужна категоризация кодерских задач для тимлида.

Аврал я помещать в категории не буду. Его наличие означает, что уже всё.

1. Есть свободное окно. Планы закреплены, команда занята, довольна и понимает, что делать, цели намечены — ок, можно продолжать.
2. Ты лучший в том, что собрался делать. Можешь качественно и быстро сделать задачу — вперёд, но не забывай о процессах. Будь примером.
3. Не блокируй критичные узлы. Условно, не надо лезть в аутентификацию, а потом спрыгивать с неё, как будто ничего не было, вешая задачу на кого-то из команды. Не смог спланировать правильно — не начинай.

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

Справляюсь ли я с этим на данный момент? Хороший вопрос! Но я пытаюсь, правда :)

#teamlead #manager #code #problems