# Уилл Ларсон: «Мы часто относимся к инженерам как к детям, вместо того чтобы дать им ответственность»

Источник: https://www.youtube.com/watch?v=Z9ftpRhRiJE
Канал: Lenny's Podcast
Опубликовано: 07.01.2024

---

В новом выпуске подкаста Ленни Рачитски (Lenny Rachitsky) инженерный лидер Уилл Ларсон (Will Larson), занимавший руководящие посты в Carta, Stripe и Uber, развенчивает миф о необходимости «опекать» разработчиков. Он утверждает, что эпоха избыточного капитала приучила компании относиться к инженерам как к детям, скрывая от них реальные бизнес-проблемы, и призывает к возвращению ответственности и системного подхода в управлении технологиями.

## 📉 Конец «эпохи баловства» и новая реальность инженерного менеджмента
[[JUMP:04:19]]

По мнению Уилла Ларсона, переход от эпохи нулевых процентных ставок (ZERI) к текущему рынку радикально изменил роль инженерного лидера [04:32]. Если 18 месяцев назад менеджеры по найму тратили более 50% своего времени на рекрутинг, проводя до шести интервью подряд [05:00], то сегодня интенсивность найма упала почти до нуля. Это выявило проблему «ложных перформеров»: лидеры, чьим единственным навыком было быстрое масштабирование команд, оказались неэффективны в условиях оптимизации и сокращений [05:37].

Уилл Ларсон выделяет несколько ключевых изменений:

*   **Отказ от «кокона» для разработчиков:** Раньше компании боялись расстроить инженеров, чтобы не спровоцировать их уход к конкурентам [07:19]. Ларсон называет это «отношением как к детям» и считает вредным для профессионального роста.
*   **Возврат ответственности:** Сейчас инженеров начинают воспринимать как полноправных бизнес-партнеров, которых можно и нужно ставить на высшие руководящие роли, не скрывая от них реальные финансовые трудности компании [06:51].
*   **Смена фокуса с роста на эффективность:** Теперь топ-менеджмент оценивает директоров не по количеству нанятых людей, а по умению правильно распределять ресурсы и проводить болезненную консолидацию команд [05:49].

## 🔄 Системное мышление: запасы, потоки и реальность
[[JUMP:08:36]]

Уилл Ларсон является сторонником системного мышления, однако он предупреждает: часто самые умные люди терпят неудачу, потому что их модель системы вступает в конфликт с реальностью [09:03]. По его словам, «реальность никогда не ошибается, ошибается только ваша модель» [10:35].

Для анализа систем Ларсон использует концепцию «запасов и потоков» (stocks and flows), заимствованную из книги Донеллы Медоуз «Азбука системного мышления» [11:40]:

1.  **Запасы (Stocks):** Элементы, которые накапливаются (например, количество инженеров в штате или количество рыбы в озере).
2.  **Потоки (Flows):** Движение между запасами (например, скорость найма или скорость воспроизводства рыбы) [12:06].

Примером применения этого подхода является воронка найма [13:24]:

*   Вместо того чтобы абстрактно жаловаться на «плохих кандидатов», лидер должен разложить процесс на узлы: охват (outreach), конверсия в интервью, процент офферов и процент принятых предложений [13:48].
*   Ларсон утверждает, что часто проблема кроется не в отсутствии кандидатов, а в неспособности менеджеров принять решение («отсутствие убежденности») на этапе оффера [14:40].
*   Использование исторических данных из систем вроде Greenhouse позволяет увидеть реальные разрывы (drop-offs) и лечить причину, а не симптомы [15:31].

## 🏗️ Инженерная стратегия: почему «скучное» — это хорошо
[[JUMP:16:40]]

Ларсон считает, что стратегия в инженерии часто отсутствует в письменном виде, что ведет к хаосу. Он опирается на определение Ричарда Румельта: стратегия состоит из диагноза, направляющей политики и конкретных действий [21:28].

По мнению гостя, лучшие инженерные стратегии часто выглядят «скучно», потому что они построены на жестких ограничениях [19:05]:

*   **Standard Kit (Стандартный набор):** В Carta была введена политика использования только утвержденного стека технологий. Это раздражает инженеров, желающих пробовать новые базы данных, но фокусирует энергию всей компании на решении бизнес-задач, а не на обслуживании зоопарка технологий [19:43].
*   **Кейс Uber (Собственные дата-центры):** В 2014 году в Uber действовала стратегия отказа от облаков в пользу собственного железа [22:07]. Это было неудобно, но позволило компании за 3 месяца развернуться в Китае, обойдя геополитические ограничения облачных провайдеров [22:32].
*   **Кейс Stripe (Монолит на Ruby):** Длительное время компания придерживалась использования монолита, что позволяло инженерам фокусироваться на фичах для пользователей, а не на микросервисной инфраструктуре [23:40].

## ✍️ Инженер как автор: зачем писать 1000 постов за 16 лет
[[JUMP:27:35]]

За свою карьеру Уилл Ларсон опубликовал две книги (готовится третья) и около тысячи записей в блоге [31:02]. Он уверен, что секрет продуктивности в письме — это работа только над тем, что дает энергию [28:38].

Его советы для пишущих инженеров:

*   **Писать для себя, а не для аудитории:** Ларсон не соблюдает график и не пишет ради финансовой выгоды. Он пишет о том, что занимает его мысли в данный момент [29:46].
*   **Совмещение с работой:** Лучший способ найти время — писать о проблемах, которые вы прямо сейчас решаете в офисе. Это превращает письмо в инструмент уточнения мыслей, а не в отдельную нагрузку [36:14].
*   **Правило публикации:** Уилл публикует почти всё, что пишет, не стремясь к идеалу. По его мнению, лучше выпустить «сырой» текст оператора, который учится в процессе, чем бесконечно полировать черновик [38:38].
*   **Карьерный рычаг:** Если цель — карьерный рост, достаточно написать 2-3 глубоких, качественных материала, а не вести еженедельную рассылку [38:11].

## 🤝 Тандем EM и PM: радикальный подход к KPI
[[JUMP:41:15]]

Конфликты между инженерией (EM) и продуктом (PM) часто возникают из-за невидимых ограничений. Уилл Ларсон предлагает необычное решение, которое практикуется в Carta: **инженерный менеджер и продукт-менеджер получают одинаковую оценку эффективности (performance rating)** [45:32].

Логика этого подхода:

*   Это заставляет пару работать как единое целое, а не перекладывать вину [46:11].
*   Они вместе несут ответственность за компромисс между скоростью выпуска фич и техническим долгом.
*   В Carta СЕО Генри Уорд (Henry Ward) продвигает идею «трифекты» (EM, PM и бизнес-лидер), где все трое оцениваются по общей способности решать ограничения системы [45:06].

## 📊 Измерение продуктивности без «фейковых» метрик
[[JUMP:48:34]]

На вопрос о том, как измерить скорость работы инженеров, Ларсон отвечает, что бенчмаркинг от венчурных капиталистов часто бесполезен для управления — он нужен лишь для того, чтобы «совет директоров меньше злился» [50:05].

Основные тезисы по метрикам:

*   **DORA и Accelerate:** Метрики из книги «Accelerate» (время выполнения, частота деплоев, время восстановления) хороши для диагностики инфраструктуры, но они не говорят, является ли компания успешной [53:11].
*   **Демонстрация «мяса»:** Самый эффективный способ доказать продуктивность — показать список значимых, сложных задач, выполненных за последние 6 месяцев. Если списка нет — у команды проблемы [52:18].
*   **Интуиция лидера:** Хороший лидер узнает о проблемах, просто разговаривая с инженерами. Они всегда знают, где процесс «тормозит» [50:43].
*   **Обучение через метрики:** Метрики нужны не для «идеальных данных», а для того, чтобы на их примере объяснять руководству нюансы инженерной работы [54:59].

## 💎 Как создавать ценности, которые работают
[[JUMP:56:03]]

Уилл критикует практику «карго-культа», когда компании копируют ценности Facebook или Amazon [56:16]. По его мнению, рабочие ценности должны обладать тремя свойствами:

1.  **Честность (Honesty):** Они должны описывать то, что вы реально делаете, а не то, кем хотите казаться [57:33].
2.  **Применимость (Applicability):** Они должны помогать принимать решения в спорных ситуациях (например, «оптимизировать глобально» против «действовать в интересах команды») [58:14].
3.  **Обратимость (Reversibility):** Хорошая ценность имеет жизнеспособную противоположность. «Мы пишем хороший софт» — плохая ценность, так как никто не скажет: «Мы пишем плохой софт». А вот «Мы работаем как спортивная команда, а не как семья» (Netflix) — отличный пример [1:00:15].

## 💥 Провал Digg v4: суши, шампанское и смерть проекта
[[JUMP:1:02:14]]

Уилл Ларсон поделился историей «смертельного марша» при запуске четвертой версии Digg. Чтобы конкурировать с Facebook и Twitter, компания решилась на полную перезапись платформы — решение, которое, по словам Ларсона, «никогда не срабатывает» [1:03:52].

*   **Атмосфера катастрофы:** В день запуска в офисе были официанты с суши и шампанским, но сайт лежал [1:02:56]. Он оставался в полурабочем состоянии почти месяц [1:08:43].
*   **Технический нюанс:** Одной из причин падения серверов каждые 12 часов была глупая ошибка в коде на Python, связанная с инициализацией переменных в параметрах по умолчанию [1:06:04]. Код писал человек, не знавший Python, и никто не заметил этого на ревью [1:06:17].
*   **Итог:** Несмотря на героические усилия инженеров (Ларсон и коллега написали систему кэширования с нуля за два дня), бизнес не оправился. Через 9 месяцев команда сократилась со 100 до 30 человек [1:06:58]. Тем не менее, именно этот опыт сделал Уилла руководителем в рекордно короткие сроки, так как все остальные «умные люди» уволились [1:07:25].