Каким должно быть техническое лидерство

Перевод: https://firstround.com/review/this-is-what-impactful-engineering-leadership-looks-like/

В 2012 году Джессика МакКеллар вместе с друзьями из MIT запускает стартап скрытого чата Zulip. Спустя почти два года его выкупает Dropbox. И это не было чем-то аномальным. Такое уже происходило ранее, когда также быстро был продан Ksplice компании Oracle. Такая бешеная гонка дала МакКеллар больше разнообразных возможностей управления чем средний инженер может получить за всю свою карьеру. Она была тимлидом, основатель, техническим лидером в огрромной корпорации и сегодня она руководит десятками сотрудников в быстрорастущем международном стартапе. (Кстати она еще и значимая фигура в мире Python).

“Когда инженерное управление правильно осуществляется, вы сосредотачиваетесь на трех важных вещах:

  • вы напрямую поддерживаете членов своей команды;
  • вы управляете исполнением и координируете взаимодействия между командами;
  • делаете шаг назад для наблюдения и развития организации и ее процессов по мере роста”. Это звучит просто, говорит МакКеллар, но каждая из этих областей есть свои глубокие сложности и проблемы. Ниже мы рассмотрим ее действия, которыми она поделилась как оказавшими наибольшее влияние на технических лидеров и людей которыми она управляет.

Что означает прямая поддержка команды

“Когда ты технический руководитель, твоя работа происходит в основном с людьми,” говорит МакКеллар. “Есть две вещи о которых вы всегда должны думать: жизнь людей ежедневная и ежегодичная”. Вы должны представить себе, что каждый человек идет по этим двум путям одновременно. И как лидер вы можете формировать их опыт на каждом из них, помогая найти траекторию, которая соответствует их целям и вашим потребностям.

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

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

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

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

“Чтобы построить долгосрочные отношения с инженером, вы должны узнать о нем достаточно, чтобы создать основу для совместного обдумывания карьерного роста”, говорит она. “Вам необходимо, чтобы сотрудники сформулировали:

  • Навыки которые они хотят улучшить.
  • Технический и не технический опыт который они хотят получить.
  • Как они хотят увеличить свое влияние на компанию.”

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

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

“Чтобы получить эту информацию, вам придется поделить все на более мелкие части. Возможно вы захотите узнать, чем хочет заниматься человек через пять лет, но это очень большой вопрос. И в нем есть еще невысказанное давление, чтобы человек сказал вам, что хочет и дальше работать в этой компании,” говорит МакКеллар. “Единственный вариант, чтобы все это сработало – все должны быть честны и искренни друг с другом. Если вы менеджер, то вы должны задать этот тон. Дайте понять, что для них нормально и безопасно говорить о том, чем они хотят заниматься чем-то другим или работать в другом месте. Я стараюсь представлять это в таком свете: “Все ли мы с компанией Dropbox делаем правильно, чтобы вы получили желаемый опыт для занятия тем, чем вы хотите в будущем?”

МакКеллар говорит, что для того чтобы помочь людям открыться, нужно сначала быть честным в отношении себя и своих карьерных мотивов. Обычно она начинает такие разговоры с того, что на собственном примере рассказывает чего планирует достичь. “Если я спрашиваю людей о следующих пяти годах их жизни, я должна знать, чем я хочу заниматься в это время. Иначе это нечестно.”

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

“В Dropbox мы прошли через это упражнение, и у нас получилось два явных полностью параллельных пути: один для технических специалистов и один для людей заинтересованных в управлении”, – говорит МакКеллар.

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

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

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

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

“У многих компаний нет индикаторов или рамок для распознавания таких мелочей, которые выходят за рамки должностной инструкции,” – говорит МакКеллар. “Очень важно чтобы любые существующие ресурсы для карьерного роста учитывали эти вещи. Если вы не будете их признавать, то люди не будут этого делать. Не будет мотивации и некоторые люди не смогут увидеть для себя будущего в вашей компании, которые бы их воодушевляло.”

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

Возможности вашей команды = Ваша способность к управлению

Почти все руководители инженеров помнят свой поворотный момент – тот самый когда написание кода перестало быть приоритетом номер один. “До перехода в менеджмент я была инженером и техническим руководителем, и я помню те первые моменты, когда мне приходилось искать компромисс между написанием кода самостоятельно и предоставлением возможности это сделать кому-то другому,” – вспоминает МакКеллар. “Есть что-то по-настоящему приятное в непосредственной, личной причастности к написанию кода, работа которого приносит пользователю продукта удовлетворение.”

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

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

В Dropbox у меня была возможность уменьшить масштаб и подумать о том, как осуществляется проектирование в более широком смысле – о том как мы осуществляем планирование, как структурированы в организационном плане, позволяют ли наши инструменты добиться успеха,” – говорит МакКеллар. “Сегодня, если я замечаю неэффективность, у меня есть время, пространство и глобальный контекст, чтобы исправить это.”

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

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

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

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

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

“Я больше не вхожу в команду разработки. Для меня было бы неуместно принимать такие решения” говорит МакКеллар. “Вы должны много доверять чтобы быть максимально эффективным и действенным руководителем. Вы должны доверять своим техническим лидерам, чтобы они могли делать то что считают необходимым для проектирования и масштабирования, а также разбивки сложных проектов на более мелкие составляющие. Безусловно очень заманчиво желание вмешаться в обсуждение архитектуры или код-ревью. Но на самом деле вы должны дать людям возможность и пространство выполнять эти вещи самостоятельно не используя каждрый раз вас как опору для принятия решений. Этой единственный способ двигаться вперед”.

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

Наиболее прогрессивная из этих привычек – особенно в том, что касается неудач – проведение post mortem – поучительного, требующего принятия мер в ближайшее время, анализа неудачи. “Как руководитель, я должна дать команде время и место поразмыслить над тем, почему проект завершился таким образом.” – говорит МакКеллар. “Это не рассказ людям о том, что пошло не так. Допустим, что мы очень сильно нарушили дедлайн по проекту. Нам необходимо потратить время чтобы понять что мы можем сделать по-другому в следующий раз, и какие организационные или процессуальные изменения нам необходимо внести чтобы избежать этого. Я нужна, чтобы способствовать обсуждению и обобщить его таким образом, чтобы его можно было передать другим командам.”

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

“Новые люди действительно привносят свежий взгляд и конструктивно задаются вопросом, как правильно поступать,” – говорит МакКеллар. “Новые инженеры не согласны с тем, что некоторые вещи всегда ломались, и это действительно полезно для вашей организации. С другой стороны, опытные инженеры привносят хорошие привычки и дисциплину в сложные проекты.” У вас всегда будет определенное количество крутых проектов, которые вы будете раздавать. Равномерно распределите их между этими двумя категориями сотрудников.

Вы хотите постоянно повышать уровень всех в своей команде. Мастерство подтянется.

Ускорьте работу людей с помощью правильных инструментов и процессов

Одна из причин, по которой МакКеллар рада работать в Dropbox, – это размер продукта и связанные с ним проблемы. “Мы занимаемся вопросами инфраструктуры и продуктов, с которыми обычно сталкиваются гораздо более крупные компании,” – говорит она. “Это означает, что у каждого инженера Dropbox есть возможность проявить большую заинтересованность и влияние. У нас нет времени заниматься вещами, которые не важны.”

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

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

Маккеллар часто спрашивают, как она может запоминать и следить за всеми целями. Она отвечает так: “Я живу и умираю по своему календарю. Я буквально добавляю календарные события о проверке карьерного роста для каждого человека. Таким образом, я не смогу забыть проверить или подумать об этом”.

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

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

Окружение

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

“Адаптация новых сотрудников – один из самых мощных инструментов в вашем распоряжении как лидера,” говорит МакКеллар. “Вы не только помогаете новым инженерам понять, что они хотят делать и претендовать на право собственности, но и даете существующим сотрудникам возможность наставлять и делиться тем, что они узнали.” Вы не захотите упускать из виду это второе преимущество, потому что именно так вы определяете будущих менеджеров и траектории роста.

Собрания/Планерки/Проверки

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

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

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

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

“По мере того, как люди повышают свой уровень, их потребности постепенно меняются”, – говорит МакКеллар. “С новыми инженерами вы должны активно общаться и выяснять, где они застопорились. Опытные инженеры обычно сами умеют поднимать вопросы.”

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

“Каждый может извлечь выгоду из того, что вы уберете отвлекающие факторы, обеспечите им непрерывное ‘рабочее время’, что поможет устранить неэффективность во внутрикомандном общении”, говорит МакКеллар. “Классический пример – это действительно долгий обмен сообщениями по электронной почтой из-за какой-то технической проблемы без решения. Поместите всех участников обсуждения в одну комнату на 10 минут, и проблема будет быстро решена.”

Прозрачность – серьезный ускоритель, и Маккеллар извлекает из этого выгоду. Хотя некоторые лидеры технологической индустрии считают, что им нужно оградить свои команды от происходящего на уровне руководства, чтобы не отвлекаться, существует тонкая грань между производительной защитой и непреднамеренным отказом инженерам в доступе к информации важной в контексте развития компании. Вы хотите, чтобы они чувствовали себя вовлеченными в развитие компании. “Вообще говоря, инженерам сообщается недостаточно информации, поэтому мой менталитет состоит в том, чтобы раскрывать информацию, которую я имею, на собраниях, проверках, обзорах, когда только я могу. У нас по-умолчанию чрезмерная коммуникация”.

Мотивация

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

“Люди всегда с энтузиазмом относятся к следующему важному делу. Сложнее всего закончить последние 5% проекта, над которым вы работали продолжительное время, – говорит она. – Вот где вам нужен человек, который яростно заинтересован в работе и полностью понимает, откуда вырос Dropbox. Как бренд, мы стремимся всегда поставлять что-то восхитительное, и для этого нужно много смазки для локтей, чтобы доделать эти последние 5%”.

Для того, чтобы люди постоянно были заряжены на достижение целей и выполнение дедлайнов, МакКеллар считает, что менеджеры должны помогать инженерам увидеть свою работу через призму их влияния на компанию. Особенно, если среди них есть те кто ценит свою заметность и рост. “Половина успеха состоит в том, чтобы иметь команду над проектом, которая действительно, заботится о фундаментальной работе, которая потребуется для создания чего-то по-настоящему великого. Другая половина – посвящена признанию. Никто не собирается делать по-настоящему серьезную фундаментальную работу, если о ней никогда не узнают”.

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

В Dropbox большая часть органической мотивации проистекает из того, что компания делает упор на действительно высококачественный и удобный пользовательский интерфейс. По большей части, его конкурентное преимущество состоит в том, что продукт очень прост, легок и “просто работает”. “Это такая ценность, которая облегчает мотивацию последних 5%, потому что именно от них исходит удовольствие пользователя. Вот почему людям нравится этот продукт”.

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

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

Джессика МакКеллар не только управляет командами инженеров в Dropbox, но и является директором Python Software Foundation. Она пишет об этом в своем в Твиттере @jessicamckellar.