Рано или поздно большинство разработчиков достигают того момента в своей карьере, когда могут перейти на управленческие позиции. Это может быть должность технического лида, тимлида, руководителя разработки, старшего архитектора, ведущего инженера или другая роль, включающая в себя управление техническими специалистами. Один из вопросов, который задают себе опытные технические специалисты: «Переходить ли мне в менеджмент или стоит остаться на технической позиции?»
Переход в менеджмент часто воспринимается как отказ от технической работы, от того, что вам нравится и в чём вы успешны. Неудивительно, если такой шаг вызывает дискомфорт. Также это решение так или иначе повлияет на отношения с коллегами в компании — как с другими инженерами, так и с менеджерами. Всё это может заставить задуматься о целесообразности перехода.
В этой статье мы обсудим, что побуждает людей становиться лидерами и как они это делают. Также мы выясним, действительно ли переход на руководящую должность означает необходимость навсегда покинуть техническую сферу или существует путь назад в инженерию.
Участники виртуальной дискуссионной панели от InfoQ:
Шона Мартелл, ведущий инженер в Carta
Питер Гиллард‑Мосс, старший менеджер по разработке в DeepL
Бриттани Вудс, старший менеджер по разработке в The LEGO Group
InfoQ: Что побудило вас стать техническим лидером? Вдохновило ли что‑то вас на такой переход в те времена, когда вы были инженером? Были ли вы уверены, что готовы к этой роли?
Шона Мартелл: Когда я начинала работать в IT почти двадцать лет назад, я знала только об одном типе лидерства — управление людьми. О «карьерной траектории отдельного специалиста» я узнала только спустя десять лет работы — к тому времени я дважды побывала на позиции менеджера. Если бы я знала о других вариантах, возможно, выбрала бы другой путь.
Управление людьми — это важная и ценная форма лидерства. Не могу сказать, что когда‑либо чувствовала себя «готовой» к менеджменту или лидерству. Вступление в такую должность даёт почву для проявления синдрома самозванца. Когда мне впервые предложили управленческую роль, я сильно колебалась, но поддержка моего менеджера меня всё‑таки убедила. Это ещё раз доказывает, насколько важны хорошие менеджеры для любой организации.
Но управление и лидерство — это не синонимы. Сейчас моя роль — ведущий инженер, и я являюсь лидером, не будучи при этом менеджером. Я также не чувствовала себя готовой взять на себя эту лидерскую роль, но опять же мне повезло оказаться в окружении людей, которые поддерживали меня и вдохновляли.
Я соглашалась на каждую лидерскую роль, которую мне предлагали, потому что люди, которым я доверяю, побуждали меня это сделать. Я осталась в лидерстве, потому что поняла, что это работа, которая мне действительно нравится.
Лидеры — это организаторы, вдохновители и визионеры. Они используют своё влияние, чтобы сделать окружающих лучше.
Питер Гиллард‑Мосс: Не было какой‑то одной причины. Сначала это была комбинация факторов: я видел в этом возможность карьерного роста и чувствовал, что справлюсь с задачей (можно сказать, это было проявление эго?). В третий раз я колебался, но кто‑то разглядел мой потенциал и убедил меня попробовать.
Мои первые две попытки в роли лидера не были успешными. Я уже был готов отказаться от этой идеи, но третий раз всё было иначе благодаря отличному наставнику, который помог мне справиться с трудностями.
Бриттани Вудс: Для меня одним из самых вдохновляющих аспектов работы ведущим инженером было то, что я помогала окружающим расти и смотрела на проблемы не только через техническую призму, но и с точки зрения того, как они вписываются в общую картину. На этом этапе я уже занималась разработкой дорожных карт, представляла проекты и координировала их с высшим руководством, поэтому чувствовала себя готовой к следующему шагу хотя бы в этом отношении.
InfoQ: Какие навыки или качества, которые у вас уже были как у инженера, помогли вам стать менеджером или техническим лидером? Чего не хватало и что вы развивали в процессе?
Шона Мартелл: Моя первая роль, где лидерство было частью должностных обязанностей, была «гибридной ролью», которую многие компании называют Tech Lead Manager. Я всё ещё отвечала за инженерные задачи, но у меня также появились несколько подчинённых. Я знаю, что такие роли могут вызывать споры, и понимаю почему. Мне было легко тратить много времени на техническую работу, которой я занималась до смены должности — эта работа была для меня привычной, в отличие от управления людьми.
Мой единственный предыдущий опыт управления заключался в том, что мной самой кто‑то управлял. Я не проходила курсы по менеджменту в университете. Думаю, мой путь в управление был типичным: я была высокоэффективным инженером, и в компании появилась управленческая вакансия. Я уже руководила повседневной работой своей команды и распределяла задачи, поэтому добавление обязанностей по управлению людьми стало логичным следующим шагом.
Мне не хватало понимания, как справляться с трудностями управления персоналом. Как помогать решать межличностные проблемы, а не только технические задачи? Я активно искала поддержку у своего менеджера и прочитала множество книг. Сейчас я могу порекомендовать следующие книги: Creating Magic: 10 Common Sense Leadership Strategies from a Life at Disney («Ли Кокерелл: Управляя волшебством. 10 здравых стратегий лидерства») и The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change («Камиль Фурнье: От разработчика до руководителя. Менеджмент для IT‑специалистов») для начинающих менеджеров.
Через несколько лет во время моей второй работы менеджером я стремилась стать директором и понимала, что в этой роли потребуется знание бизнес‑ и финансовых концепций, которые моя степень магистра в области компьютерных наук не могла мне дать. Поэтому я решила поступить в бизнес‑школу и получить MBA. Я не считаю, что всем лидерам обязательно нужно получать бизнес‑образование, но я рада, что сделала это. Даже сейчас, когда я снова перешла на роль исполнителя, знание маркетинга, брендинга и финансовых концепций, которое я получила во время MBA, оказалось для меня крайне полезными.
Питер Гиллард‑Мосс: У отличных инженеров и лидеров есть три общих качества: они хорошие коммуникаторы, знают, как проектировать вещи, чтобы они были простыми, и они отлично распознают проблемы. Инженеры делают это каждый день, работая с кодом. Как я могу сделать намерение этого кода понятным? Как я могу убедиться, что ценность этого метода может работать независимо от ценности другого метода? Как я могу быстро переключаться от некорректного поведения на уровне системы к коммиту, который его вызвал?
Когда вы становитесь менеджером, эти качества становятся вашими сильными сторонами и дают вам реальное преимущество. Вам просто нужно применять их через другую призму. Мы доносим до других наши намерения так же хорошо, как мы передаём их в коде? Мы устранили двусмысленности? У этой команды есть чёткая цель? Является ли эта проблема с поставкой единичным случаем или частью общей закономерности?
Чего обычно не хватает, так это умения адаптировать эти навыки к работе с людьми. Когда у вас есть хороший ответ, компьютеры вам убеждать не нужно — достаточно просто дать им инструкции. С людьми так не работает.
Бриттани Вудс: Я всегда была сильным коммуникатором с умением выстраивать отношения в рамках бизнеса. Для лидера это невероятно полезное качество, так как значительная часть моей работы связана с построением связей с другими командами или заинтересованными сторонами.
Ранее я упоминала, что мне очень нравилось помогать другим развиваться. Когда я была инженером, я регулярно обучала коллег и брала на себя роль наставника в отношениях с другими инженерами. Это также очень полезный навык при переходе на лидерскую роль, потому что, на мой взгляд, здесь дело уже не в вас. Это о том, как вы можете помочь окружающим и вашей команде расти.
InfoQ: С какими трудностями вы столкнулись в роли технического лидера, и как вы их преодолели?
Шона Мартелл: Самым большим препятствием для меня на протяжении всей карьеры был синдром самозванца. Он заставлял меня сомневаться в себе, и этот недостаток уверенности бывало сложно скрыть.
Я справлялась с этим, будучи честной с другими о своих чувствах, и была поражена, как часто встречала людей, которые страдают от того же самого.
Оказалось, что некоторые из тех, кем я искренне восхищаюсь, тоже страдают от синдрома самозванца! Осознание того, что вы не одиноки, является огромным ресурсом, и обращение к этому сообществу за поддержкой в нужный момент может очень помочь.
Питер Гиллард‑Мосс: В роли технического лидера вам придётся работать с людьми из других дисциплин и добиваться включения технических вопросов в решения, которые принимаются за пределами инженерного отдела. Во многих организациях технологии воспринимаются лишь как инструмент, подключаемый на этапе «поставки», без участия в планировании и стратегии.
Вдобавок, общение с инженерами — это ваша зона комфорта...
Однако как технический лидер вы несёте ответственность за качество, скорость изменений и масштабируемость, над которыми вы не имеете прямого контроля, так как они сильно зависят от решений, принимаемых вашими коллегами из других сфер (маркетинг, продукт, финансы, дизайн и т. д.). Мы можем попасть в ловушку, полагая, что должны работать только в рамках этих ограничений, и идти на компромиссы исключительно в рамках инженерных решений.
Единственный способ решить эту проблему — сделать работу инженерного отдела более прозрачной, чтобы другие могли сотрудничать с вами и принимать более качественные решения. Это не значит говорить о техническом долге, чистом коде или рефакторинге. Речь идёт о понимании того, что важно для других, и помощи им в осознании компромиссов, необходимых для достижения их целей. Это означает начинать с того, что, по вашему мнению, правильно, а затем договариваться о компромиссах с обеих сторон.
Здесь уместен ответ Альфреда П. Слоуна молодому Питеру Друкеру: «Моя единственная инструкция для вас — изложите то, что, по вашему мнению, правильно, так, как вы это видите. Не думайте о нашей реакции. Не беспокойтесь о том, понравится нам это или нет. И, что самое главное, не думайте о тех компромиссах, к которым вероятно придётся прибегнуть, чтобы сделать ваши выводы приемлемыми. В этой компании нет ни одного руководителя, который не знал бы, как пойти на любой мыслимый компромисс без вашей помощи. Но он не сможет прийти к правильному компромиссу, если вы сначала не скажете ему, что правильно».
Бриттани Вудс: Женщины в IT, а особенно женщины‑лидеры, сталкиваются со многими трудностями. Думаю, одним из наиболее распространённых вызовов в моей карьере было то, чтобы меня услышали.
Я не гооврю за всех женщин в IT, так как у каждого свой опыт. Но для меня стало очевидным, что люди иногда пытаются перебивать или доминировать в разговорах, особенно если женщины продвигают решение или идею.
Моё решение — постоянно напоминать себе, что я могу уверенно выражать своё мнение, когда это нужно, и занимать своё пространство, как любой другой. В то же время я стараюсь следить за тем, чтобы создавать пространство для других. Если кто‑то из моей команды затрудняется вставить слово или не высказывается по теме, по которой, я знаю, у него есть мнение, я просто спрашиваю конкретно их и даю возможность спокойно ответить. Это работает отлично.
Как лидер, я считаю своим долгом это делать для своей команды и настоятельно рекомендую другим лидерам быть внимательными к тому, чтобы каждый имел возможность быть услышанным. Мне бы хотелось, чтобы этот небольшой жест кто‑то сделал для меня, особенно на ранних этапах моей карьеры.
InfoQ: Как вы руководите высокоэффективными техническими командами? Что, по вашему опыту, работает, а что нет?
Шона Мартелл: Если смотреть на этот вопрос с точки зрения управления, высокоэффективным командам от их менеджеров нужно две вещи:
Защита их времени, чтобы они могли работать над действительно важными задачами.
Устранение помех, чтобы они могли решать эти задачи.
У высокоэффективных команд есть замечательная особенность — они обычно улучшают любую ситуацию. Но это же и одна из самых сложных сторон их работы, потому что они не могут заниматься вообще всем.
Такие команды часто состоят из людей, которые всегда готовы помочь и хотят сделать лучше всё вокруг. Это здорово! Но это также может быть проблемой, потому что все знают, насколько они полезны. Их могут вовлечь во множество проектов, но то, что они могут помочь, не значит, что они должны это делать. Как понять, что действительно заслуживает их времени и внимания?
Решение этой задачи — скорее искусство, чем наука. Будучи хорошим руководителем, вы не можете заниматься микроменеджментом и контролировать каждый их рабочий час, чтобы убедиться, что каждая минута используется «правильно». Вы также не можете просто предположить, что они сами поймут, какие запросы можно игнорировать, или что другие команды будут ценить их время.
По моему опыту, лучше всего работает поддержка прозрачности относительно их времени в том формате, который подходит всей команде. Это может быть еженедельный список задач, которые занимают их время, обновления на еженедельных 1:1 встречах или поддержание актуального тикет‑борда, где видно текущую и предстоящую работу. Неизбежно будут приходить задачи, которые должен решать кто‑то другой. Помогите им как можно быстрее избавиться от таких задач.
Если вы лидер в высокоэффективной команде, ситуация мало чем отличается. Вы, вероятно, лучше понимаете повседневные задачи, чем менеджер, и защита времени команды всё равно останется вашим главным приоритетом.
Высокоэффективные команды также подвержены риску выгорания. Если их время не защищать, они будут испытывать сильный стресс, пытаясь справиться с чрезмерно большим количеством задач.
Ваши команды добьются успеха, если их ресурсы будут правильно распределены и их время будет тщательно охраняться.
Питер Гиллард‑Мосс: Самое важное — это выстраивание доверия. Когда команды доверяют вашим намерениям, вашему мнению и уверены, что вы ставите их интересы на первое место, тогда можно построить высокоэффективную команду.
Без доверия вы давите на «рычаг» и думаете, что это приносит результаты. Поэтому вы жмёте на этот рычаг сильнее, ожидая ещё более впечатляющих результатов. А спустя полгода вы осознаёте, что каждый раз, когда вы нажимали этот рычаг, команда говорила: «хватит уже, мы и так перегружены». Но так как вы их лидер, они не хотят вас расстраивать, и, если не доверяют вам до конца, прибегают к тактике «управление снизу». То есть начинают говорить вам то, что вы хотите услышать, чтобы вы оставили их в покое. Потому что вы причиняете им неудобства, и они боятся, что, если скажут вам об этом прямо, вы сделаете что‑то, что только усугубит ситуацию. Когда такое происходит, вернуться обратно очень сложно.
Бриттани Вудс: Самым важным при руководстве высокоэффективными техническими командами я считаю доверие и прозрачность.
Стараюсь сделать так, чтобы моя команда знала, что я доверяю их профессионализму, их знаниям бизнеса и тому, что они помогут нам найти правильное решение для компании. Мы нанимаем инженеров, потому что верим в их навыки. Приводить их в команду и диктовать шаги, которые они должны выполнить для решения задачи, или, что ещё хуже, давать уже готовое решение, превращая их работу в формальность, — это оскорбление их знаний и опыта.
Что касается прозрачности, я делаю всё, чтобы делиться с командой всей доступной информацией. Это укрепляет их доверие ко мне и гарантирует, что они получили все необходимые данные для принятия лучших решений. Я понимаю, что есть вещи, которые нельзя раскрывать, но если это не конфиденциально и имеет отношение к работе команды, я делюсь этим.
InfoQ: Некоторые инженеры стремятся к роли ведущего инженера, чтобы сохранить техническую составляющую работы и взять на себя лидерские обязанности. Как вы относитесь к таким ролям и какой у вас опыт?
Шона Мартелл: Я работаю ведущим инженером почти три года. Когда ко мне приходит инженер и говорит, что думает о переходе на роль ведущего, это всегда захватывающий разговор. По моему опыту, такая роль — это сдвиг парадигмы в карьере, который отличается от перехода с «технической траектории» на «управленческую».
Моя роль ведущего инженера сочетает в себе то, что часто считается «управлением людьми», и инженерные обязанности. Я участвую в планировании, стратегии и формировании видения продукта — этим занималась, будучи менеджером. Также я занимаюсь архитектурой, разработкой и реализацией решений (хотя реализация занимает у меня меньше времени, чем на предыдущих исполнительских ролях).
Я по‑прежнему много занимаюсь наставничеством и работаю над развитием инженеров и менеджеров, но я не пишу перфоманс ревью, не составляю бюджеты на персонал и у меня нет подчинённых.
Подобная роль не всем подходит. Найти такую позицию, где каждый день можно писать код, сложно. Такие роли существуют, но они редки, по моему опыту. Для меня тип лидерства, который я выполняю в качестве ведущего инженер, — это моя идеальная роль. Я остаюсь вовлечённой в глубокие технические вопросы и решение проблем, одновременно работая над видением и стратегией.
Я советую всем, кто задумывается о том, подходит ли им роль ведущего инженера, обратить внимание на сайт Уилла Ларсона staffeng.com. Я прочитала его книгу в первую неделю работы на позиции ведущего инженера, и это помогло сделать мой переход гораздо более плавным.
Питер Гиллард‑Мосс: Каждый лидер уникален. И люди не остаются статичными на протяжении своей карьеры. Мы не производим детали на заводе с фиксированным набором характеристик, поэтому нужно быть осторожными с созданием процессов, которые загоняют людей в жёсткие рамки и роли.
То же самое касается команд. Единицей эффективности является команда, а не отдельный человек. Всё сводится к тому, чтобы построить правильную команду и создать такое сочетание талантов, где каждый сможет использовать свои сильные стороны. Одной команде может требоваться более технический лидер. Другим может понадобиться лидер, который лучше управляет взаимодействием с заинтересованными сторонами. Ещё одной может быть важна высокая экспертиза в продуктовой области.
На индивидуальном уровне, если у кого‑то есть значительный потенциал, цель состоит в том, чтобы найти для него подходящую возможность, где он сможет оказывать большее влияние и быстрее учиться. Если в данный момент карьеры для этого человека важно оставаться на более технической роли, как можно это организовать? Как вы работаете с его текущей командой или находите новую возможность для него?
Бриттани Вудс: Я считаю, что наличие продуманной системы карьерного роста для инженеров так же важно, как и для тех, кто стремится стать лидером. Когда более опытные инженеры выражают интерес к развитию, я всегда советую им поразмышлять о том, что приносит им удовлетворение в их текущей роли.
Как я уже упоминала, я нахожу удовлетворение в поддержке других с точки зрения взаимодействия с людьми, а также в создании общей картины с технической стороны. Поэтому мой вопрос к инженерам, которые хотят расти: находите ли вы удовлетворение в том, чтобы помогать другим расти, или в решении задач и работе с кодом?
В большинстве случаев, чем дальше вы идёте по пути лидерства в работе с людьми, тем больше вы отдаляетесь от непосредственной работы с кодом и решения реальных технических задач на регулярной основе. Для тех, кто находит в этом удовлетворение, я всегда рекомендую следовать инженерной траектории развития.
InfoQ: Были ли моменты, когда желание вернуться к технической роли становилось особенно сильным? Если да, то как вы с этим справлялись?
Шона Мартелл: В течение своей карьеры я дважды переходила с управления людьми обратно на роль исполнителя, последний раз оставив должность директора, чтобы занять роль ведущего инженера в компании Carta.
Раньше я думала, что мне придётся сделать выбор между технической ролью и лидерством, но оказалось, что это не так. Я полностью поняла это только на своей работе в Carta, где нашла роль, которая позволяет мне совмещать обе сферы. Мне невероятно повезло работать в компании, которая предоставляет мне автономию для реализации крупных проектов, таких как обновление нашего процесса собеседований или создание программы наставничества для инженеров, параллельно с продумыванием архитектуры новых систем. Я понимаю, что такая возможность есть не у всех, и я очень благодарна за неё.
Каждому из нас радость и удовлетворение на работе приносят разные моменты, и важно понять, что именно приносит их вам. Вы можете пробовать разные вещи, которые могут не совсем вам подойти, как это было у меня. Но каждый переход в карьере многому меня научил, и каждый из них был шагом на пути к тому, чтобы я оказалась на месте, где сейчас занимаюсь любимым делом.
Питер Гиллард‑Мосс: Да, такое бывало часто. Я нахожу альтернативные способы удовлетворить эту потребность. Например, я являюсь большим сторонником практики Genba — проведения времени с инженерами, наблюдая за их работой непосредственно в процессе. Это развивает эмпатию и понимание, а также позволяет мне снова ощутить удовольствие от непосредственной работы с технологиями.
Бриттани Вудс: Для меня очевидно, что я на правильном пути, и у меня не было желания вернуться к более технической роли. Думаю, на данном этапе мне удалось сбалансировать необходимость оставаться в технической области через личные проекты, которые помогают мне поддерживать навыки, при этом я занимаюсь тем, что мне действительно нравится.
Я понимаю, почему кто‑то может захотеть вернуться к технической роли, и знаю многих людей, которые переходили от лидерства обратно к роли инженера и снова возвращались в управление. Думаю, всё сводится к балансу между тем, что важно для вас, и тем, что приносит радость. И это нормально, если эти вещи со временем меняются или трансформируются.
Заключение
Разработчики переходят на управленческие позиции, когда их просят об этом или вдохновляют, либо когда появляется подходящая возможность, и они чувствуют готовность к такому шагу. Они используют уже имеющиеся навыки, такие как хорошие коммуникативные способности, опыт в построении отношений, умение проектировать решения и решать проблемы.
Сложности, с которыми люди сталкиваются в управленческой роли, могут варьироваться — от синдрома самозванца до необходимости нести ответственность и быть услышанной, особенно в случае женщин‑лидеров в IT.
Лидеры могут создать высокоэффективные команды, предоставляя им время и пространство для работы, доверяя им и обеспечивая прозрачность, делясь доступной информацией.
На позиции ведущего разработчика вы можете сохранить свои технические навыки и взять на себя лидерские обязанности. Роль ведущего разработчика может стать следующим шагом в карьере для старшего разработчика или подходящей позицией для возвращения к технической работе после управленческой роли.
Всех, кому интересен вопрос управления технической командой, приглашаем на открытые уроки: