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

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

Почему технические руководители должны обладать технической компетенцией

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

Технически компетентный руководитель:

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

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

Кодер или наставник?

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

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

Приведите свою команду к успеху

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

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

Самодостаточная команда наделенных полномочиями ответственных профессионалов, где вы не являетесь бутылочным горлышком при принятии решений, позволит вам выделить больше времени на то, чтобы заняться чем-то еще.

Вес ваших слов

Еще одной проблемой для меня стало то, что во время обсуждения технических вопросов я слишком много говорил или навязывал команде свою точку зрения. Я не осознавал эту проблему, пока сотрудница не указала на нее во время сессии обратной связи, в которой принимала участие вся команда. Она сказала что-то вроде: «Во время наших технических обсуждений Вы слишком настаиваете на своей точке зрения… Думаю, Вам следует меньше давить на нас, дать нам больше свободы».

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

Что я могу посоветовать?

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

Всегда говорите в последнюю очередь и задавайте вопросы, вместо того чтобы давать ответы

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

James Everingham пошел еще дальше и предположил, что, только лишь наблюдая, руководитель уже меняет исход проекта. В своей квантово-механической аналогии (Quantum Mechanics analogy) он пишет:

Эффект наблюдателя проявляется и на рабочем месте. Вы можете влиять на исход любого проекта лишь своим присутствием. Часто бывает, что руководитель собирает всех вместе и говорит: «Вот что мы должны сделать», или «Вот что я думаю», или «Давайте посмотрим на этой вопрос вот с такой стороны», начиная при этом что-то рисовать на доске. Он пытается добавить ценность. Мы все к этому стремимся. Но если вы говорите это с позиции власти, то в первую очередь добиваетесь лишь сужения спектра возможных вариантов и серьезно затрудняете путь к успеху.

Созидатель или руководитель?

При попытке объединить расписания Созидателя и Руководителя я столкнулся с проблемой организационного плана. Paul Graham говорит (добавлено выделение жирным шрифтом):

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

Короче говоря, фрагментированное, реактивное и наполненное совещаниями расписание руководителя мешает достижению концентрации, необходимой для программирования (которое является разновидностью Deep Work). Можно сказать, что характеристики расписаний руководителя и созидателя являются антагонистами: инженеру нужно, чтобы его как можно меньше отвлекали, тогда как репутация менеджера, не посещающего совещаний или не взаимодействующего с командой, может сильно пострадать по причине «недостаточной заметности».

Не смешивайте эти два вида расписаний

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

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

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

Находясь в роли Созидателя, необходимо стараться избегать любых отвлекающих факторов. Для начала отключите почту. Далее закройте все лишние вкладки в браузере ?—? кхм, Facebook, ?—? или откройте новое окно браузера только для необходимой документации. И последнее: я бы также отключил HipChat/Slack. При этом, безусловно, необходимо оставить какой-то способ связи на случай срочных вопросов и важных людей (вашей команды).

Способность фокусироваться и быть продуктивным в значительной степени зависит от контекста, в котором вы находитесь физически и духовно. Вы можете потратить немало времени, подстраивая свое рабочее окружение (работая за другим столом/из другого места; слушая определенную музыку; делая что-то еще, лишь бы вам помогало), чтобы подобрать нужный контекст, который обеспечивал бы максимальную продуктивность.

В книге Deep Work, которую написал Cal Newport, можно найти много других приемов, позволяющих бороться с проблемой достижения глубокой концентрации (shallow vs deep).

Как не стать бутылочным горлышком

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

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

Ваш код не должен попадать в production

Один хороший друг во время разговора об опытных технических руководителях дал такой совет:

Ты не должен быть бутылочным горлышком в своей команде. Тебе нужно учить и наставлять своих сотрудников так, чтобы они могли справиться со всеми техническими проблемами без твоей помощи. Ты ни в коем случае не должен быть необходим для написания production-кода. Свои программистские навыки ты можешь применить в «грязной» работе, не связанной с функциональностью продукта. Ускорь сборку кода, выдели общие функции в качественную библиотеку. Ищи такие вещи, которые повысят продуктивность команды или просто сделают работу более приятной. Ты можешь поддерживать свою техническую квалификацию путем программирования доказательств концепций (Proofs Of Concepts), исследования новых технологий, которые может использовать команда, или работой над сторонними проектами, делая это совместно с другими сотрудниками или самостоятельно.

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

Чтобы передать свои технические знания, я решаю интересные задачи, программируя в паре, а также провожу «Сеансы чистого кода», на которых все члены команды вместе решают технические проблемы с использованием «программирования толпой» (mob programming) или просто делятся своим мнением и техническими знаниями.

Теперь бо?льшая часть моей программистской работы связана со сторонними проектами. Это касается и Expedia (Expedia Alexa Skill), и моих сторонних проектов, таких как markpress или бесполезное, но симпатичное расширение Rolex GMT Chrome Start tab.

Заключение

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

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

Что еще почитать по теме

• Developer turned manager?—?статья, написанная работающим в Stackoverflow David Haney.
• Average vs Great manager?—?статья, написанная работающим в Facebook Julie Zhuo.
• Maker’s schedule, Manager’s schedule?—?статья, написанная Paul Graham.
• Deep Work?—?книга, написанная Cal Newport.
• Team of Teams: New Rules of Engagement for a Complex World?—?книга, написанная генералом Stanley McChrystal.
• The Principles of Quantum Team Management?—?статья, написанная James Everingham, руководителем технического отдела в Instagram.

Ссылки:

1. Оригинал: From Engineer to Manager: keeping your technical skills.