В новом выпуске Lenny's Podcast вице-президент и глава инженерного отдела компании Shopify Фархан Тавар делится уникальными методами построения высокоэффективной и автономной технологической культуры. Собеседники подробно разбирают, как компании с более чем 10 000 сотрудников удается сохранять стартап-скорость, почему парное программирование является недооцененным инструментом менеджмента и как радикальное сокращение совещаний влияет на продуктивность. В основе философии управления гостя лежит принцип осознанного выбора самых трудных путей ради долгосрочной устойчивости бизнеса.
🛠️ Стратегия «сложного пути»: почему тяжелый выбор облегчает жизнь в будущем 5:42
Один из главных карьерных и жизненных принципов Фархана Тавара заключается в том, что при наличии нескольких альтернатив всегда следует выбирать наиболее трудный вариант. Логика этой концепции строится на гарантированном получении ценного опыта независимо от финального результата. Если выбрать легкий путь, и он завершится неудачей, человек теряет время, ничего не приобретая взамен. Сложный же путь, даже в случае полного провала проекта, оставляет участникам новые навыки, глубокое понимание процессов и социальный капитал в виде связей с сильными специалистами, которые обычно не задерживаются на легких задачах.
В качестве примера Фархан Тавар приводит типичную стратегию соискателей рабочих мест. По его наблюдениям, большинство кандидатов выбирают легкий путь — рассылку по 10 резюме в день, что не приносит новых знаний. Вместо этого он рекомендует сложный, но продуктивный подход: изучить документацию API интересующей компании (например, Shopify) и создать работающее приложение или расширение. Даже если кандидат не получит работу, у него останется готовый проект в репозитории GitHub, практические навыки работы с платформой и весомый аргумент для других работодателей.
Фархан Тавар применял это правило на протяжении всей жизни:
- В Университете Ватерлоо (University of Waterloo) он дополнительно к компьютерным наукам взял сложную специализацию по электротехнике.
- Во время обучения на степень MBA он выбрал дополнительную специализацию в области финансового инжиниринга.
Такой подход приводил к снижению средних оценок, однако, как утверждает гость подкаста, именно в сложных аудиториях он знакомился с самыми умными людьми, которые остаются его друзьями до сих пор. При этом важно отличать сложный путь от заведомо деструктивных или глупых решений. По мнению Фархана Тавара, правильный «сложный путь» должен определяться потенциалом образовательного путешествия (learning journey): необходимо выбирать те условия и окружение, где можно узнать больше всего нового.
Еще одной личной «суперсилой» Фархан Тавар считает готовность регулярно выглядеть глупо на публике и пытается привить это качество своим командам. Он убежден, что страх показаться некомпетентным блокирует развитие. На практике, когда топ-менеджер задает простой или кажущийся глупым вопрос, выясняется, что половина присутствующих в зале имела тот же вопрос, но боялась его озвучить. Навык преодоления страха отторжения формируется через практику: сам Фархан развивал сопротивляемость к отказам в молодости, работая в розничной торговле на комиссионной основе и ежедневно сталкиваясь со множеством клиентов, уходящих без покупки. До сих пор коллеги и партнеры иногда пишут ему, что он задает «самые глупые вопросы» или просят перечитать объяснения, сделанные трижды, однако Тавар относится к этому спокойно, ставя приоритетом понимание сути материала, а не защиту собственного эго.
Интересной особенностью карьеры Фархана Тавара является то, что каждое десятилетие своей профессиональной деятельности он работал под руководством нового миллиардера: Джо Лемонда в 20 лет, Чамата Палихапитии в 30 лет и Тоби Лютке (основателя Shopify) в настоящее время. Анализируя их сходства, Тавар отмечает, что все эти лидеры обладают иррациональным видением будущего на 10–25 лет вперед. Сам гость признает, что не умеет формировать столь масштабные долгосрочные видения, но обладает талантом ежедневно продвигать команду к этой цели на 1%. По его словам, осознание своих сильных и слабых сторон позволяет эффективно дополнять таких визионеров. При создании собственной компании Helpful в 2015 году Тавар составил список всех «иррациональных» предпринимателей Торонто, встретился с каждым из них для проверки «совместимости API» и выбрал одного партнера для запуска бизнеса.
Для долгосрочного планирования карьеры Фархан Тавар использует жесткий письменный фреймворк личных ценностей, защищающий его от отвлекающих факторов, таких как деньги, привлекательные должности или бренд компании в сообщениях рекрутеров. Если текущая работа нарушает этот фреймворк, Тавар незамедлительно увольняется, даже не имея альтернативного предложения на руках. Так произошло во время его работы в компании Xtreme Labs, которая была выкуплена Pivotal. Когда его роль трансформировалась в позицию выездного CTO (field CTO), он обнаружил, что больше не работает с самыми умными людьми, перестал развиваться и потерял масштабы влияния. В результате Тавар объявил команде об уходе, что впоследствии открыло для него новые инвестиционные и карьерные возможности.
🚀 Культура высокой интенсивности: как делать больше за единицу времени 19:23
Философия высокой интенсивности в Shopify базируется на концепции максимизации затрат килоджоулей (калорий) в час, а не на увеличении общего количества рабочих часов. Фархан Тавар исходит из фундаментального тезиса о том, что один час времени неизменен для любого человека. Если сотрудник работает с высокой концентрацией с 9:00 до 17:00, он успевает сделать колоссальный объем работы и может со спокойной душой идти на футбольный матч своего ребенка, не растягивая задачи на 12-часовой рабочий день за счет перерывов на настольный футбол или затяжной кофе. По мнению гостя подкаста, по-настоящему сильные специалисты способны выдавать высококачественный результат в разы быстрее именно за счет сфокусированной интенсивности, что подтверждает закон Паркинсона.
💻 Парное программирование как инструмент управления
Фархан Тавар называет парное программирование самым недооцененным и малоиспользуемым управленческим инструментом в современной инженерии. Метод предполагает одновременную работу двух специалистов за одним компьютером (с использованием двух клавиатур, мониторов и микрофонов, либо удаленно через специализированный софт, такой как Tuple). Вопреки распространенному скепсису о том, что два инженера за одной машиной произведут в два раза меньше кода, Тавар утверждает, что они напишут еще меньше — и это огромный плюс. Основным ограничением разработки является не скорость ввода символов на клавиатуре, а поиск элегантного, простого и долговечного архитектурного решения.
В подтверждение этого тезиса приводится исторический пример из практики основателя Shopify Тоби Лютке и бывшего CTO компании Коди Фаазера:
- Они устанавливали таймер ровно на один час и садились писать код в паре.
- Если по истечении часа задача не была решена, они полностью удаляли весь написанный код, оставляя только тесты, и начинали заново.
- Логика Лютке заключалась в том, что если фичу невозможно выразить и закодить за час, значит, изначально была выбрана неверная и слишком сложная архитектура.
Аналогичный жесткий подход практировался в Pivotal Labs: если напарник заболевал, оставшийся инженер продолжал писать код в одиночку, но на следующий день вернувшийся коллега стирал всё написанное без него и они создавали решение заново. Тавар подчеркивает, что код — это долгосрочное обязательство и пассив (liability) компании. Лучшее время для переписывания кода — сразу после его создания, когда контекст максимально свеж. Удаление промежуточных вариантов позволяет преодолеть «заблуждение о невозвратных затратах» (sunk cost fallacy) и прийти к максимально лаконичному результату. Парное программирование также обеспечивает высокую скорость обучения сотрудников, исключает появление информационных изоляторов (silos) и повышает общий уровень удовлетворенности работой.
Фархан Тавар сравнивает нежелание ИТ-индустрии внедрять парное программирование с феноменом бросков из-под юбки (underhanded free throw) в баскетболе. Статистически этот метод обеспечивает гораздо более высокую точность попадания штрафных бросков, однако профессиональные игроки (включая легендарного Шакила О'Нила) наотрез отказывались его использовать, поскольку это «выглядит глупо».
В отличие от Xtreme Labs, где парная разработка занимала все 40 часов в неделю из-за специфики контрактной сборки приложений по готовым спецификациям, в Shopify этот инструмент применяется более гибко — в объеме от 4 до 8 часов в неделю. Поскольку Shopify является компанией-первопроходцем, находящейся в режиме постоянного поиска решений (wayfinding), инженеры объединяются в пары стратегически: для прохождения сложных участков кодовой базы по средам, совместного разбора инцидентов или быстрого прототипирования. С появлением ИИ-ассистентов (таких как GitHub Copilot или Cursor через Whisper) формат трансформируется: программист может вести голосовой диалог с ИИ, как с напарником. Тем не менее, Тавар считает идеальной комбинацию, когда за одной машиной работают два инженера, совместно использующие ИИ-копилот, что позволяет мгновенно фильтровать генерируемый нейросетью код и глубже оценивать его архитектурную интеграцию.
🗓️ Шестинедельные спринты и «микроменеджмент» здорового человека
Для поддержания высокого темпа работы в Shopify выстроена система регулярных кросс-функциональных обзоров. В то время как многие компании погрязли в затяжных шестимесячных процессах реорганизации и согласований, в Shopify любые крупные изменения структуры занимают одну-две недели. Руководство сознательно отказывается от классического управления изменениями (change management) в пользу высокой скорости адаптации, открыто транслируя сотрудникам тезис о волатильности среды ради блага мерчантов (клиентов платформы).
Ритм работы компании задается следующими процессами:
- Инструмент GSD (Get Shit Done): Еженедельные текстовые и видеообновления по каждому проекту, транслируемые на всю компанию для демонстрации непрерывного прогресса.
- Двухэтапное согласование архитектуры: Этап OK1 проходит на уровне директоров для подтверждения концептуального направления проекта. Этап OK2 происходит на уровне вице-президентов для проверки соответствия архитектурным стандартам и глобальному контексту индустрии.
- Шестинедельные циклы планирования: Каждые шесть недель вовлеченные команды собираются на трехдневные сессии очных обзоров с участием Тоби Лютке, где детально пересматривается дорожная карта каждого проекта и распределение ресурсов.
Фархан Тавар отмечает, что на таких встречах Лютке проявляет максимальную требовательность, жестко пресекая избыточное теоретизирование со стороны инженеров. В качестве примера эффективного ускорения Тавар описывает недавний случай, когда команда инженеров застряла на архитектурной проблеме: для работы с LLM требовалось большое окно контекста на выходе, которое у стандартных моделей было ограничено. Инженеры уже начали проектировать сложную систему кэширования и разбиения данных на куски, что отняло бы недели работы. Тавар напрямую написал партнерам в открытые каналы OpenAI и Google Gemini в Slack с простым вопросом: можно ли увеличить лимиты для Shopify? В течение часа недокументированная функция была активирована, и проект мгновенно сдвинулся с мертвой точки.
В Shopify переосмыслено понятие микроменеджмента, которое в корпоративной культуре обычно считается деструктивным. По словам гостя, контроль важен не ради фиксации невыполненных задач, а как формат совместного решения проблем руководством и исполнителями. Регулярные погружения руководителей в детали позволяют им вовремя делиться стратегическим контекстом, а инженерам — быстрее получать необходимую помощь. В начале работы в Shopify Тавар пытался сказать Тоби Лютке, что его не нужно контролировать, на что основатель ответил, что нанял топ-менеджера не для того, чтобы тот забирал проблемы себе, а для того, чтобы они решали их вместе.
📉 Борьба с хаосом: «Армагеддон совещаний» и Клуб удаления кода 37:22
Для предотвращения бюрократизации и защиты времени инженеров (crafters) в Shopify раз в год проводится процедура, получившая название «Армагеддон совещаний» (Meeting Armageddon). В случайный момент времени администраторы централизованно удаляют из календарей сотрудников абсолютно все повторяющиеся внутренние встречи, в которых участвуют более двух человек (за исключением внешних партнерских звонков и собеседований). После этого вводится двухнедельный мораторий на создание любых новых регулярных митингов. Данная практика призвана разрушить инерцию совещаний. По мнению Фархана Тавара, людям психологически трудно отменить укоренившуюся еженедельную встречу, даже если её повестка исчерпана. Сброс календарей заставляет команды заново оценивать реальную необходимость каждого синхронного обсуждения.
Вторым радикальным шагом компании стал перенос всех статус-апдейтов и крупных организационных объявлений из Slack на платформу Facebook Workplace (в данный момент закрывается Meta). Руководство пришло к выводу, что Slack как инструмент мгновенных сообщений порождает избыточные уведомления и сильный фактор отвлечения. Перевод официальной информации в формат ленты новостей, работающей на алгоритмах машинного обучения, позволил сотрудникам потреблять корпоративный контент асинхронно и порционно, не выпадая из рабочего потока.
Результаты данных инициатив отразились на статистике:
- Время нахождения рядовых инженеров (individual contributors) на совещаниях сократилось на 50–60% — с 5–6 часов до рекордных 3 часов в неделю.
- Управленческий состав (managers) сократил время на митингах с 10 до 6–7 часов в неделю.
Освободившееся время инженеры инвестируют непосредственно в написание кода и проектирование в состоянии потока. Внутренняя цель Shopify — оставаться «раем для создателей» (crafters' paradise), где UX-дизайнеры, продуктовые менеджеры и разработчики могут беспрепятственно оттачивать свое мастерство.
Параллельно в компании культивируется стремление к максимальному упрощению кодовой базы. Фархан Тавар напоминает, что объем написанного кода не является метрикой продуктивности, а сам по себе крупный код усложняет обеспечение надежности, производительности и ремонтопригодности системы. В Shopify действует официальный «Клуб удаления кода» (Delete Code Club), а в рамках регулярных хакатонов (Hack Days), проходящих 2–3 раза в год, как минимум одна команда всегда целенаправленно ищет устаревшие компоненты для ликвидации. В результате таких сессий инженерам стабильно удается безболезненно удалять более 1 миллиона строк кода за раз. Комментируя заявления технологических гигантов о том, что ИИ теперь пишет до 25% кода, Тавар иронизирует, что поверит в силу искусственного интеллекта лишь тогда, когда нейросети научатся удалять 25% лишнего кода ради элегантности системной архитектуры.
Любая техническая задача в компании жестко классифицируется по трем корзинам: эксперимент, фича или инфраструктура. Эксперименты создаются быстро для проверки гипотез, фичи используют готовую базу, а инфраструктура требует долгой проработки. Тоби Лютке ориентирует команды всегда инвестировать в инфраструктурный слой. Его подход Тавар описывает метафорой «заправки бака»: создание точечного решения для конкретной задачи (например, токен-гейтинга для NFT) может занять две недели, тогда как построение платформенного API, позволяющего любому внешнему разработчику собрать такую фичу за час, требует 2–3 месяцев. Руководство Shopify всегда выбирает второй вариант, так как качественная инфраструктура окупается годами высокой скорости последующей разработки. При проектировании Лютке использует метод написания клиентского кода под еще не существующие API, чтобы сначала добиться идеального UX интерфейса, и лишь затем приступать к реализации серверной части.
👥 Эволюция найма: отказ от классических резюме и ставка на стажировки 1:03:11
Фархан Тавар убежден, что стандартные собеседования являются крайне слабым предиктором реальной успешности сотрудника на рабочем месте, что подтверждается множеством независимых исследований. В его практике часто встречались ситуации, когда кандидаты с блестящими навыками самопрезентации проваливались в реальных задачах, и наоборот.
В качестве примера гость подкаста приводит личный опыт найма специалистов по машинному обучению в свой предыдущий стартап:
- Кандидат А: Обладатель степени PhD, преподаватель университета, имевший сильную внутреннюю рекомендацию. Был уволен через несколько недель из-за абсолютной культурной несовместимости с интенсивной средой.
- Кандидат Б: Молодой человек, встреченный Таваром в кофейне, который вообще не имел опыта работы в ИТ-индустрии, но демонстрировал колоссальную увлеченность технологиями. Он успешно прошел испытания, до сих пор работает в Shopify и вырос в выдающегося инженера.
Для оценки кандидатов Тавар использует аналогию с гоночным автомобилем: если нужно нанять лучшего пилота болида, бессмысленно задавать ему вопросы по анкете, его нужно просто посадить за руль. Поэтому ключевой упор делается на прозрачные рабочие испытания (job trials) в первые 30, 60 и 90 дней после найма. Кандидатов заранее предупреждают, что этот период является взаимным тестом на соответствие жесткой культуре компании, и если синергии не происходит, с сотрудником быстро и честно расстаются, что выгодно обеим сторонам. На прошлых местах работы Тавара данный подход приводил к 20-процентной текучести кадров в первые три месяца, однако среди тех, кто преодолевал этот рубеж, показатель увольнений составлял менее 1% на долгие годы.
Важнейшим этапом самого интервью в Shopify является так называемая «история жизни» (life story). Рекрутеры и менеджеры полностью игнорируют сухие перечисления должностей в резюме. По мнению Тавара, резюме фиксирует лишь то, что человек сделал, но умалчивает о главном — почему он принимал эти решения. В рамках «истории жизни» оценивается мотивация переходов между компаниями и широта кругозора (range). Опираясь на книгу Дэвида Эпштейна «Интервал» (Range), Тавар подчеркивает ценность генералистов для инновационных компаний. Сам гость долго считал себя узким специалистом-разработчиком, пока не осознал, что его компетенции лежат на стыке инженерии, рекрутинга, построения компенсационных систем и HR.
🎓 Масштабирование через программу стажировок
Идеальным воплощением концепции рабочих испытаний Тавар считает масштабную программу стажировок Shopify. В 2025 году компания намерена нанять более 1000 стажеров. Руководитель категорически отвергает подход к стажировкам как к форме «социальной благотворительности» или общественной работы корпорации. Для Shopify это прагматичный бизнес-инструмент: компания получает тысячу молодых специалистов, выросших в эпоху генеративного ИИ, обладающих свежим взглядом на голосовые интерфейсы, чат-боты и коммерцию. В течение 4 месяцев стороны оценивают друг друга в условиях реального продакшена, что заменяет любые многочасовые теоретические интервью.
Программа имеет две уникальные особенности:
- Обязательный гибридный формат: Стажеры обязаны работать из физических офисов (хабов в Торонто, Монреале или Оттаве) 3 дня в неделю, несмотря на то, что сама Shopify на 95% является удаленной компанией. Это необходимо для формирования когортной поддержки и ускоренного обучения через личное взаимодействие с менторами.
- Повышенная интенсивность: По наблюдениям Тавара, стажеры в процессе парного программирования демонстрируют значительно более высокий уровень вовлеченности и энергии, чем штатные сотрудники, что дополнительно подстегивает общую продуктивность инженерных департаментов.
Данная инициатива Тавара вызвала резонанс в технологической отрасли Канады: после его публикаций в социальных сетях CTO нескольких конкурирующих компаний заявили о расширении своих интернатур до 1001 человека, чтобы «побить рекорд Shopify», что гость оценивает как позитивный фактор для перезапуска всей экосистемы после волны ИТ-сокращений последних лет.
🤯 Эксперимент на 120 прямых подчиненных: опыт управления в Xtreme Labs 1:15:31
В период работы в мобильной компании Xtreme Labs Фархан Тавар провел радикальный управленческий эксперимент, замкнув на себя рекордные 120 прямых подчиненных (direct reports). Целью этого шага была проверка гипотезы о возможности полного исключения промежуточного менеджерского звена за счет создания систем саморегуляции инженеров.
Тавар декомпозировал стандартные обязанности классического менеджера и заменил их альтернативными инструментами unblocking-а:
- Определение приоритетов: Заменено жестким ведением прозрачных продуктовых бэклогов, из которых инженеры всегда знали следующую задачу.
- Техническая помощь: Проблема решалась за счет тотального парного программирования, где специалисты страховали и обучали друг друга в режиме реального времени.
- Обратная связь по качеству: Заменена обязательными еженедельными открытыми демонстрациями (demos) готового продукта как внутри команды, так и напрямую заказчикам.
- Соблюдение дисциплины: Контролировалось фиксированными часами интенсивной совместной работы в офисе.
Главным условием выживания руководителя в такой структуре стал полный отказ от плановых еженедельных встреч «один на один» (one-on-one). Тавар подсчитал, что проведение 120 регулярных встреч отняло бы все его рабочее время. Вместо этого он внедрил практику спонтанных, неструктурированных микро-встреч по запросу (unscheduled one-on-ones). Рабочее место руководителя располагалось в самом центре опенспейса, а из-за отсутствия официальных совещаний он физически находился там постоянно. Любой заблокированный инженер мог подойти к его столу и за 2 минуты решить вопрос с закупкой оборудования, согласованием бюджетов или получением доступа к сторонним API.
Кроме того, находясь в центре зала, Тавар визуально контролировал вовлеченность: если пара разработчиков активно дискутировала перед монитором — процесс шел штатно; если один из инженеров откидывался на спинку кресла с безучастным видом — руководитель сам подходил для оказания помощи.
Эксперимент был остановлен после вмешательства крупного инвестора компании Чамата Палихапитии. Палихапития не стал спорить об эффективности текущей модели на 120 человек, но задал один правильный вопрос: «Сработает ли эта схема, когда в компании будет 400 сотрудников?». Тавар признал, что масштабирование невозможно, после чего структура была скорректирована. Модель сделали более плоской: Тавар назначил нескольких директоров, но вменил им в обязанность иметь не менее 40 прямых подчиненных каждому, чтобы сохранить ДНК быстрой unblocking-системы без бюрократических искажений.
В текущей структуре инженерного отдела Shopify Тавар имеет около 14 прямых отчетов, а общекорпоративный стандарт предписывает лимит от 8 до 20 подчиненных на менеджера для поддержания максимально плоской структуры. По словам гостя, данные внутренних опросов четко показывают: чем дальше уровень сотрудника находится от основателя Тоби Лютке, тем сильнее размывается стратегическое выравнивание (alignment) команд.
📉 Главный провал в карьере: цена компромисса и уроки Тоби Лютке 1:21:06
Несмотря на статус успешного топ-менеджера, Фархан Тавар за свою карьеру дважды проходил через процедуру сокращения (layoffs), что считает полезным опытом, подтолкнувшим его к созданию личного ценностного фреймворка. Самым масштабным профессиональным провалом внутри Shopify он называет стратегическое решение, принятое им в первую неделю после вступления в должность в 2019 году.
Перед Таваром стояла задача перезапуска системы Point of Sale (POS), которая сегодня генерирует для Shopify миллиардные объемы валового торгового оборота (GMV). Инженерная команда выбирала технологический стек для мобильной версии: писать приложения полностью нативными методами (Swift под iOS и Kotlin под Android) или использовать кроссплатформенный фреймворк React Native от компании Meta.
Пытаясь захеджировать риски, Тавар принял компромиссное и, как он сам теперь признает, ошибочное решение:
- Версию для iOS было решено писать на нативном Swift, чтобы гарантировать стабильный выход продукта на рынок, так как у Shopify на тот момент не было успешного опыта крупных продакшн-приложений на React Native.
- Версию для Android параллельно отдали под эксперимент с React Native, посчитав эту платформу более сложной для тестирования кроссплатформенных возможностей.
Через год нативная iOS-версия POS вышла на рынок и продемонстрировала отличные показатели. Однако еще через шесть месяцев, когда была завершена Android-версия на React Native, инженеры осознали колоссальное преимущество единого кроссплатформенного стека: он позволял использовать веб-разработчиков экосистемы React для создания мобильных интерфейсов, а также запускать код непосредственно в вебе. К этому моменту Shopify параллельно запустила флагманское потребительское приложение Shop App, также написанное на React Native, доказавшее зрелость технологии.
Тавар осознал, что совершил критическую ошибку, разделив стек. Он лично пришел к Тоби Лютке и признался, что его решение сожгло (burned) 18 месяцев работы команды из 100 инженеров, поскольку теперь всю iOS-версию POS необходимо полностью переписать с нуля и перевести на React Native. Реакция Лютке оказалась неожиданной. Он не стал применять административные санкции, а лишь сказал: «Ты должен рассказать эту историю абсолютно всем в компании». Основатель Shopify пояснил, что жестко карает сотрудников за отказ от оправданного риска, но никогда не наказывает за неудачу, ставшую следствием этого риска в обучающейся организации (learning org). Ошибка Тавара заключалась именно в трусливом хеджировании (hedging) рисков в первую неделю работы. Вместо того чтобы пойти до конца и перевести весь проект на перспективный React Native, он выбрал половинчатый путь. Впоследствии Shopify полностью реорганизовала мобильную разработку, став одним из ключевых контрибьюторов в ядро React Native во всем мире, однако цена этой управленческой ошибки стоила компании полутора лет работы огромного департамента.
