И почему я никогда не думал, что буду здесь

Мой босс: «Ты хочешь быть менеджером?»

Я: «Нет, это звучит ужасно».

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

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

Но сегодня Я стал инженером-менеджером! Что случилось? Эта статья — моя попытка задокументировать перипетии и изменения мышления, которые привели меня к менеджменту.

Почему я не хотел быть менеджером?

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

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

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

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

Менеджер, который разрушил мои упрямые убеждения

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

Стряхнув сонливость с глаз, я запрыгнул на встречу в Zoom. Новый сотрудник представился и объяснил, как он исследовал одну из наших забытых кодовых баз, внося небольшие исправления и разрабатывая план постепенного улучшения системы. Он хотел узнать мою точку зрения, так как я был главным участником. Мы мило поболтали, и у меня остались отличные впечатления от этого нового разработчика.

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

Через полгода он стал моим менеджером.

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

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

Как и почему старший директор инженерного кодирования?

Старший директор, Почему вы программируете?

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

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

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

Г-н старший директор по проектированию постепенно начал пересматривать то, как могла бы выглядеть для меня роль инженера-менеджера.

Медленная трансформация

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

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

И я знал, что мистер Директор может помочь мне понять, как это сделать.

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

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

Поворотный момент

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

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

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

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

  • Пример 1. Инженер из команды 1 мог ускорить свой проект, используя код, созданный инженером из команды 2. Поэтому я их соединил.
  • Пример 2 — Было непонятно, как проводить эксперименты по росту. Я уже знал, как это сделать, поэтому начал документировать свой процесс для обеих инженерных групп.
  • Пример 3 — Ни один из инженеров не был фулстеком, но наша работа была фулстеком. Я наставлял и руководил традиционными фронтенд- и бэкенд-инженерами в построении всего стека.
  • Пример 4 — я представил предложения по инвестированию в инфраструктуру, которая ускорит работу обеих команд.

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

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

В этот момент я начал думать: «Хотел бы я быть менеджером; это было бы намного проще».

Подождите, я все это время занимался управленческой работой?

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

Он сделал несколько наблюдений:

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

«Вы понимаете, что уже руководите этими двумя командами роста?» он спросил.

Я был потрясен. Он воспользовался этим моментом, чтобы задать мне тот же вопрос, что и в начале этой статьи:

Мой босс: «Ты хочешь быть менеджером?»

Я: «Конечно. Может быть. Я не знаю?"

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

Должен ли я быть штатным инженером или менеджером?

Я был в середине цикла обзора производительности, который представлял собой распутье. Меня повысили бы до (официально) штатного инженера или инженера-менеджера. Это был мой выбор.

Но я все еще не знал, что имело для меня большее значение.

Чтобы помочь с моим решением, г-н директор порекомендовал мне прочитать две книги Уилла Ларсона, бывшего инженера-менеджера в Stripe и Uber. Он плодовитый писатель, и две его книги в моем списке для чтения:

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

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

Обновление: вот мои любимые идеи из элегантной головоломки.

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

Я решил стать менеджером

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

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

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

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

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

Почему я всегда буду программировать как менеджер

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

Могут ли менеджеры быть успешными без кодирования? Конечно! Все ли отдельные участники должны становиться менеджерами? Точно нет!

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

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

Вы на том же пути или боретесь с некоторыми из проблем, которые я здесь описал? Дайте мне знать, что вы думаете!