Я стал техническим руководителем около двух лет назад. За это время одной из самых сложных задач оказалось нахождение баланса между обязанностями руководителя и желанием программировать. Похоже, я не единственный, кто столкнулся с такого рода трудностями, поэтому думаю, что стоит добавить в обсуждение этого вопроса и мои пять копеек. На мой взгляд, идеальными руководителями коллективов, состоящих из инженеров, являются технически компетентные, обладающие практическим опытом менеджеры  (а также те, кому большую часть времени удается избегать Принципа Дилберта).  Технически компетентный руководитель: Думаю, мы сошлись на том, что сохранение и развитие технических навыков является действительно хорошей идеей. Но на этом пути есть серьезные трудности. Первая трудность, с которой вы, скорее всего, столкнетесь, — это конфликт между вашими «я» инженера и наставника. Инженер будет все время хотеть самостоятельно решать интересные технические задачи, а наставник должен стремиться к тому, чтобы поручать эти задачи другим членам команды, повышая тем самым их мастерство. Эта проблема особенно сильно проявляется в командах, где много молодых сотрудников и недостаточно опытных специалистов, которые могли бы учить молодежь. В этой ситуации технический руководитель должен уделять наставничеству особое внимание. На первом месте должны быть ваши люди, а самостоятельное программирование в данном случае вторично. Это необходимое условие: тогда и только тогда, когда ваша команда успешна, вы можете посвятить немного времени программированию. В качестве руководителя вы не занимаетесь созданием продукта, вы создаете команду, которая знает, как создавать продукты. Таким образом, именно успех команды должен быть вашей основной целью и главной метрикой, на основе которой оценивается ваша работа. Если вы руководите успешной командой, состоящей из довольных положением дел инженеров, вы будете тратить меньше времени на совещания с вашими коллегами из других подразделений и руководством, стараясь объяснить или продать им ваши достижения. Самодостаточная команда наделенных полномочиями ответственных профессионалов, где вы не являетесь бутылочным горлышком при принятии решений, позволит вам выделить больше времени на то, чтобы заняться чем-то еще. Еще одной проблемой для меня стало то, что во время обсуждения технических вопросов я слишком много говорил или навязывал команде свою точку зрения. Я не осознавал эту проблему, пока сотрудница не указала на нее во время сессии обратной связи, в которой принимала участие вся команда. Она сказала что-то вроде: «Во время наших технических обсуждений Вы слишком настаиваете на своей точке зрения… Думаю, Вам следует меньше давить на нас, дать нам больше свободы». Некоторые руководители, без сомнения, много говорят, причем достаточно часто с позиции силы. Я же осознал, что это мешает другим высказывать их альтернативные точки зрения либо выражать свое несогласие, что в итоге может привести к принятию менее качественного решения. Что я могу посоветовать? Мне нравится звучание твоего голоса, особенно когда ты заткнулся. Это утверждение настолько важно, что, как сильно его ни выделяй, все равно будет мало. Опытные руководители знают, что каждое сказанное или написанное ими слово потенциально заглушает идеи и предложения членов команды. James Everingham пошел еще дальше и предположил, что, только лишь наблюдая, руководитель уже меняет исход проекта. В своей квантово-механической аналогии (Quantum Mechanics analogy) он пишет: При попытке объединить расписания Созидателя и Руководителя я столкнулся с проблемой организационного плана. Paul Graham говорит (добавлено выделение жирным шрифтом): Короче говоря, фрагментированное, реактивное и наполненное совещаниями расписание руководителя мешает достижению концентрации, необходимой для программирования (которое является разновидностью Deep Work). Можно сказать, что характеристики расписаний руководителя и созидателя являются антагонистами: инженеру нужно, чтобы его как можно меньше отвлекали, тогда как репутация менеджера, не посещающего совещаний или не взаимодействующего с командой, может сильно пострадать по причине «недостаточной заметности». Даже не пытайтесь. Это прямой путь к разочарованию и постоянному ощущению непродуктивности. Как воду и масло, их лучше держать отдельно друг от друга. Я стараюсь разделять эти виды активности естественными перерывами, например, обеденным. Все встречи с моим участием проводятся в первой половине дня, что, конечно, очень утомительно, но позволяет после обеда перевоплотиться в Созидателя и сконцентрироваться на сложных программистских вопросах. Я стремлюсь выполнять это упражнение минимум дважды в неделю. Я также обнаружил, что длительный перерыв на обед и прогулка вне офиса, если это возможно, очень хорошо помогают отключиться, очистить голову от совещаний. После перерыва я возвращаюсь в офис отдохнувшим и готовым к продуктивной работе в качестве программиста. Находясь в роли Созидателя, необходимо стараться избегать любых отвлекающих факторов. Для начала отключите почту. Далее закройте все лишние вкладки в браузере  —  кхм, Facebook,  —  или откройте новое окно браузера только для необходимой документации. И последнее: я бы также отключил HipChat/Slack. При этом, безусловно, необходимо оставить какой-то способ связи на случай срочных вопросов и важных людей (вашей команды). Способность фокусироваться и быть продуктивным в значительной степени зависит от контекста, в котором вы находитесь физически и духовно. Вы можете потратить немало времени, подстраивая свое рабочее окружение (работая за другим столом/из другого места; слушая определенную музыку; делая что-то еще, лишь бы вам помогало), чтобы подобрать нужный контекст, который обеспечивал бы максимальную продуктивность. В книге Deep Work, которую написал Cal Newport, можно найти много других приемов, позволяющих бороться с проблемой достижения глубокой концентрации (shallow vs deep). С учетом напряженного рабочего графика вам, возможно, будет очень непросто выполнять задачи по написанию кода в срок. Это, вероятно, будет приводить к блокированию попадания затронутого функционала в Production. Что еще хуже, в случае возникновения проблем вы можете оказаться заняты другими делами и быть не в состоянии взяться за срочные технические вопросы, такие как, например, неработающая авторизация на сайте или прорыв трубопровода. В качестве лидера команды вы должны в первую очередь ограждать своих сотрудников от отвлекающих совещаний, чтобы они могли сконцентрироваться на программировании. Опять же, ваша работа заключается не в написании кода, а в обеспечении условий, позволяющих команде писать код эффективно. Также очень важно помогать сотрудникам публично рассказывать о своих достижениях. Один хороший друг во время разговора об опытных технических руководителях дал такой совет: Я решил последовать этому совету и очень доволен результатами. Я теперь меньше волнуюсь, зная, что не являюсь техническим бутылочным горлышком. И, что важно, моя команда получила больше возможностей решать проблемы самостоятельно, набирая в процессе бесценный опыт. Чтобы передать свои технические знания, я решаю интересные задачи, программируя в паре, а также провожу «Сеансы чистого кода», на которых все члены команды вместе решают технические проблемы с использованием «программирования толпой» (mob programming) или просто делятся своим мнением и техническими знаниями. Теперь бо́льшая часть моей программистской работы связана со сторонними проектами. Это касается и Expedia (Expedia Alexa Skill), и моих сторонних проектов, таких как markpress или бесполезное, но симпатичное расширение Rolex GMT Chrome Start tab. Быть руководителем, который может писать код, — почти то же, что работать на двух работах. Для этого нужно упорно трудиться, посвящая себя выбранному делу. Велика вероятность почувствовать себя заваленным работой и выгоревшим, в особенности если не соблюдать баланс между руководством коллективом и оттачиванием своих технических навыков. Пожалуй, чтобы совмещение сработало, нужно в одинаковой степени любить руководство людьми и программирование, поскольку это потребует траты большого количества свободного времени на улучшение ваших «я» руководителя и программиста. Но это того стоит! Да и в конечном итоге это же жизнь. Ссылки: CEO в Southbridge