В новом выпуске подкаста Ленни Рачитски (Lenny Rachitsky) инженерный лидер Уилл Ларсон (Will Larson), занимавший руководящие посты в Carta, Stripe и Uber, развенчивает миф о необходимости «опекать» разработчиков. Он утверждает, что эпоха избыточного капитала приучила компании относиться к инженерам как к детям, скрывая от них реальные бизнес-проблемы, и призывает к возвращению ответственности и системного подхода в управлении технологиями.
📉 Конец «эпохи баловства» и новая реальность инженерного менеджмента 4:19
По мнению Уилла Ларсона, переход от эпохи нулевых процентных ставок (ZERI) к текущему рынку радикально изменил роль инженерного лидера . Если 18 месяцев назад менеджеры по найму тратили более 50% своего времени на рекрутинг, проводя до шести интервью подряд , то сегодня интенсивность найма упала почти до нуля. Это выявило проблему «ложных перформеров»: лидеры, чьим единственным навыком было быстрое масштабирование команд, оказались неэффективны в условиях оптимизации и сокращений .
Уилл Ларсон выделяет несколько ключевых изменений:
- Отказ от «кокона» для разработчиков: Раньше компании боялись расстроить инженеров, чтобы не спровоцировать их уход к конкурентам . Ларсон называет это «отношением как к детям» и считает вредным для профессионального роста.
- Возврат ответственности: Сейчас инженеров начинают воспринимать как полноправных бизнес-партнеров, которых можно и нужно ставить на высшие руководящие роли, не скрывая от них реальные финансовые трудности компании .
- Смена фокуса с роста на эффективность: Теперь топ-менеджмент оценивает директоров не по количеству нанятых людей, а по умению правильно распределять ресурсы и проводить болезненную консолидацию команд .
🔄 Системное мышление: запасы, потоки и реальность 8:36
Уилл Ларсон является сторонником системного мышления, однако он предупреждает: часто самые умные люди терпят неудачу, потому что их модель системы вступает в конфликт с реальностью . По его словам, «реальность никогда не ошибается, ошибается только ваша модель» .
Для анализа систем Ларсон использует концепцию «запасов и потоков» (stocks and flows), заимствованную из книги Донеллы Медоуз «Азбука системного мышления» :
- Запасы (Stocks): Элементы, которые накапливаются (например, количество инженеров в штате или количество рыбы в озере).
- Потоки (Flows): Движение между запасами (например, скорость найма или скорость воспроизводства рыбы) .
Примером применения этого подхода является воронка найма :
- Вместо того чтобы абстрактно жаловаться на «плохих кандидатов», лидер должен разложить процесс на узлы: охват (outreach), конверсия в интервью, процент офферов и процент принятых предложений .
- Ларсон утверждает, что часто проблема кроется не в отсутствии кандидатов, а в неспособности менеджеров принять решение («отсутствие убежденности») на этапе оффера .
- Использование исторических данных из систем вроде Greenhouse позволяет увидеть реальные разрывы (drop-offs) и лечить причину, а не симптомы .
🏗️ Инженерная стратегия: почему «скучное» — это хорошо 16:40
Ларсон считает, что стратегия в инженерии часто отсутствует в письменном виде, что ведет к хаосу. Он опирается на определение Ричарда Румельта: стратегия состоит из диагноза, направляющей политики и конкретных действий .
По мнению гостя, лучшие инженерные стратегии часто выглядят «скучно», потому что они построены на жестких ограничениях :
- Standard Kit (Стандартный набор): В Carta была введена политика использования только утвержденного стека технологий. Это раздражает инженеров, желающих пробовать новые базы данных, но фокусирует энергию всей компании на решении бизнес-задач, а не на обслуживании зоопарка технологий .
- Кейс Uber (Собственные дата-центры): В 2014 году в Uber действовала стратегия отказа от облаков в пользу собственного железа . Это было неудобно, но позволило компании за 3 месяца развернуться в Китае, обойдя геополитические ограничения облачных провайдеров .
- Кейс Stripe (Монолит на Ruby): Длительное время компания придерживалась использования монолита, что позволяло инженерам фокусироваться на фичах для пользователей, а не на микросервисной инфраструктуре .
✍️ Инженер как автор: зачем писать 1000 постов за 16 лет 27:35
За свою карьеру Уилл Ларсон опубликовал две книги (готовится третья) и около тысячи записей в блоге . Он уверен, что секрет продуктивности в письме — это работа только над тем, что дает энергию .
Его советы для пишущих инженеров:
- Писать для себя, а не для аудитории: Ларсон не соблюдает график и не пишет ради финансовой выгоды. Он пишет о том, что занимает его мысли в данный момент .
- Совмещение с работой: Лучший способ найти время — писать о проблемах, которые вы прямо сейчас решаете в офисе. Это превращает письмо в инструмент уточнения мыслей, а не в отдельную нагрузку .
- Правило публикации: Уилл публикует почти всё, что пишет, не стремясь к идеалу. По его мнению, лучше выпустить «сырой» текст оператора, который учится в процессе, чем бесконечно полировать черновик .
- Карьерный рычаг: Если цель — карьерный рост, достаточно написать 2-3 глубоких, качественных материала, а не вести еженедельную рассылку .
🤝 Тандем EM и PM: радикальный подход к KPI 41:15
Конфликты между инженерией (EM) и продуктом (PM) часто возникают из-за невидимых ограничений. Уилл Ларсон предлагает необычное решение, которое практикуется в Carta: инженерный менеджер и продукт-менеджер получают одинаковую оценку эффективности (performance rating) .
Логика этого подхода:
- Это заставляет пару работать как единое целое, а не перекладывать вину .
- Они вместе несут ответственность за компромисс между скоростью выпуска фич и техническим долгом.
- В Carta СЕО Генри Уорд (Henry Ward) продвигает идею «трифекты» (EM, PM и бизнес-лидер), где все трое оцениваются по общей способности решать ограничения системы .
📊 Измерение продуктивности без «фейковых» метрик 48:34
На вопрос о том, как измерить скорость работы инженеров, Ларсон отвечает, что бенчмаркинг от венчурных капиталистов часто бесполезен для управления — он нужен лишь для того, чтобы «совет директоров меньше злился» .
Основные тезисы по метрикам:
- DORA и Accelerate: Метрики из книги «Accelerate» (время выполнения, частота деплоев, время восстановления) хороши для диагностики инфраструктуры, но они не говорят, является ли компания успешной .
- Демонстрация «мяса»: Самый эффективный способ доказать продуктивность — показать список значимых, сложных задач, выполненных за последние 6 месяцев. Если списка нет — у команды проблемы .
- Интуиция лидера: Хороший лидер узнает о проблемах, просто разговаривая с инженерами. Они всегда знают, где процесс «тормозит» .
- Обучение через метрики: Метрики нужны не для «идеальных данных», а для того, чтобы на их примере объяснять руководству нюансы инженерной работы .
💎 Как создавать ценности, которые работают 56:03
Уилл критикует практику «карго-культа», когда компании копируют ценности Facebook или Amazon . По его мнению, рабочие ценности должны обладать тремя свойствами:
- Честность (Honesty): Они должны описывать то, что вы реально делаете, а не то, кем хотите казаться .
- Применимость (Applicability): Они должны помогать принимать решения в спорных ситуациях (например, «оптимизировать глобально» против «действовать в интересах команды») .
- Обратимость (Reversibility): Хорошая ценность имеет жизнеспособную противоположность. «Мы пишем хороший софт» — плохая ценность, так как никто не скажет: «Мы пишем плохой софт». А вот «Мы работаем как спортивная команда, а не как семья» (Netflix) — отличный пример .
💥 Провал Digg v4: суши, шампанское и смерть проекта 1:02:14
Уилл Ларсон поделился историей «смертельного марша» при запуске четвертой версии Digg. Чтобы конкурировать с Facebook и Twitter, компания решилась на полную перезапись платформы — решение, которое, по словам Ларсона, «никогда не срабатывает» .
- Атмосфера катастрофы: В день запуска в офисе были официанты с суши и шампанским, но сайт лежал . Он оставался в полурабочем состоянии почти месяц .
- Технический нюанс: Одной из причин падения серверов каждые 12 часов была глупая ошибка в коде на Python, связанная с инициализацией переменных в параметрах по умолчанию . Код писал человек, не знавший Python, и никто не заметил этого на ревью .
- Итог: Несмотря на героические усилия инженеров (Ларсон и коллега написали систему кэширования с нуля за два дня), бизнес не оправился. Через 9 месяцев команда сократилась со 100 до 30 человек . Тем не менее, именно этот опыт сделал Уилла руководителем в рекордно короткие сроки, так как все остальные «умные люди» уволились .
