С возрастом я всё чаще задумываюсь о том, правильно ли я распоряжаюсь своим временем и помогает ли это продвигаться в карьере и жизни. Этот же вопрос задаёт вам и компания на каждом цикле оценки эффективности: эффективно ли этот руководитель разработки использует своё время, чтобы развивать компанию или своё подразделение?
Парадоксально, но по моему опыту, ответы на эти похожие вопросы почти не пересекаются. В этой статье я рассматриваю оба — в довольно странный момент, в котором мы сейчас живём: менеджерам говорят, что последние десять лет они делали всё неправильно, и теперь им нужно перейти на новую модель управления разработкой, чтобы оставаться востребованными в в сегодняшней реальности рынка.
Когда я начинал карьеру разработчика в Yahoo в конце 2000-х, за два года у меня было всего две встречи встречи один на один (1:1) с руководителем. Первая прошла через несколько месяцев после моего выхода на работу и в основном свелась к вопросам о качестве работы одного из коллег. Вторая — когда я сообщил, что ухожу в другую компанию. По современным меркам такого менеджера бы жёстко раскритиковали, но его стиль управления во многом напоминал подход тимлида из классической книги The Soul of A New Machine: находить важные возможности для команды и снимать организационные барьеры, мешающие их реализации. В контексте, в котором мы тогда работали, он был эффективным менеджером.
Теперь сравните этот стиль с ожиданиями 2010-х, когда в центре внимания оказались привлечение, удержание и мотивация инженеров как ключевые критерии лидерства во многих компаниях. Это было логично для эпохи гиперроста, когда бюджеты практически не ограничивались, а многие компании считали, что их основной барьер роста — это найм сильных инженеров. В тот период менеджерам прямо говорили: первый шаг при переходе в управление — перестать писать код, и это действительно было разумным советом. Сегодня можно утверждать, что по текущим стандартам это было не лучшая рекомендация, но тогда она соответствовала ожиданиям от лидеров.
А теперь посмотрите на текущую эпоху, начавшуюся в конце 2022 года: рост процентных ставок завершил эпоху околонулевых ставок, а продуктовые решения на базе больших языковых моделей (LLM) начали рассматриваться как фактор, способный «сократить» раздутые инженерные структуры. Структуры команд упростились: многие роли, ранее ориентированные на координацию, теперь требуют работы «руками», погружения в детали. И снова: лучшие менеджеры предыдущей эпохи — те, кто делал именно то, чего от них требовала индустрия — теперь воспринимаются как бюрократы, а не как ключевые лидеры.
В каждом из этих переходов менялась бизнес-среда, что приводило к новой формулировке «идеального» лидерства. Это вполне логично: мы ожидаем, что лидеры будут соответствовать актуальным требованиям времени. Странность начинается в тот момент, когда на эти изменения задним числом накладывается некий морализаторский нарратив:
В 2010-х такая история заключалась в том, что главное — это наделение инженеров полномочиями как безусловное благо. Да, это звучит привлекательно, но я не считаю это истинной причиной: всё происходило потому, что рынок найма был перегрет.
В 2020-х «мораль» сместилась: бюрократизированное среднее звено управления якобы сделало организации неповоротливыми и неэффективными, а нехватка экспертов подорвала их результативность. И снова — в этом есть доля правды, но ключевые причины лежат не в морали, а в окончании эпохи нулевых ставок и ожиданиях роста продуктивности за счёт инструментов на базе искусственного интеллекта.
Вывод достаточно очевиден: по мере развития индустрия будет требовать от вас разного и каждый раз объяснять эти изменения некими «глубокими моральными причинами», хотя на деле всё почти всегда сводится к изменениям бизнес-реальности. Если воспринимать текущий морализаторский нарратив как истину, вы рискуете оказаться не у дел через несколько лет, когда всё снова изменится, потому что «хорошее лидерство» — это всего лишь мода.
Саморазвитие в условиях меняющихся управленческих трендов
Если принять тезис о том, что востребованные сегодня управленческие навыки — это результат быстро меняющихся трендов, возникает важный вопрос: какие навыки действительно стоит развивать, чтобы быть эффективным сейчас и оставаться востребованным вне зависимости от этих изменений?
За время работы и взаимодействия с руководителями разработки я пришёл к выводу, что существует восемь ключевых навыков управления. Я бы разделил их на две группы: базовые навыки, необходимые для эффективной работы на любой позиции (включая стартовые управленческие позиции), и продвинутые навыки, от наличия которых зависит, насколько далеко вы сможете продвинуться в карьере.
Базовые навыки
1. Реализация: вести команду к достижению ожидаемых результатов — как осязаемых, так и неосязаемых. В своей основе менеджмент — это про достижение результата, и вы не получите шанс стать менеджером или долго удержаться в этой роли, если ваши команды не выполняют задачи.
Примеры: выпуск проектов, управление дежурствами, планирование спринтов, управление инцидентами.
2. Работа с командой: формировать команду и рабочую среду так, чтобы достигать успеха. Это не работа «на команду» и не работа «на руководство», а поиск баланса между этими сторонами, который работает для обеих.
Примеры: найм, наставничество, управление эффективностью, отстаивание интересов команды перед руководством.
3. Ответственность: уметь работать с реальностью и двигаться вперёд, даже если она сложная. Искать способы довести дело до результата, а не причины, почему это невозможно и кто в этом виноват.
Примеры: браться за сложные задачи, включаться в работу, когда это неудобно, нести ответственность несмотря на системные проблемы.
4. Согласованность: формировать общее понимание между руководством, заинтересованными сторонами, командой и самой задачей. Находить реалистичный план, соответствующий текущей ситуации, без неожиданных сюрпризов для окружающих — и без сюрпризов для себя.
Примеры: документировать нужную информацию, рассказывать о ключевых проблемах и держать команду в курсе дел во время кризисов.
Продвинутые навыки
1. Вкус: способность выносить взвешенные суждения о том, что считать «хорошим» — с точки зрения технологии, бизнеса и стратегии. Это широкое понятие, и по моему опыту, развитый «вкус» является почти универсальным критерием для по-настоящему зрелых управленческих ролей. В каком-то смысле это необходимое условие для принципа Amazon «Are Right, A Lot»
Примеры: доработка продуктовой концепции, избегать рискованных переписываний с нуля, выявлять проблемы удобства использования в результатах работы команды.
2. Ясность: ваша команда, заказчики и руководство понимают, что вы делаете и зачем, и согласны с этим. В частности, они понимают, как вы решаете ключевые проблемы. Ясность — это не «у нас проблемы с масштабируемостью», а «мы делим базу пользовательских логинов на сегменты в новом кластере, чтобы снизить нагрузку».
Примеры: понимание ключевых факторов прогресса, разработка плана выхода из кризиса, демонстрация прогресса по его реализации.
3. Работа с неопределённостью: умение переходить от сложной, неструктурированной проблемы к конкретному и жизнеспособному решению. Если вам дают крайне размытую и открытую задачу, можете ли вы всё равно продвигаться вперёд?
Примеры: запуск нового направления бизнеса, улучшение опыта разработчиков, масштабирование инфраструктуры с одного до нескольких облачных регионов.
4. Работа с временными горизонтами: обеспечивать прогресс как в краткосрочной, так и в долгосрочной перспективе. Есть множество способов выглядеть успешным сегодня, жертвуя будущим. Настоящий успех требует понимания того, как взаимодействуют разные временные горизонты, и готовности нести за это ответственность.
Примеры: наличие чёткого долгосрочного ориентира, выстраивание краткосрочной работы в соответствии с ним, жёсткость в долгосрочных целях и гибкость в краткосрочных решениях.
Потратив достаточно времени на проверку этих идей на практике, я почти уверен, что большинство эффективных менеджеров и их типажей можно уложить в эти категории.
Самооценка по этим навыкам
Не существует идеального способа измерить что-то сложное, но вот набор вопросов, над которыми стоит подумать, оценивая свой уровень по каждому из навыков:
Реализация
Когда в последний раз у вашей команды возникали сложности при выполнении задач? Это повторяющаяся проблема?
Какой сложный проект вы довели до релиза, и он прошёл действительно успешно?
Когда вас в последний раз привлекали к решению срочной задачи, находящейся в фокусе руководства?
Команда
Кого из сильных специалистов вы наняли последним?
Удалось ли вам удержать ваших самых сильных сотрудников?
Какие сильные специалисты хотят попасть в вашу команду?
Кто из коллег считает вашу команду высокоэффективной?
Когда руководитель высшего уровня отмечал вашу команду как выдающуюся?
Ответственность
Когда вам или вашей команде удавалось добиться результата вопреки обстоятельствам? (Согласились бы с этим заинтересованные стороны?)
Какую сложную проблему вы решили так, что она не возникала снова?
Когда вы в последний раз сначала решили проблему, а уже потом разбирались с пробелами между командами?
Согласованность
Когда вас в последний раз удивили действия заинтересованной стороны? Что можно сделать, чтобы это не повторилось?
Как новый участник понимает ваши компромиссы в приоритизации и их обоснование?
Когда вы в последний раз разочаровали заинтересованную сторону, не разрушив при этом отношения?
Какие заинтересованные стороны готовы были бы перейти в вашу компанию, потому что доверяют вам?
Вкус
Какое недавнее решение стало заметно лучше благодаря вашему участию?
Если ваш продакт-менеджер уйдёт, какие решения вам будет сложно принимать?
Какое небольшое уточнение существенно повлияло на архитектуру или запуск?
Как вы повлияли на результаты команды, предвидя развитие событий?
Ясность
В каком сложном выборе вы недавно помогли команде разобраться?
Как вы можете сделать так, чтобы команда могла принимать такие же решения без вашего прямого участия?
Какое принятое вами решение недавно было отменено? Почему?
Работа с неопределённостью
С какой проблемой вы работали, которая до вас «стояла на месте», а после — сдвинулась?
Как именно вам удалось сдвинуть её с мёртвой точки?
Обращаются ли к вам старшие руководители с неструктурированными задачами? Почему?
Работа с временными горизонтами
Какой недавний компромисс вы сделали между краткосрочными и долгосрочными приоритетами?
Как вы принимаете решения с учётом разных временных горизонтов?
Какие долгосрочные цели вы защищаете, жертвуя краткосрочной выгодой?
Большинство этих вопросов не требуют дополнительных пояснений, но стоит кратко остановиться на вопросе «Привлекали ли вас руководители к определённому типу проектов?». По моему опыту, в большинстве компаний топ-менеджеры стремятся «перетянуть» вас на решение своих наиболее важных задач, которые совпадают с вашими сильными сторонами. Поэтому, если вас никогда не пытаются вовлечь, возможны два объяснения: либо вас не считают особенно сильным в этом направлении, либо вы уже настолько загружены, что привлекать вас просто нецелесообразно.
Остаются ли «базовые навыки» неизменными со временем?
Хотя деление на «базовые» и «продвинутые» навыки кажется мне очевидным, в процессе написания я понял, что некоторые навыки со временем переходят из одной категории в другую по мере смены трендов. Например, если сегодня реализация — это фундаментальный навык, то в эпоху гиперроста он играл менее значимую роль, а в период избыточного финансирования — ещё меньшую.
И в этом заключается ключевая сложность для руководителя разработки: чтобы оставаться успешным вне зависимости от трендов, нужно иметь достаточно широкий набор навыков. В противном случае с высокой вероятностью вы будете восприниматься как слабый менеджер, когда очередная эпоха неожиданно закончится.
Сохраняйте энергию, чтобы оставаться вовлечённым
Глава «Управление приоритетами и энергией» в книге The Engineering Executive’s Primer описывает важную мысль, на понимание которой у меня ушло слишком много времени: идеальное распределение задач — это не математически оптимальное распределение, максимизирующее результат. Это баланс между таким «идеалом» и выполнением задач, который позволяет вам быть на том уровне энергии, чтобы оставаться мотивированным на длинной дистанции.
Если вам нравится писать код, это может означать, что вы будете программировать чуть больше, чем объективно полезно для команды. Если вам нравится оптимизировать процессы, это может выражаться в том, что вы будете улучшать неудобный процесс просто потому, что он вас раздражает, даже если он не создаёт значительных потерь эффективности в масштабе всей организации.
Карьера длиной в сорок лет
Подобно тому как важно расставлять приоритеты в задачах, чтобы сохранять энергию, не менее важно понимать, на каком этапе карьеры вы находитесь — эту идею я разбирал в статье «Сорокалетняя карьера».
В каждой роли у вас есть возможность расставлять приоритеты между разными измерениями: темп, люди, престиж, доход или обучение. Здесь нет «правильного решения», и всегда существуют компромиссы. Решения, которые вы принимаете в начале карьеры, накапливаются и влияют на последующие сорок лет. При этом вы ограничены текущими обстоятельствами своей жизни и теми вариантами будущего, которые для вас возможны. В начале карьеры у меня было немного обязательств перед другими людьми, и я мог позволить себе работать на пределе. Сегодня, с большей семейной ответственностью, я не готов регулярно идти на такие компромиссы, и это напрямую влияет на то, какие роли я выбираю и как расставляю приоритеты.
Осознание этих компромиссов и осознанное их принятие — одна из самых ценных вещей, которые вы можете сделать для формирования своей карьеры. И, что ещё важнее, построить долгую карьеру практически невозможно, если не учитывать эти факторы и не обладать достаточными способностями к саморефлексии, чтобы понимать, какие компромиссы позволят вам оставаться вовлечённым на протяжении десятилетий.
Если хочется разобрать подобные вещи не только в теории, но и на практике — через реальные управленческие ситуации, типичные ошибки и рабочие подходы, — приходите на бесплатные вебинары от преподателей курсов Otus. Там как раз про самые болезненные для руководителя разработки темы: делегирование, переход к роли техдиректора и управление тимлидами.
22 апреля, 20:00. «Делегирование без боли: как перестать быть “главным исполнителем” и не скатиться в микроменеджмент». Записаться
29 апреля, 20:00. «Разрешите себе карьеру технического директора». Записаться
30 апреля, 20:00. «Как управлять тимлидами?». Записаться
А системно прокачать менеджерские навыки, освоить продвинутые методы организации процессов и управления командой можно на курсе «Руководитель команд в ИТ». Полный список обучающих программ по управлению смотрите в каталоге.