Задача менеджера - это построение производственного процесса

- Как вы стали тимлидом?
- Предыдущий умер.
- Что?
- Что?

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

Раньше всё было просто. Сидишь ты, пишешь код целый день, вечером сделал коммит - и домой. Такая работа очень понятна, ценность её очевидна, результат заметил. Но с переходом в тимлиды бывший разработчик начинает заниматься каким-то мифическим "менеджментом". Обычно под менеджментом воспринимается полный календарь созвонов и ощущение бессмысленности в конце дня.

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

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

Задача тимлида - это построение производственного процесса в команде. Мне больше всего нравится аналогия с производственным конвейером, которая пришла ко мне в процессе чтения книги "Цель" Элияху Голдратта. Результатом работы тимлида является именно работающий конвейер, поэтому и метрики успешности совершенно другие.

Руководитель должен смотреть на свою команду и задаваться вопросами:
- Насколько хорошо команда справляется с работой?
- Где буксуют задачи?
- Довольны ли люди своей работой?
И любыми другими на своё усмотрение.

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

Напоследок поделюсь небольшим советом, который я даю начинающим тимлидам на консультациях. Когда я не понимал, как оценивать свою работу, мне помогла одна простая мысль: "Если команда работает, делает задачи, не срывает сроки и не срётся между собой - то я достаточно хорошо справляюсь со своей работой".