В недавнем выпуске подкаста DotNet & More мы обсуждали полезные материалы для тимлидов, и всплыла классическая проблема: как совмещать управление командой и написание кода. Этой осенью я рассказывал о лайфхаках, которые помогают мне продолжать программировать на позиции лида, и мне показалось полезным, в этом контексте, выложить текстовую расшифровку доклада.

Хочу сказать отдельное спасибо Алисе Мироненко за подготовку транскрипта. Видео версия доклада:

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

Мне часто встречаются люди с такой карьерной историей: в новую компанию приходит разработчик с десятилетним опытом работы. В 2010 году он пришел в компанию Х, быстро развился до синьора, он талантливый, крутой. Так как он талантливый, ему дали тимлида.

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

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

Потом человек с таким опытом приходит к нам на позицию разработчика.

Получается интересная история: опыт в резюме – десять лет, а реальный опыт разработки – два-три года.

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

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

Но расстояние между лидом и менеджером такое же, как между джуном и лидом.

У нас нет времени учиться на менеджеров – это главная проблема.

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

Но есть и другие варианты роста. Есть возможность быть тимлидом, который развивается в первую очередь как инженер. Я специально говорю романтизированное «инженер». Не просто человек, который умеет крутить гайки/писать код, а который умеет решать сложные задачи, в том числе привлекая других людей.

У нас есть такой вариант – идти в тимлиды, сохраняя инженерную рабочую нагрузку.

Раз мы решили пойти в менеджмент, давайте получать соответствующие навыки, знания. А то есть менеджеры, которые не знают основ – как делегировать и прочее.

Если мы решили углубиться в разработку, у нас должна быть инженерная нагрузка, хотя бы 30%. Возникает вопрос: «А разве эти 30% нас спасут?» Да, об этом сегодня и поговорим – как добиться этих 30% эффективной работы, чтобы мы продолжали развиваться как настоящие инженеры.

Давайте начнем с того, когда тимлиду стоит заниматься разработкой. Я сделал небольшой чеклист. 

Возможно, у вас есть время на разработку, если:

1. Вы занимаетесь микроменеджментом.

2. Пишете много документации «в стол».

3. Вы единая точка коммуникации на проекте.

4. Ваша команда только пишет код.

5. У вас много тет-а-тет митингов.

6. Вы инициатор большинства этих митингов.

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

В целом я считаю, что совмещение ролей управленца и инженера зависит от трех вещей: 

1) Стадии развития вашей команды  

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

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

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

Как только вы перейдете в режим норминга и перформинга, у вас освободится гораздо больше времени на программирование.

2) Уровня квалификации и мотивации ваших сотрудников  

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

Обратная ситуация – у вас в команде толпа «выгоревших синьоров». Тогда время и энергию стоит вложить в поддержку  ребят, чтобы они выскочили из ямы демотивации.

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

Есть классическая табличка на эту тему:

Единственный возможный вариант освободить себе время на разработку – делегировать задачи достаточно мотивированной и квалифицированной команде.

3) Уровня коммуникации на проекте 

Возможности тратить времени на разработку не будет, если есть проблемы в коммуникации на проекте.

Например, mushroom management (управление по принципу «меньше знаешь – крепче спишь), когда вы являетесь единой точкой коммуникации и никто больше не знает, что происходит.

Очевидно, что в таком случае у вас не будет времени на инженерную деятельность.

Как настроить коммуникацию?

Вариант: если я единая точка коммуникации, я возьму и самоустранюсь.

Главная проблема будет в том, что появится неформальный лидер. Понятие «неформальный лидер» неприятное, потому что часто неформальные и формальные лидеры – не одно лицо. Это становится проблемой для формального лидера.

В идеале нам нужно соблюдать баланс в коммуникации: вы управляете командой, но не всё не завязано на вас – команда тоже общается с заказчиком и может решать проблемы.

Как перестать быть единой точкой коммуникации? 

Если «всех всё устраивает», один из самых приятных вариантов – натравить на команду SCRUM-мастера, чтобы контролировать и оптимизировать рабочий процесс. К сожалению, это не всегда срабатывает.

Тогда можно пойти по классическому пути: уходите в отпуск – оставляете своего заместителя. Никакой заказчик не будет против, чтобы временно пообщаться с вашим сотрудником (кроме редких исключений). Но это не помогает познакомить заказчика со всей командой. Поэтому я бы хотел рассмотреть более общий способ того, как «подружить» заказчика с командой:

• Познакомьте заказчика с командой через task manager.

• Организуйте встречу с командой в привычном для заказчика месте и времени. Не приводите сразу всех.

• Ведите первые митинги как обычно, тет-а-тет с заказчиком, но с командой «на фоне».

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

• Поднимайте на встречах вопросы, которые можно адресовать команде. Пусть на них отвечают, не ожидая вас.

• Позвольте вашим коллегам вести митинги и переписки напрямую с заказчиком, но в первое время будьте рядом.

• Всегда будьте в копии и на связи с заказчиком. 

• Это было про коммуникацию, теперь про то, как делегировать.

Делегирование – процесс передачи функции руководителя. Но наши функции не всегда очевидны другим. Например, наша обязанность – деплой на продакшен в рамках фичи деплоя. Для нас может быть очевидно, что нужно прогнать тесты, кто ж не знает? Никто не знает, эта информация в вашей голове. Необходимо донести её до человека, который будет выполнять задачу.

Делегирование – это отдельная тема, сейчас я остановлюсь только на нескольких моментах.

Не забывать, что ваши функции не очевидны другим. 

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

Делегирование должно развивать сотрудников. Помните, что чем больше вы делегируете человеку, тем лучше он справляется со своими полномочиями. Поэтому, если первый раз произошло полное фиаско и человек не справился с функциями, которые вы делегировали, лучше дать ему возможность еще раз попробовать эту задачу, возможно, он чему-то научился. Как это понять? Важная часть делегирования – контроль. Еженедельный контроль, ежедневные митинги и прочее.

Не забывайте, что делегирование – это не безучастность. Вы должны быть в курсе событий, слушать митинги.

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

Давайте теперь подумаем, как бороться с отвлечением и управлять вниманием

В чем проблема борьбы с отвлечением для тимлидов? В том, что классические подходы к тайм-менеджменту – focus time, помидорка, скалирование времени и другие – не работают, если сотрудники не уважают ваше время.

Но что делать с вопросами коллег? Важно отвечать на них хотя бы в течение получаса.

Я предпочитаю способ переноса времени: если вам написали, а вы программируете, то вы отвечаете через пятнадцать минут. Крайне важно не забывать ответить.

Для тимлидов отметим важный момент: пишем «через 15 минут» правильно.

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

Рассмотрим еще одну проблему – возврат в контекст.

Вы программируете, у вас в голове: «Задача-метод-класс». Вас отвлекли, контекст пропал. Вы ответили сотруднику, нужно вернуться в контекст.

Одно из самых эффективных решений – микродекомпозиция. Это когда вы берете листочек/one note, где можно сделать древовидную структуру и декомпозировать свою задачу вплоть до псевдокода или формулировки «сделай вот это».

Мультитаскинг – большая проблема тимлида, и здесь могут помочь виртуальные рабочие столы.

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

На виртуальном столе, где у вас релиз в продакшен, Jenkins/TeamCity, Splunk/Kibana, чат с DevOps. То же самое с обсуждением требований: Skype/Teams, Jira, Confluence.

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

Пора программировать

Мы настроили время, коммуникацию, справились с отвлекающими факторами, налили чаёк… И мы парализованы.

У нас антипаттерн – аналитики-паралитики.

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

Как вы думаете, о чём будет думать архитектор нефтекомплекса, когда ему надо чинить трубу? «Пройдет ли этот биметалл эконормы? А как на давление повлияет в сжигателе?» В данном случае архитектор просто не сможет починить эту трубу, потому что не справится с такой когнитивной нагрузкой.

У нас то же самое. Разработка ПО – это комплексная задача. Бизнес-контекст, архитектура, код и прочее. От нас как от тимлидов требуют думать глобально. 

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

Напоследок хотелось бы поговорить про выбор «программерской роли», когда вы тимлид 

Давайте рассмотрим основные роли:

Ключевой разработчик, который делает основную бизнес-логику, разрабатывает ядро продукта.

Если ваша большая команда, времени на это может не быть. Стоит вовремя отдать эту роль, когда команда растет, иначе вы можете превратиться в прототипщика (человек, который пилит прототипы, а доведение проекта до ума оставляет на откуп команде).

«Затыкатель дыр» – человек, который приходит, когда нам чего-то не хватает для полного счастья.

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

«Еще одни руки» – еще один программист, который просто еще что-то делает – фиксит баги, например.

Этот подход работает, потому что тимлид с такой ролью хорошо знает систему. Тут важно не стать кодерским балластом.

И мое любимое – кодерский балласт. Человек, которого лучше бы не было. 

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

Резюмируя: как быть тимлидом и продолжать программировать.

Когда? 

• Когда команда на стадии норминга или перформинга.

• Когда люди квалифицированы и мотивированы.

• Когда настроена коммуникация.

Как?

• Прямая коммуникация.

• Делегирование.

Рекомендации

• Управлять отвлекающими факторами.

• Микродекомпозировать задачи.

• Облегчить переключение фокуса внимания.

• Трезво выбирать роль. 

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