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

Если стратегии в компании отсутствуют

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

Рис. 3.1. Три пересекающиеся стратегии компании

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

Как можно было бы кардинально изменить эту ситуацию? Попытаться научить компанию писать хорошие стратегии, а затем запустить общекорпоративный процесс документирования. Это может сработать, но отложит появление столь нужного вам документа на месяцы, кварталы или годы. Вы сможете двигаться быстрее, если просто напишете стратегию для инженерного подразделения (https://lethain.com/model-document-share), вместо того чтобы пытаться изменить общий подход в компании; если бы команда руководителей считала нужной разработку стратегий так, как было описано выше, это уже было бы сделано.

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

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

• Каковы целевые показатели денежных потоков?

• Как распределяются инвестиции между функциональными подразделениями, например продаж и маркетинга, исследований и разработок, административным?

• Предполагаются ли слияния и поглощения?

• Какова структура бизнес-юнитов? Как они поддерживают друг друга? Как на них распределяются расходы?

• Кто является пользователями вашей продукции, что им нужно и каковы ваши приоритеты по отношению к ним?

• Что станет показателем успеха в следующем году?

• Каковы ваши текущие механизмы дистрибуции и как вы пытаетесь их изменить?

• Каковы наиболее значимые конкурентные угрозы?

• Почему текущая стратегия не работает?

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

Подготовка раздела диагностики

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

Несколько проверенных временем советов по написанию раздела диагностики.

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

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

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

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

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

Структура направляющей политики

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

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

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

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

Обычно мы стремимся поддерживать соотношение 4: 1 между продуктовыми разработчиками и платформенными (безопасность, надежность, инфраструктура, продуктивность разработки). Однако в этом году мы запускаем два крупных проекта без соблюдения этого правила, выделяя в общей сложности 10 инженеров по безопасности (весь доступ к продакшен требует многофакторной аутентификации и привязан к неизменяемому журналу аудита) и повышению продуктивности разработчиков (это вызвано постепенной миграцией всех кодовых баз с JavaScript на TypeScript).

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

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

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

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

Даже самая полная стратегия упустит много важных деталей, но она должна объяснить, как обычно принимаются решения. Подумайте об этом как о сочетании позитивной и негативной свободы (https://lethain.com/company-culture-and-managing-freedoms), а также выстраивании отношений между командами и теми, на кого влияют их решения.

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

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

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

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

Поднимите направляющую политику на должную высоту

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

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

Применимы должны быть не только ценности подразделения (https://lethain.com/setting-engineering-org-values), но и направляющая политика, которая должна являться живым, полезным инструментом. Если вы не можете ее применить, то откажитесь от нее!

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

Мы работаем с SaaS-вендорами, а не создаем собственные платформенные решения, но мы рассматриваем только поставщиков SaaS с текущим соответствием SOC 2[15] Type 2. Решения о сборке или покупке должны приниматься после проверки технических характеристик. Исключения из этой политики должны быть одобрены техническим директором.

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

Здесь трудно привести универсальные советы. Это скорее вопрос, который вы должны задать самому себе: готовы ли вы соблюдать эти принципы во всех ситуациях без исключения? Если нет, поищите другие. Часто неосуществимое можно сделать осуществимым, приписав всего несколько слов, например «если одобрено техническим директором».

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

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

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

Например, Google исторически ограничивал разработку четырьмя языками – Python, C++, Go и Java. Они соблюдают правило довольно строго, и это обеспечивает успех их разработки. Каждый новый проект, реализуемый в этой экосистеме, увеличивает влияние перечисленных инструментов на компанию.

Похожий пример – стратегия Дэна Маккинли (Dan McKinley) «Выбирайте скучные технологии» (Choose Boring Technology, https://mcfunley.com/choose-boring-technology), которая пропагандирует повышение эффективности путем ограничения набора используемых технологий. Это активно применялось в эпоху, когда инженерным направлением Etsy руководил Келлан Эллиот-Маккри (Kellan Elliott-McCrea).

Еще один пример. Инженерная стратегия Uber (в 2014 году) опиралась на ценностный принцип «Дайте строителям строить» («Let builders build»): разрешение командам самостоятельно выбирать те инструменты для работы, которые они считают лучшими. Это было реализовано как за счет отсутствия запретов со стороны технического руководства, так и за счет использования платформы контейнеризации с открытым исходным кодом Docker, которая с легкостью запускала любой контейнер.

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

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

Выбор согласованных действий

Последний компонент вашей инженерной стратегии – это набор согласованных действий по внедрению направляющей политики. Я выделяю три их основные категории.

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

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

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

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

Как происходит переход от текущего состояния к новому? Этот вопрос особенно актуален, когда меняется распределение ресурсов, которое повлияет на людей или команды. В простейшей форме это может быть перенаправление нескольких сотрудников в другой проект на короткий срок, например на квартал. Примером более масштабного преобразования может быть реорганизация инженерного подразделения в целом (https://lethain.com/running-an-engineering-reorg).

В случаях, когда ваша направляющая политика требует перехода с одного технологического стека на другой, например смены основной технологии хранения данных, мы говорим о миграции (https://lethain.com/migrations).

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

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

Разве стратегия не должна быть направлена снизу вверх?

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

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

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

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

Обычно подобные возражения направлены против конкретных стратегий (например, мигрировав на Go, не упустили ли мы определенные возможности? Решает ли использование монорепозитория наши проблемы?). Если вы сможете докопаться до корня беспокойства, то вы почти всегда найдете что-то интересное!

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

Выводы

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

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

Ссылки на дополнительную литературу и ресурсы можно найти на сайте https://lethain.com/eeprimer-refs-3.

Глава 4. Как планировать