Технический директор. Эффективное техническое лидерство

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

Долгие годы я работал над уточнением этого понятия. Результаты вы можете увидеть в приложении Д этой книги (где описывается амбициозный подход к достижению баланса между технической стандартизацией и исследованиями) и в руководстве по написанию инженерной стратегии (https://staffeng.com/guides/engineering-strategy) (которое я переписывал четыре раза с нуля).

Короче говоря, инженерная стратегия – это документ, который определяет:

• как распределяются инженерные ресурсы в зависимости от приоритетов компании;

• какие правила должны соблюдать инженерные команды;

• как принимаются решения в технической области.

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

• определение стратегии, данное Ричардом Румельтом (Richard Rumelt) и включающее диагностику, направляющую политику и согласованные действия;

• пример инженерной стратегии;

• методы написания собственной инженерной стратегии;

• работу с недокументированными стратегиями в других областях;

• способы диагностики потребностей и ограничений вашего подразделения;

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

• поддержание стратегии на высоком уровне: вам предстоит убедиться, что ее базовые принципы применимы, соблюдаются и влияют на достижение результата;

• наиболее распространенные виды согласованных действий в инженерных стратегиях;

• подходы к разработке стратегии: сверху вниз или снизу вверх.

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

Определение стратегии

Книга Ричарда Румельта «Good Strategy, Bad Strategy»[13] – самая понятная книга о стратегии из всех мною прочитанных, и я многому из нее научился. Самое главное – она дает краткое и полезное определение рассматриваемого понятия. По мнению Румельта, стратегия состоит из трех частей.

Это теория, описывающая природу проблемы. Ее цель – определить первопричины сложившейся ситуации. Хороший пример такой диагностики: «Большой объем незавершенной работы мешает нам закрывать задачи, поэтому мы все больше отстаем от графика».

Это подходы, которые вы будете применять, чтобы справиться с проблемой. Направляющая политика может включать неявные или явные компромиссы. Например, она может быть такой: «Нанимать новых сотрудников только в команду, выполняющую самый срочный проект с самой острой потребностью в персонале; не распределять новый персонал по всем командам». Если направляющая политика не подразумевает компромисса, вы должны отнестись к ней с подозрением (например, «работать лучше, чтобы сделать это» не является направляющей политикой).

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

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

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

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

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

Пример стратегии

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

Вот основные факторы (мы определили их путем диагностики нашего нынешнего положения), которые мы хотим учитывать в своей стратегии.

• Мы поддерживаем три направления бизнеса (с покупателями-физлицами, или B2C, коммерческие отношения с юрлицами, или B2B, и инновации). Около 80 % дохода поступает от B2C, а 20 % – от B2B. Инновации делаются в расчете на будущие доходы. В этом году мы ожидаем значительного роста доходов в B2B; роста доходов менее чем на 15 % в B2C; и мы считаем, что есть небольшая, но реальная вероятность получения сверхдоходов от инновационных продуктов в ближайшие 3–5 лет.

• Мы являемся инженерным подразделением со штатом в 350 человек (300 инженеров, 40 менеджеров и 10 технических менеджеров программ) и планируем оставаться на самоокупаемости при условии сохранения численности персонала.

• Проблема номер один, снижающая продуктивность разработчиков, как показал наш последний опрос (https://infraeng.dev/developer-survey), – хрупкие (нестабильные) тесты. Кроме того, наши дашборды показывают, что стабильность тестов снизилась примерно на 40 % в годовом исчислении, что приводило к сбою в каждом третьем случае.

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

Наша направляющая политика в сложившихся обстоятельствах:

• Мы поддерживаем соотношение продуктовых разработчиков и инженеров по инфраструктуре 4 к 1. Оно было таковым в течение последних нескольких лет и работало довольно хорошо, поэтому мы намерены его сохранить. Для нашего следующего обновления стратегии мы намерены более точно определить соотношение инженеров по безопасности и дата-инженеров, чтобы точнее подбирать штат для этих направлений.

• 45 % наших ресурсов по разработке продуктов ориентированы на B2B, 3 % – на B2C и 10 % – на инновации. Оставшиеся ресурсы распределены следующим образом: 10 % будут в течение года сосредоточены на повышении продуктивности разработчиков (в частности, это выделение 10 % времени в существующих командах для повышения продуктивности разработчиков, а не на набор новых людей). По сравнению с прошлым годом мы на 20 % увеличиваем ресурсы в секторе B2B, поскольку видим там значительный рост доходов, а восстановления роста в B2C не наблюдаем. Мы хотим поддерживать постоянные инвестиции в инновации, хотя этот сегмент пока не показал значимых успехов, чтобы обосновать выделение его в отдельное бизнес-направление.

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

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

• Если что-то неясно, кажется рискованным или есть существенные разногласия, готовится ревью проблемы, технической или организационной, и передается вверх по цепочке управления. Если в ответ не поступило письменного указания, если кто-то не согласен с предложенным решением или если непонятно, кто отвечает за сложившуюся ситуацию, следует обратиться к руководству! Эскалации[14] часто рассматриваются как «негативные» или «враждебные», но мы отказываемся от таких оценок. Эскалации являются естественной частью совместной работы и позволяют нам принимать быстрые и эффективные решения. Не следует с этим затягивать, оправдывая себя тем, что процесс по своей природе медленный. Задержки возникают тогда, когда мы сами (в процессе технического ревью или менеджменте) действуем медленно.

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

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

• Внедрить структурные изменения для перевода 10 % ресурсов разработки продукта из потребительского сегмента в B2B. Это поддержит рост доходов в той части бизнеса, которая ориентирована на юрлиц. Предстоит переместить несколько команд между подразделениями. Также будет переведено небольшое количество отдельных сотрудников. Эти действия смещают фокус нашего внимания в сторону B2B.

• Создать рабочую группу по повышению стабильности тестов и улучшать этот показатель. Как прописано в недавно обновленной документации по этой проблеме, в этом году мы посвятим ей 10 % времени разработки продукта. Над этим также будут работать инфраструктурные инженеры, причем это будет третьей задачей после безопасности и общей стабильности работы.

• Улучшить процесс технического ревью (tech spec review, TSR): теперь мы добавляем в него немного асинхронности. Мы просим специалистов брать на себя больше задач и предоставляем им 1–2 недели, чтобы подготовить развернутый отчет по поступающим к ним вопросам. Теперь мы просим размещать все запросы в чате, после чего они будут обрабатываться немедленно и асинхронно, если это возможно, и мы стремимся к тому, чтобы только сложные темы выносились на еженедельную сессию. Мы также намерены расширить штат сотрудников, занимающихся TSR, в течение следующих четырех недель; так что ждите скорых апдейтов.

Если у вас есть вопросы по инженерной стратегии, мы обсудим их на следующем мероприятии «Вопросы и ответы» в среду, а также вы можете задавать вопросы с хештегом #eng-ask-anything в любое время!

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

Процесс создания стратегии

В своей книге «Staff Engineer» я сравнил написание инженерной стратегии с историческим изысканием. Посмотрите, как все работает, запишите это и покажите другим то, что вы написали.

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

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

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

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

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

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

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

Составьте актуальную дорожную карту, проанализируйте конкурентов и финансовый план. Если у вас есть данные опросов, посвященных корпоративной культуре или продуктивности разработчиков (https://infraeng.dev/developer-survey), включите эти результаты. Добавьте все проблемы, о которых вы узнали во время встреч 1:1 и собраний команды. Помните, что нужно доверять своему собственному суждению: вас назначили возглавлять инженерное подразделение не за красивые глаза. Вместе с тем не полагайтесь только на себя. После того как вы составили черновик раздела диагностики, обсудите его с членами вашей рабочей группы. Я бы рекомендовал делать это один на один с каждым участником, так легче получить прямую обратную связь. Встретьтесь с одним человеком, выслушайте его мнение, затем включите это мнение в драфт, прежде чем обсуждать раздел со следующим коллегой. После всех итераций поделитесь финальным вариантом со всей рабочей группой, прежде чем двигаться дальше.

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

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

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

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

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

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

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

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

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

Вскоре после прихода в Calm я открыл документ, озаглавленный «Инженерная стратегия», и передо мной разверзлась бездна, так что я предпочел сразу же закрыть его. Год спустя я вернулся и записал три основных руководящих принципа: выбирать скучную технологию (https://mcfunley.com/choose-boring-technology), проявлять любознательность при разрешении конфликтов и выбирать тех поставщиков, чьи продукты максимально функциональны. Эти простые правила значительно облегчили принятие решений, позволив нам сосредоточиться на улучшении продукта и бизнеса. (Если бы я мог вернуться в прошлое, то перенес бы «проявлять любознательность при разрешении конфликтов» из стратегии в наши ценности, но тогда я сделал то, что сделал.)

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

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

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

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

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