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

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

comp@sprintbook.kz

(издательство «SprintBook», компьютерная редакция).

Мы будем рады узнать ваше мнение!

О научном редакторе русского издания

Игорь Курочкин – эксперт в Enabling.team. Помогает развивать инженерную культуру, процессы и практики, платформенные и продуктовые команды в технологических и Enterprise-компаниях. Руководил направлением анализа и технологического консалтинга в Express 42. Работал платформенным и SRE-инженером в Microsoft и Skype, стартапах Qik и Scalaxy. Выступал на конференциях HighLoad, South HUB, AgileDays, TeamLeadConf, DevOpsConf, DevOops.

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

Моя любимая глава в этой книге – третья, в которой обсуждается создание инженерной стратегии. Я также написал главу об этом в своей предыдущей книге «Staff Engineer» (https://staffeng.com). Интересно посмотреть, насколько отличаются эти две главы, несмотря на то что я написал их с разницей всего в три года. Сначала я думал, что это произошло вследствие того, что я стал глубже разбираться в теме, но на самом деле различие более фундаментальное: быть техническим руководителем высшего уровня (executive) – это совершенно иная деятельность, и она заставила меня поменять точку зрения, которая была у меня, когда я работал инженером и техническим менеджером.

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

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

Чем эта книга не является

Если вы ищете подробности о том, как управлять одной отдельно взятой группой инженеров, эта книга не будет для вас самой полезной. В ней не рассматриваются методы проведения еженедельных собраний команды, индивидуальных бесед или оценки сотрудников. Вместо этого она фокусируется на том, как организовать совместную работу многих команд, относящихся к инженерному направлению. А для упомянутых пропущенных тем я от всей души рекомендую книгу Камиль Фурнье «The Manager’s Path»[2] и мою собственную «An Elegant Puzzle»[3].

Данная книга посвящена комплексному инженерно-техническому менеджменту, ориентированному как на технологии, так и на людей. Невозможно говорить об инженерном лидерстве, не затрагивая оба этих аспекта. Если вы ищете книгу, более сосредоточенную на лидерстве в области технологий, читайте «The Staff Engineer’s Path»[4] Тани Рейли или мою «Staff Engineer».

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

Навигация по книге

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

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

Разъяснение терминов

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

Executive (руководитель высшего уровня, или топ-менеджер)

Это функциональный лидер направления для всей компании. Многие компании по-разному называют руководящие должности: например, вице-президентами, несмотря на то что они подчиняются другому руководителю в той же функции – вице-президенты по продукту подчиняются главному директору по продукту (Chief Product Officer). Эти вице-президенты не включены в определение руководителя в данной книге.

Engineering executive (руководитель инженерного подразделения, технический лидер, технический топ-менеджер[5])

Это функциональный руководитель инженерного направления, который отвечает как за технологическую составляющую, так и за управление инженерным персоналом. В зависимости от компании эта должность может называться технический директор (CTO, Chief Technology Officer), вице-президент инженерного направления (Vice President of Engineering) или руководитель инженерного направления (Head of Engineering).

Team (команда)

Термин подразумевает тех, кто подчиняется непосредственно менеджеру.

Organization (организация)

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

Engineering/Engineering organization (инженерное направление, инженерное подразделение, инженерно-технический отдел)

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

Благодарности

Существует удобный миф, что книги пишутся исключительно их авторами. Мой опыт совершенно иной. Формально написал эту книгу я, но фактически она является кульминацией моей карьеры в качестве технического руководителя, десяти лет ведения блога, всего, чему я научился, подготовив две предыдущие книги, тесно сотрудничая с сотнями коллег, благодаря вкладу десятков лидеров отрасли, замечательной команды O'Reilly, помощи Джулии Грейс (Julia Grace), Кевина Стюарта (Kevin Stewart), Тани Рейли (Tanya Reilly), Жасмин Цай (Jasmine Tsai) и Умы Чингунде (Uma Chingunde). Вирджиния Уилсон (Virginia Wilson) заслуживает особого упоминания за исключительно внимательное редактирование этой книги. Наконец, я просто не смог бы создать эту книгу без поддержки моей жены Лорел и нашего сына Эмерсона.

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

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

В этой главе я расскажу:

• как принять решение о том, следует ли претендовать на руководящую должность;

• почему каждая ситуация поиска руководящей должности уникальна и как это повлияет на результат;

• как искать лидерские позиции внутри компании и за ее пределами;

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

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

• как принять решение, стоит ли соглашаться, если вы получили оффер.

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

Зачем становиться руководителем?

Если вы впервые решились на поиск руководящей роли, у вас должен быть четкий ответ на вопрос, который вам будут задавать много раз: «Почему вы хотите стать руководителем?» Важно ответить на этот вопрос в первую очередь самому себе. Если вы не уверены в ответе, потратьте время на обдумывание его до тех пор, пока не добьетесь полной ясности. Возможно, вам поможет подготовленная мною анкета для проверки карьеры (https://lethain.com/career-checkup).

Однозначно правильного ответа нет, но вот несколько примеров от реальных людей:

• «Люблю приобретать новый опыт. Я напрямую подчинялся техническому директору на своих последних двух должностях и хочу сам попробовать себя в этой роли».

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

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

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

Единственный в своем роде

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

Все высшие руководящие посты и процессы являются «единственными в своем роде».

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

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

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

Повышение внутри компании

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

Даже в тех случаях, когда удается получить повышение в собственной компании, добиться успеха оказывается нелегко. Новоиспеченным руководителям приходится продолжать делать то, что они делали раньше, будучи, например, техлидами (https://lethain.com/tech-lead-managers), и одновременно учиться выполнять свою новую работу. Им не избежать столкновений с другими кандидатами на повышение, которые раньше были просто коллегами, а теперь, не получив должность, чувствуют себя обделенными. Нередко эти проблемы становятся причинами увольнений, в результате которых компания остается без своих ключевых лидеров, причем случиться это может в особенно критический для нее момент.

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

Поиск руководящих вакансий в другой компании

Обычно такие вакансии не публикуются на сайте компании. Но прежде чем обсуждать, как подойти к поиску должности, давайте поговорим о том, как организации обычно находят кандидатов на руководящие позиции. Представим, что моя несуществующая компания Monocle Studios (https://lethain.com/monocle-studios) имела бешеный успех и мы захотели нанять нашего первого технического директора (СТО).

Как мы будем искать кандидатов?

1. Рассмотрим внутренних претендентов на эту должность.

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

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

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

5. Найдем компанию по подбору руководителей, которая возьмет на себя все трудности поиска.

Конечно, не каждая компания ищет персонал таким образом, но это самая распространенная модель. Теперь вам, надеюсь, стало проще ответить на вопрос: «Как мне найти свою первую руководящую должность?» Быстрый ответ – связаться с рекрутером, в чьи компетенции входит подбор руководства, в идеале с тем, с кем уже работал кто-то из коллег. Но имейте в виду: при таком подходе вы, скорее всего, столкнетесь с вакансиями, которые по какой-то причине было сложно заполнить.

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

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

Посмотрите на этот конвейер, и вы увидите много способов увеличить свои шансы получить руководящую роль. Вот пара основных: регулярно обновляйте профиль в LinkedIn (https://lethain.com/executive-linkedin-profile) и будьте вежливыми с рекрутерами, которые выходят с вами на связь. Это удивительным образом создает счастливые случайности при поиске работы. Также ваши знакомые должны знать, что вы в поиске. Они могут стать посредниками, если вы лично не знакомы ни с одним рекрутером.

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

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

Собеседование

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

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

Следовательно, во время собеседований на высшую руководящую позицию вас будут оценивать, ориентируясь в большей степени на внешнее впечатление, престиж компании, где вы работали, количество сотрудников, которыми вы управляли, на вашу коммуникабельность и способность разобраться в конкретных проблемах потенциальных подчиненных и коллег. Исходя из этого, мой совет: будьте внимательны к так называемым мелочам. На вопросы отвечайте быстро и вежливо, при ответах в первую очередь рассказывайте о рабочих ситуациях, выполненных задачах и действиях, которые привели к определенным результатам, – используйте метод STAR (Situation, Task, Actions, Results – ситуация, задача, действия, результаты) (https://lethain.com/star-method), чтобы ваши ответы были краткими и организованными; подготовьте вопросы, которые покажут, что вы понимаете, как работает компания, и в целом демонстрируйте энергию и энтузиазм.

Процесс собеседования на руководящие должности обычно выглядит следующим образом.

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

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

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

4. Индивидуальные беседы с обширным кругом руководителей того же уровня и членов команды, которой вы будете управлять. Они сильно различаются в разных компаниях, но в них есть кое-что общее: чаще всего они плохо координируются, например одни и те же темы могут подниматься несколько раз разными собеседниками. Это немного обескураживает. Как правило, это означает, что в компании не хватает человека с нужными авторитетом, опытом и энергией, который бы вложился в проектирование всего цикла отбора и найма. У меня такие интервью превращались в обсуждение общих вопросов, демонстрацию экрана (https://increment.com/teams/do-engineering-managers-need-to-be-technical/), дискуссии по архитектуре и все, что только можно себе представить. Что я могу сказать: двигайтесь вперед в меру своих возможностей.

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

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

• Попросите интервьюера[6] дать обратную связь о вашей презентации до начала сессии.

• Спросите, какие действия других кандидатов были особенно хорошо приняты.

• Обязательно воспользуйтесь полученными советами.

• Определите, чему в презентации вы хотите уделить больше внимания (наиболее важные темы).

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

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

Переговоры об условиях контракта

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

Оплата труда сильно зависит от размера бизнеса и вашего опыта. Лучше всего обратиться к коллегам на схожих должностях и расспросить у них подробности об их компенсациях. Я обнаружил, что люди на удивление охотно делятся сведениями о своих мотивационных пакетах. Также полезно читать отчеты DEF 14A[7] для публичных компаний, в которых раскрывается базовая, бонусная и акционерная части вознаграждения их топ-менеджеров.

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

Доля в собственности компании – опционы

Опционы[8] выпускаются во многих форматах: опционы на акции, RSU (restricted stock unit, «акции с ограничениями») и т. д. У них множество различных условий: периоды вестинга (переход прав на распоряжение активами, обычно четыре года), клиффы (период, в течение которого сотрудник не имеет возможность реализовать право на получение акций, обычно один год) и срок после вашего увольнения, когда вы можете воспользоваться опционами (обычно 90 дней).

Большинство этих условий подлежат обсуждению в момент приглашения на работу, но все зависит от конкретной компании. Вы можете договориться об отмене клиффа и потребовать ежемесячного вестинга сразу после выхода на работу без годичного ожидания, договориться о большем сроке, когда можно воспользоваться опционами после ухода, или попросить компанию выдать вам заем на выкуп опционов, однако это «бесплатное» приобретение будет иметь реальные налоговые последствия (https://fortune.com/2022/03/01/what-happens-to-stock-options-if-bolt-fails-ryan-breslow-startups-venture-capital-frederik-mijnhardt/).

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

Ускоренный вестинг

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

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

Выходные пособия

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

Бонусы

Размер и правила расчета бонуса тоже могут быть предметом переговоров. Бонус, составляющий бо́льшую часть заработной платы, более характерен для специальностей, далеких от инженерии, например для менеджеров по продажам, но, как и всё, это также зависит от компании и ее размера. Технический директор в акционерном обществе может иметь бонус, равный по размеру его зарплате. Технический директор в компании серии C[9] может иметь бонус в размере 20 %. Технический директор в компании с 50 сотрудниками может вообще не иметь бонуса.

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

Отпуск по уходу за ребенком

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

Дата начала работы

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

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

Что еще стоит обсудить перед подписанием контракта

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

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

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

Стоит ли принимать оффер

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

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

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

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

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

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

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

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

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

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

Размышляя над моими рекомендациями, спросите себя: вы все еще настроены решительно? Вы обсудили предстоящую работу хотя бы с двумя друзьями (которые не высказали никаких опасений)? Если ответ на эти вопросы «да», то соглашайтесь!

Вам отказали

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

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

Выводы

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

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

Прочитайте бестселлер «The First 90 Days»[10] Майкла Уоткинса (Michael Watkins), и вы наверняка почерпнете из книги что-то ценное. Я читал. Однако вы можете обнаружить, что его советы слишком универсальны. Да, вам следует разузнать как можно больше. Да, нужно достичь согласованности и договориться о предоставлении ресурсов. Да, необходимо создать команду и сотрудничать с другими отделами и подразделениями.

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

• что нужно изучить в первую очередь;

• почему важно ограничить количество вносимых вами изменений на ранних этапах работы;

• как построить систему доверия и поддержки;

• как оценить, в каком состоянии находится ваше подразделение и как ведется работа (в частности, найм сотрудников);

• как разобраться в технической части, когда у вас мало времени на знакомство с кодовой базой.

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

Что нужно изучить в первую очередь

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

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

2. Что определяет культуру компании? Каковы ее истинные ценности? Какие ключевые решения компания приняла в последнее время? Как на самом деле принимаются решения? Кого ценят и почему? Какие должности имеют вес, а какие нет?

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

4. Насколько эффективно работает инженерная команда и правильно ли поставлены цели? Как идея превращается в готовый результат? Как распределяется работа? Кто принимает меры для устранения последствий экстренных ситуаций?

5. Насколько эффективны используемые технологии? Помогают ли применяемые инструменты команде в ее ежедневной работе? Каковы ключевые технические спецификации (https://lethain.com/reclaim-unreasonable-software)? Какие проекты не выполнены из-за технических ограничений?

6. Можно ли назвать группу инженеров настоящей командой? Кто в ней успешен? Кто не добивается успеха? Почему? Какие усилия предпринимаются по формированию командного духа, и кто за это отвечает? Ценится ли эта работа? Что воодушевляет команду и что обескураживает ее?

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

Для каждого из этих приоритетов определите несколько измеримых целей, которые будут полезны для отслеживания вашего прогресса в перспективе. Установление конкретных целей является частью процесса обучения. Вы можете в качестве метрик использовать количество проведенных экспериментов или другие показатели продуктивности (https://lethain.com/accelerate-developer-productivity). Настроения в коллективе можно оценить в ходе встреч с подчиненными на два уровня ниже без участия их непосредственного менеджера (skip-level), а также путем анонимных опросов, обсуждений за чашкой кофе с группами внутри команды и т. д. Поддерживать оптимальный рабочий темп – это сложно, но вы можете определить, что вы лично можете предпринять и какие методы помогут вам добиться этого. Например, один мой знакомый руководитель рассказал, что ему нужно 30 минут каждый день, чтобы глубоко погрузиться в задачи и не упустить ничего важного. Возможно, вам потребуется что-то другое, и это нормально!

Внедрение правильных системных изменений

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

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

Если бы мне пришлось составить краткий список главных ловушек, в которые попадают новые руководители, то спешка с внесением изменений до понимания сути проблемы, несомненно, стала бы номером один. Две другие частые ошибки – это суждение без понимания контекста («Ах, эта технология ужасна, что за дураки взяли ее?») и воспоминания о прошлых работодателях (раздражающий рефрен «На моей последней работе мы…»).

Учиться – значит размышлять

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

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

Однажды я проходил собеседование в компании, которая давала новым сотрудникам инструмент для поиска компромиссов между упорством и обучением: «правило 20–40». Тратьте не менее 20 и не более 40 минут на решение проблемы, прежде чем попросить о помощи. Я сомневаюсь, что эти цифры идеально подходят конкретно вашей команде, но они дают хороший ориентир: разрешите себе просить своих товарищей о помощи и обещайте, что вы, в свою очередь, потратите время на помощь им.

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

Когда вы заняты решением сложной проблемы (такой, когда ни у кого нет достаточного опыта, чтобы помочь вам с ней), единственное решение – остановиться и подумать. Вы учитесь через размышления (https://lethain.com/offsites), особенно когда дело касается самых сложных проблем и вам приходится бороться с устоявшимися стереотипами в поисках ответов на новые вызовы.

Итак, ловите главный совет: если вы находитесь в быстро меняющейся, сложной ситуации – притормозите! Перестаньте пороть горячку. Не бейтесь в эту стену, в ней нет двери. Так вы никогда не справитесь с глубинными проблемами. Даже если кажется, что надо еще чуть поднажать для достижения результата, помните: это никогда не приведет вас туда, куда вы пытаетесь попасть. (Это похоже на мой аргумент против дежурства по принципу «следуй за солнцем» (https://lethain.com/dont-follow-the-sun).)

А вот заключительный совет людям, которые управляют теми, кто пытается справиться со сложной проблемой: помогите им остановиться, перегруппироваться, создать условия для перерыва, размышлений и роста, чтобы преодолеть преграды! Новые вызовы не заставят себя долго ждать, так что нужно сохранить силы на обратный путь (https://www.youtube.com/watch?v=GM-znjDGubE).

Задачи на первые 90 дней

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

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

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

Обучайтесь и укрепляйте доверие

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

Попросите своего руководителя, генерального или технического директора, четко изложить свои ожидания в отношении вас

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

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

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

Отправьтесь в аудиотур

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

Составьте график личных встреч

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

Расскажите о том, что вы увидели

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

Участвуйте в корпоративных чатах

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

Тикеты группы поддержки клиентов

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

Проводите встречи с клиентами и партнерами, а также пользовательское тестирование

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

Найдите аналитику бизнеса и узнайте, как запрашивать данные

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

Создавайте внешний круг поддержки

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

Поддерживайте связи с людьми, выполняющими схожие обязанности

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

Обратитесь к бизнес-тренеру

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

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

Позаботьтесь о себе

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

У вас может возникнуть соблазн отложить все это на потом, но не поддавайтесь ему. Напротив, воспользуйтесь этим волшебным временем, когда вы начинаете что-то новое и в вашей жизни происходят крупные перемены. Обращение к потенциальному наставнику со словами: «Слушай, я впервые получил работу, с которой ты уже давно и успешно справляешься, и я бы хотел задать тебе пару вопросов!» – помогает на удивление хорошо, особенно если добавить к этому короткие и четкие вопросы.

Управление временем и энергией

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

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

А еще я избавился от ненужных вещей. Выбрасывать хлам из своей жизни – моя стандартная реакция на чувство тревоги, так что за последние три года выбрасывать стало уже нечего: мы даже не смотрим телевизор, с тех пор как родился ребенок. Я полностью переделал свой домашний офис, упростив интерьер настолько, насколько это вообще возможно. Я купил шредер и уничтожил все документы, которые накопил за последние 15 лет. В шифоньере безупречный порядок: все аккуратно разложено по полочкам. Я выбросил старые носки и заменил их все тремя парами: деловыми, короткими и спортивными. Теперь сортировать и складывать носки стало в разы быстрее. «Это действительно важно», – бормочу я себе под нос, пытаясь убедить самого себя.

Хотя я купил пианино и выбросил носки, я вернулся к одной из своих наименее продуктивных привычек: поиску признаков того, что мою работу ценят. Есть ли новые твиты о моих статьях? Сколько у меня подписчиков в Twitter (X)? Каков рейтинг продаж моих книг на Amazon?

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

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

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

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

Разберитесь в организационных процессах

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

Документируйте существующие организационные процессы

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

Внедрите одно-два изменения, но не больше

Когда вы разберетесь в делах, у вас появится длинный список изменений, которые, по вашему мнению, могут помочь вашей команде. Сократите этот список до одного или двух пунктов, обсудите его с коллегами, чтобы интегрировать в рабочие планы, и затем приступайте к реализации (https://lethain.com/good-process-is-evolved).

Запланируйте рост бизнеса на следующий год

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

Настройте каналы коммуникации

Организуйте ежемесячные Q&A встречи, чтобы коллеги могли задавать вам вопросы, начните отправлять еженедельные сообщения по методу «5–15» (https://lethain.com/weekly-updates) (короткие обновления статуса, которые занимают 5 минут на чтение и не более 15 минут на написание), чтобы людям было легче отслеживать прогресс в работе, и настройте списки получателей этой рассылки. Многое будет зависеть от того, какие виды коммуникации приняты в компании, но создайте несколько явных каналов для общения и проинформируйте о них свою команду.

Находите время не только для инженеров

Обычно в составе инженерного подразделения есть специалисты, которые не занимаются напрямую разработкой программного обеспечения, например TPM (Technical Product Manager, технический продакт-менеджер) или SRE-специалист (https://lethain.com/specialized-roles). Уделите им время! Их влияние на процессы часто недооценивается, но оно значительно. Потратьте время на то, чтобы выслушать их.

Проведите выборочную проверку инклюзивности

Когда вы только начинаете работать как руководитель, вам может показаться, что компания поддерживает принципы инклюзивности и наделяет всех работников равными правами, но не делайте поспешных выводов. Проанализируйте компенсации, чтобы понять, не практикуется ли дискриминация по полу, расе и т. д. (https://increment.com/teams/pay-fair/). Познакомьтесь с людьми, которые работают не в офисе, особенно теми, кто постоянно на удаленке.

Выясните особенности найма

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

Как лучше понять процесс подбора персонала?

Отслеживайте показатели воронки найма (https://lethain.com/hiring-funnel) и его процесс

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

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

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

Решите, нужно ли полностью переделать процесс найма

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

Определите, кого в вашей команде не хватает (не более трех позиций)

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

Оффер для перспективных кандидатов

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

Начало работы над имиджем инженерной команды

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

Разберитесь, как организованы рабочие процессы

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

Понаблюдайте за работающими процессами и выясните, масштабируются ли они

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

Установите внутренние метрики продуктивности инженерной команды[11]

Я бы рекомендовал начать с метрик от Accelerate (https://lethain.com/accelerate-developer-productivity), хотя для их применения в некоторых случаях потребуются значительные инвестиции в инструменты и процессы, особенно в мобильной разработке.

Определите внешние метрики продуктивности инженерной команды

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

Рассмотрите возможность внесения небольших изменений в процесс и контроль

Не нужно много изменений, но вот два, которые я предложил бы рассмотреть: включить в план еженедельных совещаний обзор существующих процессов и перейти к такой организационной структуре (https://lethain.com/running-an-engineering-reorg), которая устраняет любые препятствия на пути к выполнению инженерных задач. Если вы вносите структурные изменения, убедитесь, что они просуществуют как минимум год.

Вникните в суть технологии

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

Определите, эффективна ли используемая технология

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

Узнайте, как принимаются важные технические решения

В некоторых компаниях есть группы по обзору технологий или группы архитектуры (https://lethain.com/scaling-consistency), которые принимают важные или требующие обсуждений технические решения, но чаще используются неформальные механизмы. Изучите, как эти процессы работают в вашем новом подразделении.

Создайте простое изменение и внедрите его

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

Поучаствуйте в on-call ротации

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

Посещайте разборы инцидентов

У небольших компаний может не быть программы реагирования на инциденты (https://lethain.com/incident-response-programs-and-your-startup), но, если она есть, эти встречи и последующие отчеты являются исключительно ценным источником информации, и вам следует им воспользоваться.

Восстановите историю принятия технологических решений

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

Задокументируйте существующую технологическую стратегию

Удивительно, но лишь у немногих компаний есть оформленная в письменном виде инженерная стратегия (подробнее об этом в главе 3), поэтому документируйте то, что вы узнали о ней, и делитесь этими заметками с командой – та ли это стратегия, которая вам всем нужна?

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

Выводы

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

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

Как только вы становитесь топ-менеджером инженерного направления, на заднем плане начинает тикать невидимый таймер. Тик-так, тик-так. В конце концов этот таймер сработает, и в этот момент кто-то бросится к вам, требуя инженерную стратегию. Будет непонятно, что они имеют в виду, но они будут хотеть этого… очень, очень сильно. «Если бы только у нас была инженерная стратегия, – их глаза будут умолять вас, – все было бы хорошо». Долгое время эти молящие глаза преследовали меня, потому что я просто не знал, что ответить. Я не знал, что такое инженерная стратегия[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), проявлять любознательность при разрешении конфликтов и выбирать тех поставщиков, чьи продукты максимально функциональны. Эти простые правила значительно облегчили принятие решений, позволив нам сосредоточиться на улучшении продукта и бизнеса. (Если бы я мог вернуться в прошлое, то перенес бы «проявлять любознательность при разрешении конфликтов» из стратегии в наши ценности, но тогда я сделал то, что сделал.)

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

Уверены ли вы в своей диагностике или доверите провести ее консультантам?

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

Готовы ли вы и способны ли реализовать эту стратегию?

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

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

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

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

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

Инженерные стратегии редко документируются, и, к сожалению, это часть более масштабной проблемы: удивительно мало компаний документируют какие бы то ни было стратегии. Это создает серьезные трудности, поскольку невероятно сложно написать эффективную диагностику без понимания других стратегий компании, которые должны учитываться в инженерной, как видно на пересекающихся кругах на рис. 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.

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

Джеймс Карс (James Carse) в своей книге «Finite and Infinite Games»[16] предлагает рассматривать большинство событий в жизни с двух разных точек зрения. Первая – жизнь как серия конечных игр с четкими правилами и конкретными способами победить. Вторая – жизнь как бесконечная игра с правилами, которые со временем пересматриваются ее игроками, и где цель – продолжать играть. Хотя планирование часто воспринимается как конечный процесс со сложными правилами, я считаю гораздо более полезным подходить к планированию как к продолжающейся игре с изменяющимися правилами. Только осознав это, я смог стать эффективным планировщиком.

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

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

• три отдельных этапа планирования: финансовый план, распределение функциональных задач и дорожная карта;

• временну́ю шкалу для трех этапов;

• причины неудач планирования.

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

Процесс планирования по умолчанию

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

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

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

• Команды несут ответственность за выполнение квартального или полугодового плана, используя методы по своему выбору (например, Scrum или Agile).

• Возможен ежемесячный контроль за выполнением планов, например бизнес-ревью (https://infraeng.dev/business-review-template), чтобы отслеживать прогресс в достижении целей компании.

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

Даже в компаниях, где руководство работает добросовестно, может появиться новая информация, которая сделает текущий план недействительным:

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

• финансовый партнер прекратил свою деятельность;

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

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

Три этапа планирования

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

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

Распределите ресурсы вашей компании по направлениям деятельности в соответствии с годовым финансовым планом

Этот план устанавливает цели по доходам и расходам, разбитые по выполняемым функциям и направлениям бизнеса. Из него вы сможете понять соотношение инвестиций в исследования и разработку (R&D); продажи и маркетинг (S&M); общие и административные расходы (G&A), а также увидеть распределение финансов по продуктам или бизнес-юнитам компании.

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

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

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

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

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

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

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

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

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

Этап 1. Составление финансового плана

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

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

Рис. 4.1. Образец финансового плана

Например, образец плана на рисунке 4.1 показывает, что направление бизнеса B2C растет на 31 % в годовом исчислении, у него $133 млн расходов на $625 млн выручки в первом квартале. Напротив, корпоративный сегмент B2B растет гораздо быстрее – на 95 % в годовом исчислении, но имеет $96 млн расходов при $52 млн выручки в первом квартале. Глядя только на эти две строки, можно обозначить очень интересную тему для дискуссии относительно двух направлений бизнеса.

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

• отчет о прибылях и убытках[17] (profit & loss statement), показывающий доходы и расходы с разбивкой по направлениям деятельности и функциям;

• бюджет, более подробно показывающий расходы на поставщиков, подрядчиков и персонал;

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

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

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

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

Как капитализировать затраты на разработку

Капитализация затрат на разработку программного обеспечения – это финансовый вопрос, а не инженерный, его решение обусловлено обязательствами финансовой команды следовать общепринятым принципам бухгалтерского учета, или GAAP (https://www.investopedia.com/terms/g/gaap.asp). Как правило, специалисты финансовой команды не сертифицируют свои ежегодные финансовые аудиты, если только они не следовали GAAP[18], в рамках которого и принимаются решения о том, капитализировать или списывать те или иные понесенные расходы.

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

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

• ее должно быть легко объяснить и обосновать аудитору;

• данные должны быть доступны для подготовки финансовой отчетности финансовым отделом;

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

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

На основе тикетов

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

На основе проектов

Отслеживайте время, затраченное на каждый проект, и определяйте вес капитализации для каждого из них (80 % капитализировано, 0 % капитализировано и т. д.) на основе характера работы. Затем финансовые специалисты объединят это с синтетическими почасовыми затратами на выполнение инженерных задач[19] на основе средней почасовой ставки команды или отдела.

На основе ролей

Установите фиксированный процент времени для каждой роли. Например, 80 % времени продуктового разработчика должно быть капитализировано; 0 % времени инженера по инфраструктуре должно быть капитализировано; и т. д.

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

Роль инженерного направления в финансовом планировании

Инженерное подразделение редко напрямую отвечает за доход компании (хотя почти всегда отвечает косвенно: перед отделом продукта или продаж), поэтому ваш основной вклад в финансовый план – управление расходами (https://infraeng.dev/efficiency).

Я рекомендую разделить эти расходы по направлениям деятельности на три отдельные группы:

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

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

• расходы на разработку (расходы на вендоров и хостинг, связанные с CI/CD; проведение тестирования; среды разработки и т. д.).

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

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

Почему финансовое планирование должно быть ежегодным?

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

Для этого есть три основные причины.

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

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

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

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

Отнесение затрат к бизнес-юнитам

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

Даже самые простые вопросы оказываются неоднозначными, когда вы погружаетесь в их суть. Например, рассмотрим такую компанию, как Figma. У нее есть один основной продукт, но бизнес имеет два подразделения: Enterprise (B2B-продажи крупному бизнесу) и все остальное. Хотя продукт один и тот же в обоих случаях, многие функции, ориентированные на Enterprise, не представляют ценности для других покупателей. В этом случае легко отнести затраты на продуктовых разработчиков, ориентированных на Enterprise, к бизнес-юниту Enterprise, но куда следует относить затраты на разработчиков, создающих основной продукт? Смотреть на доходы? Или отнести все затраты на основной продукт к сегменту non-Enterprise и тем самым искусственно обеспечить высокую рентабельность Enterprise? Другие варианты?

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

Почему финансовое планирование может вызывать столько споров?

Финансовое планирование не является спорным по определению, если управление компанией сосредоточено в руках опытных менеджеров. Однако когда руководители разобщены и не заинтересованы в общем успехе, разнесение расходов становится игрой с нулевой суммой. А еще менеджеры, испытывающие трудности в работе, любят указывать на недостаточный бюджет как на оправдание своей неэффективной работы. Так что процесс планирования может закончиться либо разрушенными отношениями с коллегами, либо неконтролируемыми расходами (https://www.saastr.com/the-biggest-problem-with-mediocre-vps-they-spend-all-the-money).

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

Должен ли рост численности инженерного персонала быть пропорциональным росту численности персонала всей компании?

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

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

Определение организационной структуры

Всякий раз, когда вы говорите, что вам требуется увеличить численность персонала, вы должны иметь документ – проект организационной структуры, в которой будут учтены новые сотрудники. Самый простой способ сделать это – провести математические расчеты (https://infraeng.dev/organizational-design).

1. Разделите общее количество сотрудников на команды по восемь человек (https://lethain.com/sizing-engineering-teams). У каждой из них должны быть менеджер и собственная миссия.

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

3. Продолжайте группировать, пока не дойдете до пяти-семи групп, которые будут подчиняться вам непосредственно. В компании из ~40 инженеров вам нужно сформировать только один уровень групп, но для компании из ~200 специалистов потребуется несколько уровней.

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

Согласование плана найма с возможностями отдела рекрутинга

Последнее, о чем я упомяну, говоря о финансовом планировании, – это привычка руководителей компании тратить время на споры о численности персонала, которая на деле вряд ли будет достигнута. Я считаю чрезвычайно полезным сравнивать количество нанятых в прошлом сотрудников с актуальным планом найма (https://infraeng.dev/recruiter-velocity-check). Если вы увидите, что запланированные цифры сильно больше прошлых значений, то все и так становится понятным.

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

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

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

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

Вендоры обычно ценят следующее:

• деньги, желательно гарантированные;

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

• помощь в достижении ими их внутренних целей, включая выполнение квартальных квот и покупку высокодоходных услуг (вы когда-нибудь задумывались, почему они скорее предпочли бы снизить общую стоимость, чем отменить плату за обучение?);

• иногда – сроки платежей (например, небольшая компания с капиталоемким бизнесом будет ценить авансовый платеж, а не постоплату);

• иногда – совместный маркетинг (если вы поможете привлечь будущих клиентов или инвесторов).

С другой стороны, при пересмотре условий сделок вы обычно ждете от вендоров:

• скидку в зависимости от объема закупки: чтобы их цены снижались, если вы будете покупать больше;

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

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

Общий подход, который я бы рекомендовал, таков.

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

2. Обратите внимание на основные проблемы, которые необходимо решить при продлении контракта, такие как нестабильная работа API или ограничения по скорости.

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

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

5. Получив от вендора цифры в письменном виде, передайте ведение переговоров сотруднику, который будет подписывать контракт, и скажите, что, к сожалению, он перехватил у вас ведение переговоров. (Это может быть формальностью.)

6. Попросите подписывающую контракт сторону оказать давление на поставщика в вопросах ценообразования.

7. Подпишите договор и переходите к решению следующей проблемы!

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

Этап 2. Распределение ресурсов

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

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

На рис. 4.2 показан один из возможных ответов на этот вопрос. Он демонстрирует фиксированные инвестиции в инфраструктуру, увеличивающиеся – в Developer Experience[20] и меняющиеся – в разработку продукта.

Рис. 4.2. Распределение ресурсов по приоритетам

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

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

2. Постоянно обновляйте этот список по ходу выполнения работы и появления новых идей.

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

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

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

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

Зачем нужно функциональное распределение ресурсов?

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

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

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

Поддерживайте стабильность распределения

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

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

Помните о различных степенях детализации

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

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

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

Пример 1

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

Пример 2

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

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

Этап 3. Согласование дорожной карты

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

Дорожная карта терпит неудачу по следующим причинам:

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

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

• смешение в дорожной карте проектов с подтвержденной эффективностью и сырых идей;

• лишение команд автономии из-за слишком детализированного планирования.

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

Дорожная карта автономных планировщиков

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

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

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

Смешение проверенных и сырых проектов

В своей превосходной статье «How to plan?» (https://kellanem.com/notes/how-to-plan) Келлан Эллиот-Маккри (Kellan Elliott-McCrea) делится наблюдениями о том, как часто в процессы планирования активно внедряют новые идеи:

Часто люди, занимающиеся планированием, явно или неявно бросают клич: «Расскажите нам обо всех ваших крутых новых идеях. Нам нужна ваша креативность, чтобы достичь наших целей. Давайте, размахнитесь посильнее! Закидайте нас своими предложениями!» Это ошибка.

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

Два действенных способа избежать такого сценария.

• Распределите инициативы на две группы: с подтвержденной и неподтвержденной эффективностью, а затем расставьте приоритеты в рамках этих групп. Например, вы можете сказать, что 20 % времени продуктовой разработки должно быть направлено на валидацию новых проектов. Затем вы можете обсудить, какие сырые идеи должны получить эти 20 % и отдельно – как инвестировать 80 % времени продуктовой разработки в проверенные проекты.

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

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

Слишком подробная дорожная карта

Последняя проблема дорожной карты, которую я отмечу, заключается в том, что, если вы будете слишком конкретны, то можете случайно лишить команду, ответственную за фактическую работу, инициативы и полномочий. Мелисса Перри (Melissa Perri) очень красочно рассказывает об этом в своей книге «Escaping the Build Trap». Она показывает, как дорожная карта, узко сфокусированная на задачах проекта, а не на желаемых результатах, может ограничивать мышление команд.

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

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

Этапы планирования

Три этапа планирования в календаре обычно выглядят следующим образом.

• Годовой бюджет – готовится в конце предыдущего года.

• Функциональное планирование – должно осуществляться на постоянной основе в течение года.

• Ежеквартальное планирование – за несколько недель до начала каждого квартала (если вы планируете работу не по кварталам, а по полугодиям, готовьтесь к полугодовому планированию за несколько недель до начала полугодия).

График планирования показан на рис. 4.3.

Рис. 4.3. Пример процессов планирования

Очевидно, что конкретные детали будут различаться в разных компаниях, но я не считаю, что это так уж важно. Самое главное, о чем я рекомендую не забывать, – это то, о чем часто говорила Клэр Хьюз Джонсон (Claire Hughes Johnson) (https://press.stripe.com/scaling-people), когда мы работали вместе в Stripe: планирование всегда занимает все отведенное на него время. Если вы выделите на него одну неделю, оно займет одну неделю. Если вы отведете ему один месяц, потратите один месяц. Поскольку планирование – это бесконечное путешествие, лучше не тратить слишком много времени на описание каждого шага.

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

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

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

Ловушки, в которые не стоит попадать

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

Планирование как проставление галочек в чек-листах

Рассмотрим два признака того, что планирование поручено человеку, ориентированному на процесс, а не на результат.

Планирование – это скорее обязательный ритуал, чем часть работы

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