Как Bending Spoons переделывает компании

Bending Spoons – это итальянская компания с очень интересной бизнес-моделью. Они выкупают бывшие когда-то легендарными компании, которые либо перестали расти, либо стали убыточными, и жестко их оптимизируют – увольняют большую часть команды, встраивают в свою инфру, выкручивают цены для лояльных пользователей, и заменяют дорогих американских инженеров дешевыми европейскими. Чисто чтобы понимать масштаб, им сейчас принадлежат Meetup, Airtable, Evernote, Issuu, Vimeo, StreamYard, Eventbrite и даже AOL. А на прошлой неделе они купили Miro!

Так вот, вышла статья от инжиниринг менеджера из Evernote, который рассказал, как поглощение и оптимизация выглядят изнутри. Там не то, чтобы какая-то eye opening история была, но вот несколько интересных шагов:

👉Каждому департаменту назначили дополнительного менеджера из Bending Spoons, задачей которого было присматривать за происходящим и задавать направление.
👉До сокращений всем желающим предложили уйти по собственному желанию с тремя зарплатами и ноутбуком.
👉Bending Spoons жестко оптимизировали косты – отказались от офиса, перевели всех с платного Zoom на уже доступный в офисном пакете Google Meet, заменили часть сервисов вроде платформ для проведения интервью или пушей на самодельные внутренние решения.
👉Подняли цену на подписку на Evernote в два раза.
👉Постепенно запустили сокращения в несколько волн, в результате весь персонал в США уволили и перевели разработку в Италию. Кому-то даже релокацию предложили!

Мне очень нравится наблюдать за этими ребятами. Большие продуктовые компании очень часто на удивление неэффективны – когда начинается быстрый рост расходы раздуваются моментально, а сокращать их обычно слишком больно, и получается это делать только у внешних людей без эмоциональных и политических инвестиций в текущее состояние дел.

Менеджеры как вымирающий вид

Компании продолжают резать косты и повышать эффективность за счет уменьшения количества прослоек между топ-менеджментом и рядовыми сотрудниками. Самые заметные примеры:

👉Uber планирует в два раза сократить количество маленьких команд, и в итоге на 20% срезать общее количество менеджеров.
👉Google еще в прошлом году срезали такие команды и их менеджеров на треть.
👉В Intel уменьшили количество слоев менеджмента с 12 до 6.
👉В Coinbase посокращали кучу людей с целью свести количество этих слоев до 5.

Эти изменения ведут к тому, что нагрузка на оставшихся менеджеров растет – от них требуют и быть играющими тренерами, и не бросать пипл менеджмент, при этом увеличивая количество людей. Многие не выдерживают и увольняются сами. При этом очередь из желающих их заменить тоже не выстраивается – судя по опросам, карьера менеджера больше не выглядит привлекательным вариантом.

Поэтому, кажется, тот карьерный тупик, которого мы всегда боялись в роли тимлида, теперь действительно настает.

Как использовать агентов в легаси кодовых базах

Держите хороший набор правил по тому, как программировать с агентами в кодовых базах с огромным количеством техдолга, которые никто по-настоящему не понимает:

👉Весь код можно условно побить на три зоны – зеленую, желтую и красную. Зеленый код хорошо спроектирован, покрыт тестами, его можно менять в целом без страха. Желтый – качество смешанное, тестам особо веры нет. Красный – бизнес-критичные части, в которых мало кто разбирается. Вот стратегия работы с кодом отличается от того, в какой вы зоне.
👉Давайте агенту контекст, который он не может сам вытащить из кода – объясните трейд-оффы, причины принятия каких-то решений, гайдлайны, которые не засунуть в детерминистические проверки и все в таком духе.
👉Если агент делает какой-то рисерч по коду, сохраняйте его результаты, чтобы эту работу не повторять дважды.
👉Перед тем, как вносить изменения в красную зону, покройте ее тестами, фиксирующими ее текущее поведение.
👉Всегда доводите миграцию до конца, и удаляйте старый код. Агенты хуже всего работают, когда видят два разных подхода к решению одной и той же задачи.
👉Не начинайте думать про автономную работу, лупы и прочую параллелизацию, пока проект не покрыт надежными детерминистическими гейтами.

Про силовые тренировки

Я в этом канале периодически напоминаю, что самый лучший способ для профилактики стресса, свойственного менеджерской работе – это спорт, а особенно – силовые тренировки.

Мы еще два года назад записали великолепную серию выпусков Подлодки про то, как вкатиться в силовые тренировки – и про то, как составить программу, и про то, как максимально эффективно нагружать мыщцы, и про то, как питаться и учитывать травмы и болезни.

👉Про составление программы
👉Про подбор тренера, выработку привычек, домашние занятия и другие прикладные вопросы
👉Про диету и здоровье

Гостем всех трех выпусков был мой тренер Стас большой приверженец методов доказательного фитнеса, а заодно – бывший дата саентист. Сейчас у него появилось несколько окон для новых клиентов, поэтому, если вы хотите потянуть веса под руководством кого-то, кто прочитал за вас весь пабмед, посмотрел всех доказательных качков, и будет вам регулярно строить всякие дикие графики – пишите @st_ts42!

А помимо выпусков Подлодки, можете почитать его канал!

Как менеджерам перестать быть кожаными роутерами

В период гиперроста компаний роль очень многих менеджеров сводилась к тому, чтобы быть кожаными роутерами – передавать информацию от руководства своей команде, и статус-апдейты обратно своим менеджерам. Сегодня ценность этой задачи заметно падает – слоев в компании становится меньше, а нужную информацию, при условии ее правильной организации, можно найти без участия дополнительных людей в этой цепочке.

Мы уже много раз обсуждали, что теперь от всех менеджеров требуется быть гораздо более техническими и глубоко погруженными в проекты своей команды, чем раньше. Вместо аккумулирования и передачи информации помогать своей команде принимать правильные архитектурные решения.

Вот какие практики советуют в статье, чтобы переключиться из режима роутера в режим технического менеджера:

👉Регулярно писать продакшн код, либо стать овнером одного из проектов команды
👉Регулярно работать с инженерами в паре над решением сложных проблем на всем протяжении процесса, не только ревьюить код
👉Принимать активное участие в написании дизайн-доков
👉В любых больших технических проектах думать над путями решения самостоятельно с помощью агента, чтобы составить о них собственное мнение

Советы все более чем разумные, кроме самого первого – мне все-таки кажется, что даже в изменившихся условиях у менеджера на критическом пути должны быть более важные задачи, чем писать фичи в какой-то конкретный сервис или чинить баги в нем, блокируя команду своей недоступностью.

Про профилактику выгораний

Очень часто причина выгорания находится не в количестве выполняемой работы, а в том, что она не приводит ни к каким ощутимым победам – не наступает момент вознаграждения за усилия. Это особенно верно для длинных проектов, или работы с очень отложенным эффектом. Иначе говоря, чем более абстрактна, далека или недостижима цель, тем больше вероятность того, что в команде будет наступать чувство выгорания.

Один из способов побороться с этим – декомпозировать такую далекую цель на более близкие и ощутимые ачивки, которые можно отпраздновать, и которые будут давать ощущение завершенности.

Статья мне понравилась своим примером – компания разрабатывала самолет, и это ну очень долгий проект. Что мне не понравилось – отсылка на marsallow test, в котором детям предлагали зефирки – он уже давно признан совсем не научным.

Про новое чувство потока

Вообще, мышление на основе первых принципов – это какой-то ну очень надоевший баззворд, который регулярно вставляют в абстрактные статьи про менеджмент. Но конкретно эта статья мне понравилась тем, что дает этому подходу очень приземленное объяснение.

Мыслить от первых принципов – значит откинуть весь свой прошлый опыт и знания, которые могут ограничивать пространство решений, вспомнить, какая проблема вообще решается и зачем, и взглянуть на нее свежими глазами.

Когда вы на самом деле понимаете, чего хотите достичь, то сделать первый шаг становится очень просто. А за первым шагом следуют и следующие, а вместе с ними – еще более глубокое понимание проблемы. И вот такой подход постепенного изучения проблемы свежими глазами вместе с агентами может стать тем, что заменит нам утерянное чувство потока.

Ходят слухи, что Amazon начал пытаться нанять обратно часть людей из списка сокращенных ранее в этом году.

Но топы не могут ошибаться, поэтому Amazon не отыгрывает свои решения, а запускает перспективный проект под кодовым названием "Boomeranf Reengagement Initiative". А такое уже тянет на повышенную премию в performance review!

Зачем платить за софт, когда все можно завайбкодить

Смотрите, какой веселый эксперимент нашел. Ребята решили проверить, можно ли заменить какую-то платную внутреннюю корпоративную систему на самодельную реализацию, написанную с агентами за два дня. На вход взяли подробную документацию, описанные юзкейсы, руководства и демки.

На выходе, ожидаемо, получили довольно убедительно выглядящий прототип, который, тем не менее, разваливался в большом количестве сценариев, отличных от описанного в документации дефолтного – часть фичей оказались стабами, никакой нагрузки система не выдерживала, а важные эдж кейсы не были учтены.

Несмотря на этот довольно ожидаемый итог, мне очень понравился один вывод из этого эксперимента:

Сложная система обладает эмерджентными свойствами. Это свойства, которые возникают на стыке компонентов, а не внутри них.

Суть в том, что вот такие эмерджентные свойства никогда не описаны в документации, и чаще всего не описаны в тестах. В лучшем случае они существуют в головах разработчиков и тестировщиков, а чаще не существуют вообще нигде. И чем сложнее система, чем больше в ней взаимосвязей, тем больше там таких эмеджентных свойств. Именно это делает задачу клонирования чужих продуктов или даже переписывания собственных с одного языка на другой такими сложными.

Я открыл клуб Подлодки про AI в разработке уже полгода назад. Он сильно помог участникам изменить рабочие процессы в их командах и научиться самим работать с агентами. За это время мы:

👉Провели 90 стримов про harness engineering и внедрение AI в команды
👉Собрали большую базу знаний про AI в разработке
👉Устроили аж два хакатона – делали автономные фабрики фичей и самообучающихся агентов
👉Собрали сообщество, в котором получается очень дельно обсуждать новости и помогать друг другу с решением проблем

Короче говоря, мне очень нравится, что получается – я и сам узнаю очень много нового, и радуюсь от того, сколько пользы получается дать другим участникам. Поэтому хочу напомнить и вам, подписчикам любимого канала, кому и зачем стоит вступить к нам:

Если вы хотите просто держать руку на пульсе происходящего в индустрии

Я вытаскиваю очень крутых экспертов из Uber, xAI, Meta, Яндекса, Cursor, а еще из кучи стартапов. Они рассказывают, как работают их команды – и вы можете узнать у них то, о чем на конференциях начнут говорить только через год.

В нашем закрытом чате мы разбираем все важные новости и изменения подходов к разработке. Если нет времени читать – вам приходит дайджест с главными выводами.

Если вы хотите вкатиться в лучшие практики AI разработки

Каждую неделю мы проводим 2-3 стрима на разные темы, где есть куча полезной информации – от автоматизации процессов QA или SRE до того, как строить внутренние AI платформы.

В нашем чате есть специализированные комнаты по самым горячим темам – например, локальные модели, или SDD. Клубчане делятся там своими сетапами и практиками.

А еще вам доступен RAG по всему контенту чата и прошедших стримов, так что найти нужный совет очень просто!

Если вы уже активно внедряете AI в свою работу или команды

Это ровно то, чем занимаются все в клубе – так что вы сможете найти единомышленников с похожими проблемами. Как работать со скептиками, как не попасть в зависимость от вендоров моделей, как внедрить локальные модели, как перестроить процесс разработки – все эти вопросы можно обсуждать в чате и на Random Coffee.

🔗Детали, расписание, заявки в клуб

на прошлой неделе, кстати, как раз проводили круглый стол про внедрение Spec Driven Development на масштабе огромных проектов и десятков команд разработки, так что самое время ворваться и посмотреть в записи!

Путь менеджера в 2026

Менеджеров сейчас пытаются закопать все, кому не лень – но при этом без них все равно никак. AI не поменял фундаментальных ограничений человеческой натуры, и нам все так же нужно уметь планировать работу, выстраивать процессы коммуникации, решать человеческие проблемы и помогать друг другу расти. В статье – довольно трезвый взгляд на то, что меняется в работе менеджера в 2026 году:

👉Надо заново учиться делить работу между людьми и следить за поддерживаемостью кода – и потому что один человек теперь делает больше, и потому что код стал дешевле, а ошибки – нет.
👉AI дает хорошую видимость того, кто чем занимается, но не дает понимания, особенно в сложных вопросах. Поэтому нужно учиться понимать, когда полезнее говорить с людьми, а когда с AI.
👉Нужно учиться справляться с выросшими ожиданиями – вам будут давать больше людей, ответственности, неопределенности, да еще и заставлять внедрять во все это AI.
👉Нужно разруливать конфликты нового вида – из-за дешевости кода люди начинают строить свои костыли сбоку, и очень не хотят отказываться от них.
👉Нужно бороться с эрозией доверия между людьми. Из-за способности AI быстро отвечать на вопросы люди начинают меньше общаться, а значит теряются связи и доверие.

Автор дает и несколько советов по тому, как справляться с этими изменениями и в целом не сваливаться в полный хаос. Мне особенно понравился один из них – осознанно замедляться, тратя часть выигрыша в продуктивности на живое общение людей – командные встречи или дизайн-ревью.

Бесплатный онлайн-тулкит по выживанию в IT для руководителей

Зарплатные гонки и “розовые единороги” в IT закончились. Layoffs говорит, что ожидаемое кол-во увольнений в 2026-м будет ровно в десять раз выше, нежели в 2021-м. LinkedIn переполнен постами о поиске работы, Хабр — очередными разборами рынка, а фраза “реорганизация” звучит, скажем так, по-другому.

Мы, в Стратоплане, хотели бы, чтобы руководители сегодня не засыпали с мыслью о том, чего ждать от завтрашнего дня и не работали с тревожными мыслями на фоне “а что, если я следующий”.

Потому вместе с экспертами извне мы задумали бесплатный интенсив «ИТ-зима. Набор для выживания». Каждый день разбираем один конкретный инструмент, чтобы не просто не “замерзнуть”, но и вырасти, потому что именно зимой освобождаются роли и решается, кому доверять больше.

Без подписок на каналы и платы за вход

По датам – 12–23 октября, по будням, в формате вечерних онлайн-эфиров с записями и лонгридами.

Регистрация здесь: https://stratoplan-school.com/marathon/tlgr

О чем будем говорить:

– как переводить свою работу в измеримый результат на язык бизнеса
– что думает о себе кандидат, и что на самом деле ищет компания 
– управление вверх и деньги
– и еще не менее 6-ти критически важных фронтов работы руководителя

Ветра зимы уже здесь, давайте готовиться вместе!

Где стафф инженеру брать идеи проектов

Классическое ожидание от staff-level инженера – это умение самому найти идеи, стоящие того, чтобы их реализовать. Какие-то идеи могут следствием наблюдаемых в компании проблем, какие-то – запросами пользователей, а какие-то – реакцией на то, что происходит на рынке.

👉Идеи можно брать из сигналов, производимых обслуживаемой системой: инциденты и постмортемы на них, стоимость каких-то кусков инфраструктуры, сопутствующая стоимость вашей собственной работы, происходящая из-за каких-то проблем в DX.
👉Идеи можно брать от ваших пользователей, если вы делаете внутреннюю платформу – конечно, помня о классическом уроке из продакт-менеджмента про то, что фиче-реквесты не стоит воспринимать буквально: надо регулярно разговаривать с пользователями, интервьюировать их про проблемы, смотреть за тем, пытаются ли они решать с помощью ваших инструментов юзкейсы, для которых они и не бвли предназначены.
👉Очевидно важный источник сигналов – ваша организация: OKR, общая стратегия, проблемы, о которых регулярно вспоминает ваш менеджер, любые миграции между техническими стеками и платформами, которые имеют свойство никогда не заканчиваться.
👉Сигналы от индустрии: сравнивать ваши системы с SOTA того, что есть на рынке.

Новые выпуски тимлидских подкастов

👉"Бреслав и Ложечкин" про то, что такое сложность и откуда она берется
👉Подлодка про AI в математике с обсуждением того, насколько сильно в сообществе математиков сейчас повторяется то, что мы уже видели среди программистов
👉КОДА КОДА про то, как читать в эпоху AI и фильтровать входящую информацию

Состояние нашей индустрии в 2026

Хороший срез основных трендов в разработке на сегодня:

👉Все меняется очень быстро – мы и раньше привыкли к довольно быстрому темпу смены технологий, но ничего даже близкого к текущей скорости еще не было.
👉Никто не пишет код руками (тут подтверждаю, я в последнее время интервьюировал десятки инженеров по всему миру, и руками хорошо если 5% работы делаются).
👉Большинство одновременно работает с несколькими агентами в параллель, и учатся справляться с когнитивным перегрузом из-за этого.
👉Количество PR за авторством агентов точно стало больше, чем человеческих. Это касается и всего GitHub, и ситуации в отдельных компаниях.
👉Скиллы стали стандартным используемым примитивом и внутри компаний, и в сообществе.
👉IDE очень-очень быстро умирают.
👉Довольно значимая часть агентских задач инициируются из Slack.
👉Все вокруг экспериментируют с разными видами автономных фабрик.
👉Большие миграции с одной технологии на другую занимают недели и месяцы, а не годы.
👉Токенмаксинг уходит в прошлое, все начинают следить за тратами на AI и искать пути сэкономить.
👉Проектная работа постепенно превращается в задачи на одного или максимум двух человек, но никак не на большую команду.
👉Инженерные специализации пропадают. Например, уменьшается спрос на iOS/Android/Frontend, но растет спрос на более универсальных инженеров.

Стартует новое исследование рынка тимлидов

Как мы тут обсуждаем практически каждую неделю, этот год принес с собой гигантский шифт во всем перечисленном. Менеджеры снова должны быть более техническими и погруженными в детали происходящего, команды стали меньше, а объем работы - на порядок больше. Это точно происходит в заграничном бигтехе и стартапах, но вот насколько докатилось до России – вопрос.

Так вот, ребята из DevCrowd делают ежегодные исследования того, что происходит с разными айтишными профессиями в русскоязычной среде. Одно из самых больших исследований – как раз про руководителей разработки – как меняются задачи, скоуп роли, проблемы, важные скиллы и зарплаты.

Опрос анонимный, все результаты будут в открытом доступе где-то в середине декабря. Голосуйте, я потом обязательно сделаю разбор!

Синтетические митинги

Если вам надо срочно показаться занятым и для тех, кто смотрит в календарь, и для тех, кто смотрит вам в монитор, держите конструктор синтетических митингов:

👉В календаре появляется встреча на нужный слот
👉На мониторе показывается UI стандартного митинга, с голосами, обсуждающими заданную тему – от All Hands до звонка с разбором инцидентов
👉Выводите звук от встречи прямо на динамики, и никто к вам в офисе не подойдет, так как все будут уверены, что вы заняты