company_banner
16 мая в 08:12

Из инженеров в руководители: сохранение технических навыков перевод



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


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


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


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


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


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

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


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


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


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


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


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


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


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


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


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


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


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



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


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


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


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.


Заключение


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


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


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



Ссылки:


  1. Оригинал: From Engineer to Manager: keeping your technical skills.
Автор: @olemskoi Joan Gamell
Southbridge
рейтинг 176,81
Обеспечиваем стабильную работу серверов
Похожие публикации

Комментарии (9)

  • +1
    Сколько я видел такого совмещения — чаще всего это заканчивается «программированием в PowerPoint», иногда — возвращением в «чистые инженеры». Уж больно разное всё — действительно «работать на двух работах», но в одно и то же рабочее время.
    Но кто хочет попробовать — параграф «Ваш код не должен попадать в production» очень полезен.
  • 0

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

  • 0
    является более эффективным наставником команды инженеров и может быть для них примером;
    — Вот это будто с устава воинской службы. Где власть по праву власти, там банальная дедовщина и нежелание работать. От забора и до заката тут не получится

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

    • 0
      Вы правы, там где власть по праву власти — там много неоднозначных моментов. Но автор как раз и пишет, что не стоит использовать брутфорс, а стоит искать более элегантные решения для достижения целей.
  • +2

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


    • Кодер или наставник? — Наставник. Вместо "создания" продукта целью должно быть "создание" людей, команды. Есть огромное желание все сделать самому, и от него надо избавляться путем делегирования заданий.
    • Все чаще себя ловлю на мысли, что важной частью работы компетентного технического руководителя является структурирование и распределение информации. Пришел e-майл извне с даташитом — загрузил в Вики, проинформировал команду. Кто-то из команды сделал отчет — а где запись в баг-трекере с сылкой? Напомнил. У кого-то появилась интересная идея? Записал в таск-лист, чтобы показать на следующем совещании по годовому бюджету. И т.д. и т.п. Программисты — разгильдяи и кто-то за них должен делать и такую работу.
  • 0
    Как ни крути, а быть наставником теряя квалификацию сложно. Двужильным быть надо, но ради чего?
    • 0
      Может «быть наставником сохраняя квалификацию сложно»? А то иначе двужильностью не пахнет))
  • +1
    Про «говорить последним» — полезный совет. При этом очень старый — я помню еще в Цусиме встречал упоминание этой традиции на флоте — первым на важных собраниях (типа решения вопроса о сдаче корабля врагу) всегда выступал самый младший офицер, и дальше по возрастанию званий, чтобы капитан или адмирал не давили младших офицеров своим авторитетом. Вот только до сих пор много кто это правило нарушает, хотя ему получается уже несколько сотен лет.
  • 0
    Из инженеров в руководители: сохранение технических навыков

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


    «Операционные системы: зачем они инженеру»


    30-летие учебного пособия ОС Minix


    Советская вычислительная техника в подготовке ваучерной приватизации РФ в 1992 году

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

Самое читаемое Управление