Сермяжная правда о том, как работают бигтехи — история без протокола инкогнито-эксперта
Дата: 21.08.2026
Кто идет работать в Big Tech? Как и на какие условия приходит? В какой культуре оказывается? Как уходят? Почему Big Tech не любят Agile, как управляют проектами и сколько там менеджеров? Как влияет ИИ на Big Tech? Интересные мысли о конфликте B2C-культуры и B2B внутри Big Tech. И в чем же секрет успеха Big Tech?
Содержание
Кто, как и на что приходит, в какой культуре оказывается, как уходит
Это миф, что в бигтехе работают только гении. Конечно, гении есть, но их процент невелик, большинство — это обычные инженеры, зачастую пришедшие на работу сразу же после окончания университета. Но уровень инженеров в бигтехах в среднем выше, чем, к примеру, в московских и питерских компаниях.
Как и раньше, бигтехи оплачивают релокацию нанимаемых сотрудников. Но это не роскошный пакет — хватает, чтобы без проблем переехать.
Про доход важно понимать, что зарплата — это только половина реального дохода, остальное — акции. Также бывают бонусы, но все зависит от компании, позиции и ценности нанимаемого сотрудника. Акции — это ключевой механизм удержания сотрудников, а также механизм тихого увольнения. Если компания публичная, как Google, акции — это фактически деньги, так как они торгуются на бирже. Если компания непубличная, как Anthropic, то акции существуют только на бумаге, пока компания не выйдет на IPO. Акции даются не сразу: часто нужно отработать год, чтобы получить первый пакет акций — и при подписании контракта обещается определенное количество акций, которые постепенно передаются сотруднику в течение 4 лет (график вестинга). Каждый год проводится оценка сотрудника (performance review) и при высоких показателях передают дополнительный пакет акций (refresh), соответственно, при низких показателях без обновления пакета акций реальный доход может упасть вдвое. Нужно еще учитывать, что чем моложе компания, тем круче падение процента акций в структуре дохода сотрудника со временем. К примеру, в первый год тебе дают большую зарплату, на второй год — в половину меньше по сравнению с первым годом, так как рассчитывают, что по итогам первого года тебе досыпают еще акций, но если не досыпают — доход падает на треть: не нравится — увольняйся. То есть если сотрудника хотят уволить без компенсации, то просто не дают обновления акций, из-за чего заметно падает реальный доход и сотрудник уходит сам. Никаких золотых парашютов и больших выходных пособий сейчас нет, компенсация только строго по локальному законодательству страны, где работает сотрудник.
Основной механизм управления сотрудниками — это система грейдов (уровни или levels) и связанный процесс оценки сотрудников (performance review). Каждая позиция описана грейдом с четкими ожиданиями, что сотрудник должен делать.
Увольняют не только за плохую работу, но и несоответствие высокой планке компании: достаточно оказаться чуть-чуть ниже ожидаемого высокого уровня. Если сотрудник демонстрирует низкие показатели в течение нескольких последовательных оценок, то он получает план улучшения (performance improvement plan) на 1-3 месяц. Если за это время он не улучшает показатели, то следует увольнение.
Кроме того, на низких грейдах (level 2-4) есть ограничение по времени перехода на следующий более высокий уровень: если за определенное количество лет не произошло перехода, следует увольнение. Таким образом, в низах коммуницируется требование обязательного саморазвития.
Теперь о самом важном, что новичок должен понять на входе. От сотрудника требуется огромное количество усилий на то, чтобы не просто сделать работу, но и сделать информацию об этом публичной, общедоступной и известной всем. Мало доказать руководителю, что ты молодец, об этом должны знать все вокруг. Необходимость самостоятельно заниматься собственным маркетингом задает структура performance review, когда оценка идет не только от руководителя, но и коллег, а в рассмотрение комитетом берутся не столько субъективные отзывы, сколько реальные артефакты: написанные документы, протоколы встреч, комментарии в чужих документах, сообщения в чатах, почтовые рассылки, комиты (для инженеров), достигнутые бизнес-показатели, количество предложенных проектов, сколько предложенных тобою проектов пошло в работу, какую пользу принесли проекты с твоим участием, в каких обсуждениях ты участвовал и насколько весомо оказалось твое мнение и т.п. Соответственно, все должно быть записано, отрецензировано и желательно растрезвонено на всю организацию. Типичная фраза новичку на старте: «О, отличная идея! Запиши в документ и подошьешь к своему перформансу» — и постепенно ты начинаешь ощущать перформанс-промо-культуру, когда все вокруг постоянно переживают за свой перформанс и промоушен из-за страха увольнения. Соответственно, очень много сил и времени тратится не на работу, а на доказательство ее свершения. И это не опциональная, а обязательная часть твоей работы, иначе оценка будет низкой.
Также выход может произойти случайно. К примеру, закрывают целый отдел, функцию или направление — раньше людей перемещали в соседние проекты, но после пандемии 2020 года просто увольняют. Также рост продуктивности инженеров с помощью ИИ провоцирует массовые временные сокращения (layoffs), но зачастую численность штата (headcount) сохраняется и получается анекдотично: одной рукой увольняют, а другой — втихаря нанимают обратно тех же самых людей, потому что новому сотруднику требуется 3-6 месяцев, чтобы стать эффективным, а бывший сотрудник знает инструменты, процессы и разделяет культуру, а потому приносит пользу с первых же недель.
Почему не любят Agile, как управляют проектами и сколько менеджеров
Бигтехи с Agile не дружат. С одной стороны, не понимают его смысл, а Agile/Scrum и прочее считают злом. А с другой стороны, Agile действительно не имеет смысла в бигтехе. Разберем причины.
Востребованности в командах и командной работе, как мы это понимаем в Agile, здесь попросту нет. Проекты всегда разбиваются на мелкие задачки, которые попадают в конкретные команды, соответственно, тамошние команды — это 2-3, максимум 4 инженера. Задачи мелкие, зависимостей мало и они узкие: договорились про API — на том и разошлись. Соответственно, серьезный механизм координации: стендапы и прочие синки — не нужен. И как говорил ранее, культура опирается на личные (индивидуальные) достижения, соответственно, не просто нет необходимости, но и попросту вредно опираться на команду, как ячейку оценку эффективности, развития и планирования. Соответственно, ретроспективы и прочие командные встречи тоже не нужны.
Идем дальше, почему задачи небольшие? Это самое большое мое разочарование в бигтехах. Я ожидал, что система OKR (Objectives and Key Results) работает в технологических гигантах так, как пишут в книгах про тот же Google, а оказался бардак. Возможно, на уровне топ-менеджеров OKR и работает, но не на уровне рядовых сотрудников. В Google ходят легенды, что когда-то OKR работал так, как написано в книжках: Ларри Пейдж и Сергей Брин каждую пятницу публично рассказывали про доходность и успешность компании, показывая конкретные цифры — но это все начало утекать наружу и влиять на биржевые махинации, и якобы поэтому практика прекратилась, хотя я не уверен, что этому стоит верить, так как информация всегда утекает. И сейчас это работает так: конкретный и измеримый OKR, к примеру: «Увеличить доходность продукта на 82% до 24.8 млрд долларов» — на уровне топ-менеджмента под NDA и публично недоступен, а инженеры видят только цель (Objective): «Увеличить доходность продукта на XX%» — то есть без конкретных цифр, а в ключевых результатах (Key Results) этой цели инженеры видят список конкретных проектов без привязки к реальным бизнес-результатам. Соответственно, специалисты не видят измеряемой цели, хотя направление, куда стремиться, в целом понятно.
Ты совершенно верно указываешь на то, что такая модель: бизнес-нацеленность сверху и индивидуализм и технологический фокус снизу — может совместно функционировать только при поддержке большого количества менеджеров.
Есть технические менеджеры: управлением они практически не занимаются, они предлагают новые идеи, запускают проекты и занимаются их реализацией — то есть непосредственно участвуют в разработке по сути в роли технического лидера: декомпозиция на задачи, рецензирование архитектуры и программного кода и написание кода. Технические менеджеры ценится ровно настолько, насколько они остаются инженерами.
Но есть огромный по численности аппарат программных менеджеров, которые по сути на ручном управлении тянут все проекты. Это ты верно подметил, что без них вся система бы не смогла функционировать. Но важно понимать, что инженеры не видят ценности в их работе, так как не считают их инженерами, ведь ценят в бигтехе только инженеров. В целом в инженерных организациях все, кто не инженеры — это люди второго или даже третьего сорта, их работу не уважают и не ценят, так как «они же тупо требуют репорты и рисуют графики».
Как итог, привычные нам навыки менеджеров и реально полезный сервис для специалистов: настройка процессов, управление и развитие команды, управление и развитие людей, а также управление ожиданиями заинтересованных лиц — не ценятся. Считается, что люди должны сами все делать.
Ну, и как следствие всего этого — системы управления проектами попросту нет, ну, или, как говорится, она по-настоящему гибкая. Все ведется в Excel! К примеру, я как-то заполнял отчет по своим проектам в 17 разных Excel-файлах, потому что с ними работали 17 разных программных менеджеров разных уровней и отчет по одному и тому же проекту надо было заполнять в 5 разных Excel-файлах для менеджеров разных уровней.
Если вы дочитали до этого места, значит, вам интересен полезный контент о современных методах управления. Чтобы узнавать про новые статьи, видео и бесплатные мероприятия, подписывайтесь на MAX-канал Enterprise Agile Russia.
ИИ-трансформация
ИИ активно внедряется: аналитика, написание программного кода (есть команды, которым запрещено писать код без ИИ) и документации, ИИ-агенты, анализирующие и исправляющие дефекты без участия человека, и т.п.
Кроме того, ИИ усилил процесс performance review. Раньше рецензенты попросту физически не могли осилить прочтение всего, что написал сотрудник. А теперь LLM практически мгновенно может оценить все артефакты сотрудника, что делает оценку более детальной. Для всех сотрудников это означает, что стало сложнее спрятаться: если ты реально приносишь пользу — это будет очень видно, но и обратно будет очень видно, если ты не приносишь пользу.
Растет и давление на технических менеджеров. И раньше-то менеджеров не любили, а теперь с приходом ИИ (с точки зрения генерации программного кода) вообще больше нет никаких оправданий, почему у них нет времени писать программный код наравне с инженерами.
Теперь про инженеров. ИИ-разработка повышает продуктивность инженеров. И если у компании в данный момент нет точек роста, то рост продуктивности инженеров приводит к снижению потребности в инженерах. Происходят сокращения инженеров: меньшим числом инженеров можно достичь тех же показателей — поэтому в компаниях без новых направлений происходят массовые сокращения. Но, как говорил ранее, несмотря на регулярные сокращения инженеров в бигтехах из-за ИИ, зачастую инженеры быстро возвращаются и порой в ту же самую компанию (layoffs).
Полная или даже частичная замена инженеров на ИИ? Думаю, что не стоит драматизировать. По крайней мере пока ИИ только создает новые инженерные позиции. ИИ рассматривают как инструмент повышения продуктивности, но не как замену мышления или способа принятия решения.
Конфликт B2C-культуры и B2B
Исторически бигтехи начинали с B2C-продуктов, лишь потом шли в B2B. В B2C есть клиенты и нет заказчиков. В B2C есть потребности пользователей и нет обязательств по работам или срокам перед заказчиком. В B2C есть требования по росту продукта, которые ты ставишь себе сам: что сделаешь — то сделаешь, когда сделаешь — тогда сделаешь. В том числе и поэтому сформировалась такая система управления и такая культура, о которых говорил ранее.
Но что происходит, когда все это переносится в B2B, где есть конкретные заказчики и контракты, прописанные функционал, сроки и неустойки за нарушения? Происходит культурный конфликт — и это очень больно! Инженеры привыкли придумывать классные фичи, но есть контракты с уже давно и жестко придуманными фичами. И, как следствие, огромное количество B2B-проектов не попадает в сроки, а компания постоянно платит десятки или сотни миллионов долларов неустойки (хотя на масштабе всего бизнеса это семечки).
К примеру, можно сравнить AWS (Amazon Web Services) и Google Cloud. Рыночная доля AWS значительно выше, чем Google Cloud, а сам продукт более клиентоориентирован. Не потому ли AWS более успешен, что Amazon изначально был в B2B и там есть близкое к enterprise проектное управление?
Но в чем секрет успеха
Важно понимать, что на масштабе таких гигантских компаний могут быть существенные отличия в отдельных направлениях. Мне кажется, что в любом бигтехе где-то все же все равно есть более профессиональное управление, иначе бы бизнес рано или поздно развалился.
Да, культура «все должны фигачить» поднимает высокую планку для людей, что не может не сказываться на результате. А идея: «соберем много умных людей — они что-то полезное, да сделают» — отчасти работает.
Рубрика «Без протокола»
Хотите выговориться? У нас теперь есть место для правды.
Сюда можно прийти с опытом, который по разным причинам нельзя сделать публичным. Истории, которые жгут руки. Провалы, которые страшно подписать своим именем. Инсайты, которые дались дорогой ценой.
Зачем это нам? Чтобы индустрия знала правду. Не причёсанную, не парадную, а настоящую. Ту, в которой закаляются сильные лидеры.
Зачем это вам? Выговориться. Выдохнуть. Поделиться тем, что накипело и знать, что это уйдёт в мир и кому-то поможет. А может, какая-то из историй потом поможет и вам. Минус только один: экспертиза останется анонимной и не попадёт в портфолио. Но иногда душа просит тишины.
Если хотите рассказать, пишите в личку генеральному директору Лидеров изменений — он разберётся, как правильно поступить в вашем случае.
Ждём ваши истории. Без протокола.
