В современном мире, где цифровые технологии проникают во все сферы бизнеса, пропасть между топ-менеджерами и разработчиками становится одной из главных угроз для выживания компаний. В рамках подкаста SaaStr основатель сообщества Джейсон Лемкин обсудил с генеральным директором Twilio Джеффом Лоусоном ключевые идеи его книги «Ask Your Developer». Лоусон подробно рассказал о том, почему классические методы управления в IT больше не работают, как концепция «команды двух пицц» помогает конкурировать за лучшие кадры с технологическими гигантами и почему успешный бизнес сегодня строится на дешевых экспериментах.
📘 Мост между бизнесом и кодом: почему родилась книга «Ask Your Developer» 0:04
Уникальное положение Джеффа Лоусона позволяет ему видеть технологический бизнес с двух сторон. С одной стороны, он сам является профессиональным программистом, понимающим внутреннюю логику разработки, ее сложность и подверженность сбоям . С другой стороны, как генеральный директор публичной компании Twilio, Лоусон ежедневно сталкивается с типичными болями топ-менеджмента: необходимостью сокращать издержки, ускорять релизы и повышать предсказуемость бизнес-процессов . По его наблюдениям, большинство бизнес-лидеров просто не умеют разговаривать с разработчиками на одном языке , что приводит к взаимному непониманию и срыву важнейших проектов.
По мнению Лоусона, руководители часто пытаются применить к разработке стандартные управленческие шаблоны, которые там не работают:
- Требование жестких сроков и фиксированного функционала. Когда бизнес требует назвать точную дату релиза с конкретным набором фич, разработчики часто ставят его перед невозможным выбором: они могут гарантировать либо дату (но без обещаний по функционалу), либо функционал (но без гарантии сроков) .
- Попытка решить проблему срыва сроков увеличением бюджета. Интуитивная реакция любого менеджера на задержку проекта — выделить больше денег и нанять больше людей . Однако Лоусон напоминает о классическом законе Брукса (хотя и не называет его по имени напрямую): добавление новых людей в опаздывающий проект лишь сильнее затягивает его сдачу .
Книга «Ask Your Developer» задумывалась как практическое руководство, призванное устранить этот коммуникационный барьер и дать технической и нетехнической сторонам общий понятийный аппарат .
☠️ От «Build vs Buy» к «Build vs Die»: новая реальность цифровой экономики 5:02
Еще 15 лет назад венчурный капиталист Марк Андриссен сформулировал свой знаменитый тезис о том, что «программное обеспечение пожирает мир» . Однако тогда, в начале 2000-х годов, в корпоративном секторе доминировал тренд на аутсорсинг IT-услуг . Бизнес рассматривал технологии как поддерживающую функцию (наподобие администрирования офисных ноутбуков или ведения бухгалтерии) и стремился передать их сторонним подрядчикам, не видя в них источника конкурентного преимущества .
Сегодня ситуация кардинально изменилась. Джефф Лоусон считает, что интерфейс взаимодействия любой компании со своими клиентами стал практически полностью цифровым . Он приводит в пример эволюцию банковского сектора:
- Раньше: Привлекательность банка для клиента определялась качеством оформления физического отделения, вежливостью кассира и тем, дадут ли его ребенку леденец на входе .
- Сейчас: Банк — это мобильное приложение в смартфоне . Клиент оценивает банк исключительно по скорости работы приложения, удобству транзакций и регулярности появления полезных функций.
В такой реальности цифровая инфраструктура больше не может быть отдана на аутсорсинг . Как только один сильный игрок на рынке осознает это, начинает нанимать разработчиков и выстраивать с ними непрерывный цикл обратной связи, остальные компании отрасли вынуждены следовать его примеру, чтобы не потерять клиентов . По мнению Лоусона, классическая дилемма «создавать или покупать» (Build vs Buy) в цифровую эпоху трансформировалась в жесткий ультиматум «создавать или умереть» (Build vs Die) . Выживают те компании, которые умеют быстро адаптироваться к меняющимся запросам потребителей с помощью собственного софта, в то время как покупка готовых шаблонных IT-решений ведет к неизбежному технологическому отставанию .
В подтверждение этого тезиса ведущий Джейсон Лемкин поделился личным опытом: при выборе специализированного банка для управления финансовыми потоками SaaStr объемом $20 млн в год представители финансовой организации сразу же признались на звонке в Zoom, что их мобильное приложение оставляет желать лучшего . Это показывает, что даже в консервативных нишах качество софта вышло на первый план при оценке надежности партнера.
🍕 Сила малых команд: как масштабировать модель «двух пицц» 9:23
Многие руководители ошибочно полагают, что для реализации масштабных цифровых проектов требуются огромные бюджеты и гигантские штаты специалистов . Лоусон, опираясь на свой опыт работы инженером в Amazon, утверждает обратное: начинать нужно с малого . Главным двигателем прогресса внутри компании должна стать автономная микрокоманда (модель «двух пицц», размер которой не превышает 10 человек) .
Каждая такая группа должна иметь:
- Четко очерченный сегмент клиентов .
- Конкретную проблему этих клиентов, которую необходимо решить .
- Понятные метрики успеха в решении этой проблемы .
Такой подход решает сразу две важнейшие задачи. Во-первых, он помогает привлекать и удерживать лучших инженеров. Талантливые разработчики не хотят чувствовать себя безликими винтиками в огромной машине из 500 человек, решающих абстрактные задачи . Им важно видеть прямой результат своей работы. Во-вторых, работа в небольшой группе сокращает дистанцию между разработчиком и конечным потребителем . Когда инженеры находятся в непосредственной близости к проблеме клиента, исчезают лишние уровни абстракции, мешающие созданию качественного продукта.
Более того, модель малых автономных команд позволяет небольшим компаниям успешно конкурировать за кадры с такими гигантами, как Google или Facebook . Стартапы не всегда способны предложить аналогичный уровень зарплат или опционов , но они могут дать разработчику то, чего нет в корпорациях:
- Максимальную автономию в принятии архитектурных решений .
- Возможность напрямую влиять на будущее бизнеса .
- Ощущение значимости своей работы.
Лоусон шутит, что в Google с его 50 000 инженеров разработчик может годами отвечать за оптимизацию кнопки «Назад» в браузере Chrome , не понимая своего реального вклада в успех компании. В небольшой же продуктовой команде инженер сразу видит, как его код меняет жизнь пользователей к лучшему.
💡 Главный принцип: ставьте перед разработчиками проблемы, а не задачи 11:19
Один из центральных тезисов Лоусона звучит так: «Делитесь с разработчиками проблемами, а не готовыми решениями» . В традиционных компаниях цепочка создания ценности выглядит линейно: бизнес-аналитики или продуктовые менеджеры общаются с клиентами, пишут детальные технические задания (PRD — Product Requirements Documents) и «перебрасывают их через стену» инженерам, которым остается лишь механически перевести текст в код .
Лоусон убежден, что этот подход неэффективен:
- Отсутствие контекста приводит к ошибкам. Если программист не понимает, зачем он пишет конкретную строчку кода и какую боль клиента она закрывает, он может совершить архитектурную ошибку, даже не заметив этого .
- Потеря внутренней мотивации. Разработка софта — творческий процесс . Задача вида «сделай текстовое поле длиной строго в 40 символов» демотивирует сильного специалиста . Но если поставить перед ним вызов: «Сделай так, чтобы клиент мог открыть счет менее чем за минуту вместо нынешних десяти» — это разжигает профессиональный азарт и заставляет искать элегантные инженерные решения .
Для того чтобы разработчики глубже понимали потребности клиентов, необходимо целенаправленно разрушать искусственные барьеры (силосы) внутри компании . Часто отделы поддержки, продаж и продуктовые менеджеры стремятся «защитить» инженеров от прямого общения с пользователями [13:31, 13:44]. Частично это оправдано (разработчик не должен тратить все свое время на разбор рутинных тикетов), однако полная изоляция вредна .
Лоусон предлагает практические инструменты для интеграции инженеров в клиентский опыт:
- Регулярные дежурства в техподдержке. В Twilio каждый разработчик раз в квартал или дважды в год проводит день на линии поддержки клиентов . Лоусон вспоминает, как во время своего дежурства обнаружил, что 75% поступающих тикетов связаны с необходимостью ручной настройки бэкенд-системы силами инженеров поддержки . Клиентам приходилось ждать решения по два дня . Сразу после смены Лоусон инициировал создание автоматического интерфейса для самостоятельной настройки этой функции пользователями .
- Участие в звонках отдела продаж. Периодическое присутствие инженера на встречах с потенциальными клиентами в качестве слушателя помогает ему лично услышать, как бизнес формулирует свои потребности . Это вызывает восторг у всех участников процесса — от самих инженеров до клиентов и сейлз-менеджеров .
🏹 Охотники и фермеры в разработке: как распределять роли и мотивировать на рутину 22:05
Любой IT-проект состоит не только из увлекательного создания новых фич с нуля, но и из рутинной работы: исправления багов, рефакторинга кода, оптимизации производительности и поддержки масштабируемости систем . Заставить высококлассных инженеров заниматься «неинтересными» задачами бывает непросто.
Джефф Лоусон предлагает решать эту проблему двумя путями:
- Формирование чувства собственности (ownership). Руководитель не должен преподносить рутину как скучную обязанность по исправлению ошибок . Задача должна формулироваться иначе: «Вы владеете этим сервисом, ваша цель — сделать так, чтобы пользователи им восхищались» . Лоусон приводит бытовую аналогию: мы убираем мусор в своем доме не потому, что это захватывающий процесс, а потому, что мы чувствуем себя хозяевами этого места .
- Понимание психологических типов инженеров. Руководителям необходимо разделять разработчиков на «изобретателей» и «эксплуататоров» (созидателей и масштабировщиков) . Лоусон сравнивает это с классическим делением в отделе продаж на «охотников» (hunters), которые умеют находить новых клиентов и закрывать сложные сделки с нуля, и «фермеров» (farmers), эффективных в удержании, развитии отношений и апсейлах . В разработке ситуация аналогична: одни инженеры способны за вечер написать работающий прототип новой идеи, а другие получают искреннее удовольствие от наведения порядка в кодовой базе, выстраивания архитектуры под миллионные нагрузки и обеспечения отказоустойчивости систем . Задача менеджера — распределить людей по подходящим ролям .
🤝 Симбиоз Product Management и Engineering: уроки Bloomberg 25:03
Разделение обязанностей между продуктовыми менеджерами (PM) и техническими лидерами часто становится зоной конфликтов. По мнению Лоусона, ключевая роль продакт-менеджера на уровне компании заключается в стратегическом планировании: распределении бюджетов и штата инженеров между наиболее перспективными клиентскими сегментами и проблемами .
На уровне же конкретной микрокоманды задача PM — не диктовать инженерам технические решения, а фасилитировать их общение с клиентами, делиться инсайтами и организовывать процесс совместного поиска ответов на бизнес-вызовы . Продакт-менеджер не должен монополизировать право на общение с пользователем .
В качестве иллюстрации Лоусон рассказывает историю одного из продуктовых лидеров Twilio по имени Бен . Свою карьеру Бен начинал программистом в Bloomberg, занимаясь разработкой одного из многочисленных информационных виджетов для знаменитого торгового терминала . В самом начале работы он поинтересовался у руководителя, когда сможет лично пообщаться с трейдерами, использующими его софт . Менеджер удивился и ответил, что в компании так делать не принято .
Тогда Бен самостоятельно нашел знакомого трейдера и пришел посмотреть на его рабочее место . Результат поверг инженера в шок:
- Ожидание разработчиков: Во время написания кода команда представляла свой виджет главным элементом на огромном 24-дюймовом мониторе .
- Реальность: На экране трейдера виджет оказался крошечным окошком размером 24 на 24 пикселя в самом углу дисплея, где шрифт был практически нечитаемым, а графики — неразличимыми .
Вернувшись в офис, Бен немедленно переписал логику масштабирования шрифтов и отображения информации . Этот важнейший продуктовый инсайт никогда не был бы получен, если бы инженер оставался запертым в рамках стандартного ТЗ .
⚾ Эра дешевых экспериментов: API как цифровая цепочка поставок 31:07
Успех таких гигантов, как AWS, Stripe и Twilio, обусловлен тем, что они предоставляют бизнесу не готовые законченные решения, а базовые строительные блоки . Лоусон называет это «цифровой цепочкой поставок» . По аналогии с автомобильной промышленностью Детройта, где заводы не собирают каждую гайку самостоятельно, а опираются на сеть специализированных поставщиков, современная разработка ПО строится на интеграции надежных сторонних API .
Главным следствием этого процесса стало радикальное снижение стоимости инноваций . В 1990-е годы внедрение любой крупной корпоративной системы (например, ERP) стоило миллионы долларов, растягивалось на годы и требовало личного согласования на уровне CIO . При этом около 60% таких проектов завершались полным провалом, не принося бизнесу никакой ценности . Это была эпоха «высоких ставок».
Сегодня разработчик может зарегистрироваться на платформе вроде Twilio или Stripe, привязать карту, потратить один доллар и за несколько минут собрать работающий прототип новой идеи . Финансовый риск провала стал ничтожным .
Лоусон убежден, что непрерывное проведение экспериментов — обязательное условие для инноваций :
«Наша вероятность наткнуться на следующую большую идею напрямую зависит от количества гипотез, которые мы проверяем в единицу времени» .
Он напоминает спортивную метафору основателя Amazon Джеффа Безоса: в бейсболе при самом удачном стечении обстоятельств игрок может выбить максимум гранд-слэм и принести команде четыре очка . Но в бизнесе, особенно в интернете, один успешный удар (« swing ») может принести миллион очков . Поэтому задача прогрессивного руководства — не искать причины отказать сотрудникам в реализации новых идей, а создавать условия для быстрого и безопасного проведения сотен мелких экспериментов .
🏗️ Инфраструктура разработки и управление рисками 36:00
Для того чтобы эксперименты проходили быстро и не вредили основному бизнесу, компания должна выстроить качественную внутреннюю платформу для разработчиков . Лоусон снова проводит параллель со сферой продаж: профессиональным сейлзам не выдают бумажные блокноты — их снабжают CRM-системами, инструментами генерации лидов и аналитикой, вкладывая в эту инфраструктуру огромные деньги . Без качественного инструментария сильные продавцы просто уволятся .
Точно так же инженерам нужны надежные инструменты для написания, тестирования, быстрого развертывания кода в продакшн, мониторинга и логирования ошибок . Лоусон отмечает, что передовые технологические компании тратят от 40% до 50% своего совокупного R&D-бюджета исключительно на развитие внутренней платформы разработки . Эти инвестиции многократно окупаются за счет повышения производительности всех продуктовых команд.
При этом бизнес часто блокирует быстрые эксперименты из соображений безопасности и комплаенса, опасаясь утечек персональных данных клиентов или репутационных рисков при сбоях тестового софта . Лоусон считает эти опасения абсолютно оправданными, но призывает решать их методологически, а не запретами :
- Использование концепций бережливого стартапа. Лоусон рекомендует книгу Эрика Риса «The Lean Startup» для понимания того, как проверять гипотезы без развертывания кода в основной инфраструктуре .
- Изоляция данных. Эксперименты можно проводить на выделенных дешевых доменах за $7 , используя синтетические данные или простейшие защищенные облачные инструменты (например, таблицы Google) на этапе прототипирования , прежде чем переносить успешно доказавшую свою ценность фичу в основной контур безопасности корпорации .
🌍 Распределенная работа и «правило трех часовых поясов» 41:08
Пандемия COVID-19 навсегда изменила ландшафт найма IT-специалистов, доказав жизнеспособность распределенной модели работы . При этом Джефф Лоусон остается последовательным сторонником поддержки локальных сообществ. Он подчеркивает, что верит в потенциал Сан-Франциско не из-за веры в монополию Кремниевой долины на таланты, а просто потому, что сам живет в этом городе . По его мнению, технологические лидеры, чей бизнес процветает, обязаны инвестировать ресурсы обратно в свои локальные сообщества, особенно в периоды кризисов, помогая тем сферам и людям, которые пострадали от экономических потрясений .
Обсуждая логистику распределенных компаний, Лоусон дает несколько практических рекомендаций:
- Соблюдение географического баланса внутри микрокоманды. Члены одной автономной группы должны находиться в пределах максимум трех часовых поясов друг от друга . Это гарантирует достаточное количество часов пересечения рабочего времени для оперативного обсуждения вопросов без необходимости вести переписку по 24 часа. В качестве примера Лоусон приводит executive-команду самого Twilio: CPO живет в Сан-Диего, руководитель продуктового направления — в Сиэтле, а руководитель аппарата (Chief of Staff) — в Нью-Йорке . Разница во времени не превышает трех часов, что позволяет комфортно работать.
- Формализация связей между удаленными командами. Сами микрокоманды внутри себя могут общаться неформально и быстро . Но если две взаимодействующие команды разделены океаном и полушариями, коммуникации между ними должны быть строго регламентированы и формализованы . Попытки заменить выверенные процессы ночными созвонами приводят лишь к профессиональному выгоранию сотрудников .
- Гибкость внутренней структуры. Руководителям не стоит навязывать единый формат работы для всей корпорации. После открытия офисов Twilio пошла по пути самоопределения команд: те группы, которые хотят работать очно, возвращаются в офисы; приверженцы удаленки остаются дома . Компания позволяет сотрудникам свободно переходить между отделами, чтобы каждый нашел наиболее комфортный для себя рабочий стиль .
🎁 Социальная миссия «Ask Your Developer» 49:02
В завершение беседы Джефф Лоусон подчеркнул, что написание книги не было для него коммерческим проектом. Все доходы от продаж «Ask Your Developer» напрямую направляются в благотворительные фонды и некоммерческие организации, помогающие людям из малообеспеченных и недостаточно представленных слоев населения получить востребованное технологическое образование .
Среди поддерживаемых организаций:
- NPower — помогает ветеранам вооруженных сил и молодежи из малообеспеченных семей осваивать IT-специальности .
- SMASH — образовательная программа в области STEM для старшеклассников из латиноамериканских, афроамериканских и индейских общин .
- Black Girls Code — инициатива, популяризирующая программирование среди темнокожих девушек .
Покупая книгу, читатели не только получают ценные инсайты по управлению командами, но и вносят непосредственный вклад в создание более инклюзивной и разнообразной технологической индустрии .
