Все пишут, что надо делать. А я сейчас напишу, что делать не надо.

Перестаньте избегать конфликтов.

Современная корп культура демонизировала конфликты на работе. Компании распечатали этикетку «Да ну, он конфликтный» и готовы тут же налепить ее на лоб (или на рот) людям, которые в случае конфликта не стремятся как можно быстрее его потушить.

Но избегание конфликта чаще бывает хуже, чем сам конфликт.

Во-первых, когда вы принимаете конфликт, вы можете ОБМЕНЯТЬСЯ МНЕНИЯМИ. Потому что конфликт — это когда два человека имеют два разных мнения по поводу. Но чтобы избежать конфликта, одна из сторон свое мнение прячет. В итоге, компания лишается мнения сотрудника.

Тут цена избегания конфликта — это половина решения.

Во-вторых, избегание конфликтов это плохой термин. На самом деле произойдет консервация конфликта. Невысказанное мнение может поселиться в голове у автора в ожидании момента, когда все провалится. Ведь тогда можно будет сказать «а я же говорил»!

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

И я не говорю — идите скандальте.

Я говорю — не нужно путать конфликт со скандалом. Конфликт — это «я думаю иначе и готов об этом говорить». Скандал — это когда вместо аргументов пошли эмоции. Первое — признак зрелой команды. Второе — признак того, что первое слишком долго избегали.

Кодинг решен. Осталось решить 5к issues в GitHub'е! 🫡

Три легендарных правила митингов Джобса.

Их знают все.

Их никто не соблюдает 🙂

Правило первое — на встрече должно быть ЕЩЁ МЕНЬШЕ людей.

Как-то раз на еженедельном митинге с рекламным агентством Джобс замечает незнакомое лицо. Останавливается. Показывает пальцем: "Кто ты?" Девушка по имени Лорри объясняет, что её позвали, потому что она работает на смежном маркетинговом проекте. Джобс вежливо кивает и говорит: "Я не думаю, что ты нужна на этом митинге. Спасибо."

Лорри вышла, потому что когда Джобс говорит тебе выйти, ты выходишь.

В другой раз Барак Обама позвал Джобса на встречу техно-магнатов — Джобс отказался. Ответил, что слишком длинный список приглашённых. Президенту. Соединённых. Штатов.

Потому что много людей на встрече — это и трата денег компании, и снижение эффективности.

Я сам отклоняю по несколько встреч в неделю и пишу людям, что не вижу своего импакта от посещения. Если вдруг я реально нужен, мне про это скажут.

Правило второе — у всего должно быть имя и фамилия.

Джобс считал, что у каждого пункта в повестке встречи есть конкретное имя. Не "команда разберётся". Не "давайте подумаем". Имя и фамилия. Человек, который отвечает. В Apple даже фраза есть ходовая: "Who's the DRI on that?".

У себя в команде я всегда строю культуру аккаунтабл: если мы о чем-то договорились, мне обязательно нужен конкретный человек, который будет отвечать за выполнение договоренности. Исключений не бывает.

Правило третье — презентации не нужны.

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

Тут я Джобса не поддержу. Мне нравятся презентации. А вот мой руководитель, наоборот — топит за 6-pager'ы как у Amazon. Но я считаю, что если мысль нельзя изложить на одном слайде, надо упрощать.

1 слайд >>> 6 страниц текста. Prove me wrong, как говорится. Сори, Джобс.

А теперь внимание — вопрос!

Почему через 15 лет после ухода Стива средняя компания из топ-500 всё ещё проводит митинги, на которых 14 человек смотрят в ноутбуки, пока кто-то листает 47 слайдов с графиками, которые никто не понимает?

Ответа не будет.

Потому что вы его знаете 🙂

Я не понимаю, почему это все не обсуждают.

2-го Марта: Амазон отвалился из-за AI-кода. Итоги: 120 тысяч заказов потеряно.
5-го Марта: Амазон решил, что прикольно получилось и надо повторить. В этот раз AI не виноват, но 6+ миллионов заказов Амазон все равно потерял.

Это плохо, но в целом — все падают, все поднимаются.

Странно другое.

BusinessInsider опубликовал новые правила, которые Амазон выкатил для инженеров. И я чего-то не понимаю. Вот текст коротко:

Amazon вводит временные правила на 90 дней для ~335 критичных систем (Tier-1), которые напрямую влияют на покупателей.

Что теперь обязательно: два ревьюера на любое изменение кода, формальное документирование и аппрув через внутренний тул, автоматическая проверка на соответствие правилам reliability-инженерии. Всем владельцам Tier-1 систем и их директорам/VP велено провести аудит всех изменений кода в проде.

Амазон при этом отрицает, что джуны и мидлы теперь обязаны получать подпись синьоров на AI-ассистированные изменения.

Честно: это БАЗА. Аппрувы, документация, правила SRE. Я думал, это уже лет 5 есть в каждой компании.

А оказалось, что нет.

Амазон изобрёл мою любимую фразу «you build it, you run it». Оказалось, он забыл про «you review it». Если вам кажется, что у вас-то всё нормально — вспомните, что Амазон тоже так думал.

// а я правильно понял, что через 90 дней можно опять без аппрува катить в прод будет?

Потратил 30 минут на новую статью McKinsey, чтобы вам не пришлось.

Свежая статья McKinsey — «Courageous Conversations: How to Lead with Heart». Рассказывают про четыре типа «смелых разговоров», которые должен вести CEO. Приводят цитаты Черчилля и Кира Великого! Слово courage встречается 47 раз, если вам интересно.

Но я отжал воду и вот что получилось.

🔹Obligation to dissent — несогласие как обязанность

Современное лидерство — это не про «у нас можно спорить с начальством» (это типа декларация). Современный руководитель создает атмосферу «ты обязан сказать, если видишь проблему».

Разница: лидер не ДЕКЛАРИРУЕТ принципы, а СОЗДАЕТ окружение, в котором эти принципы прорастут.

McKinsey предлагает назначать «chief challenger» в совещаниях — человека, чья работа тестировать допущения группы. Идея не новая (premortem, red team), но формулировка «обязанность, а не право» меняет фрейм. Когда ты молчишь — ты не «осторожный», ты не выполняешь свою работу.

У меня в команде такой человек есть на постоянной основе. Он выступает в роли адвоката дьявола, и я постоянно его за это публично благодарю. Это важно: как лидер вы должны поощрять смелость выступать в такой роли. Кстати, привет тебе, сотрудник Х, если ты себя узнал!

🔹Hardware vs Software в обратной связи

Типичная проблема: менеджер даёт обратную связь и мешает в одну кучу факты, эмоции, оценки и пожелания. Получается либо сухой удар цифрами («SLA просел на 15%, разберись»), либо мягкое облако без конкретики («хотелось бы больше ownership»).

McKinsey предлагает простое разделение. Сначала — hardware: что произошло, какие были договорённости, какой результат. Потом — software: почему ты это поднимаешь, с каким намерением, чего хочешь для человека.

«Релиз опоздал на две недели, потому что мы поздно подключили инфру» — это hardware.

«Я говорю это не чтобы наказать, а потому что хочу, чтобы в следующий раз ты сам эскалировал раньше» — это software.

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

🔹Withholds — невысказанные обиды

McKinsey удивляет нас фактом: команды с накопленным напряжением работают хуже, чем счастливые команды. Спасибо, McKinsey! Ждем статью «Быть здоровым лучше, чем быть больным: доказываем на цифрах» в вашей следующей рассылке.

А если серьезно, как раз 5-го Марта я писал пост на тему конфликтов. Моя позиция: лучше столкнуть два мнения, чем позволить невысказанным словам копиться где-то внутри человека.

tl; dr

Но главная мысль статьи — не декларировать, а создавать. И я подписываюсь под ней: я слишком много видел деклараций и гораздо реже — действия.

Когда ты помогаешь человеку, ты ему вредишь.

Представьте: к руководителю пришел сотрудник: «Не могу разобраться с проблемой Х». Руководитель рассказывает, как надо сделать, чтобы проблему решить. Иногда маэстро даже сам садится за рояль, чтобы на своем примере показать, как надо.

Это рутинная ситуация. Все так делают. И в этом проблема.

Ученые взяли тысячу человек и протестировали их креативные способности ПОСЛЕ получения помощи извне (исследование). Ну то есть: людям помогали, а потом давали тесты на креативность.

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

Не буду тянуть: в итоге, креативность первой группы ухудшилась при решении последующих задач.

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

А еще хуже то, что маэстро и сам не против сесть за рояль. Блеснуть своими знаниями архитектуры, оргдизайна — да чем угодно. Потому что объяснять и подводить сотрудника к правильному ответу трудно, а сыграть самому — легко, приятно и плюс к настроению.

Но губительно для сотрудника.

Я понимаю, что ПРОЩЕ выдать сотруднику решение, чем полчаса подводить его к решению. Но проще — не значит лучше.

Когда к вам в следующий раз придут за советом, попробуйте выступить не в роли маэстро, а в роли седобородого старца-учителя кунг-фу. Я вот недавно для себя открыл вопрос: «Как думаешь, о чем я сейчас думаю, глядя на эту проблему?» — очень помогает выступать в роли старца.

Чувак на Реддите пишет: мы подключили AI-агента отвечать на вопросы про метрики. Все были в восторге — быстро, детально, красиво.

Три месяца спустя выяснилось: агент галлюцинировал цифры. Буквально выдумывал «правдоподобные проценты».

Самое интересное: VP of Sales и CFO принимали решения и продавали их совету директоров по этим цифрам! Обнаружили случайно, когда то-то попросил перепроверить одну цифру.

И у меня есть непопулярное мнение по поводу: AI не виноват.

Это проблема организации, где НИКТО за три месяца не сказал: «подожди, а откуда эта цифра?». Они вообще до AI свои цифры проверяли? Или аналитик Вася тоже мог нарисовать что угодно, и VP of Sales бы точно так же побежал перекраивать территории?

Правило простое: AI — это инструмент генерации драфтов. Не источник истины. Если процесс принятия решений не включает шаг «а давайте проверим», то не AI сломал аналитику. У них ее не было.

// Отдельный респект тому безымянному герою, который попросил перепроверить цифру.

Два приема из мира Private Equity CEO.

PE CEO — это считай смертники. Они управляют компаниями, которые купили крупные фонды. Наемники. Смертность до 70% — 70% из них УВОЛЬНЯЮТ в первые годы их работы. Потому что их работу очень просто измерить: если вывез конкретный кейс, молодец. Если нет — попадаешь в 70%. Их часто критикуют за методы, но они показывают результат.

Короче, выжившие PE CEO напоминают мне о поговорке: «Опасайся старых людей в профессии, где обычно умирают молодыми».

Первое — посмотрите на компанию глазами внешнего инвестора.

Я это называю «провести аудит». Нужно сесть и перебрать на листке бумаги все проекты, которыми команда занимается. Только думать нужно как аудитор: ваша цель предоставить отчет заказчику аудита, а не подтвердить собственные фантазии. Если сможете абстрагироваться, это — крайне мощный прием. Поэтому успешные PE CEO его используют, чтобы очищать портфели.

Совет: попробуйте этот прием после отпуска. Мне после НГ было в разы легче смотреть на наши проекты свежим взглядом.

Слабые СЕО ждут, пока борд придет к ним с вопросом «Почему мы занимаемся этой фигней?», а сильные приходят с таким вопросом сами.

Второе — перерисуйте с чистого листа

Например: оргструктура. Ее руководители воспринимают как данность; нечто, что просто дано. Как в школе на математике, мы не пытаемся изменить дано. А между тем, закон Конвея говорит: архитектура ПО повторяет вашу оргструктуру.

Поэтому попробуйте нарисовать вашу идеальную оргструктуру с нуля. Без привязки к текущей. Это потребует от вас больших усилий, чтобы отойти от текущей картины, но это и есть out-of-the-box thinking, который все так любят.

Когда я рисовал оргу Горизонталей в Циан, я именно так и делал.

Эти приемы работают для всех менеджеров и инженеров.

Потому что на позиции СЕО уже поздно учиться, на позиции СЕО нужно уже уметь. Поэтому учиться нужно прямо сейчас. Если вы тимлид — проведите «внешний аудит» своих проектов и честно спросите себя: какие проекты вы бы закрыли, если бы были аудитором? Результаты попробуйте обсудить с вашим продактом.

Попробуйте оба приема — потому что руководителями не становятся в день назначения. К роли руководителя долго идут.

CEO NVidia предложил платить инженерам токенами. Не вместо зарплаты, но накидывать токенов сверху в размере половины самой зарплаты.

Ну, то, что пчелы выступают за более активное потребление меда — логично. Но идею подхватили в западном бизнесе и вангуют, что токены станут «четвертым столпом» компенсации. Первые три — это зарплата, опционы и премия.

Думаю, у нас тоже очень скоро в вакансиях появятся плашки «выдаем макбук и подписку Claude Max».

ИИ не убивает мышление. Он убивает вынашивание.

Я не ретроград и не стану жаловаться, что «из-за ИИ вы перестанете думать» — это неправда, не перестанете.

Проблема в другом: вы перестанете ВЫНАШИВАТЬ мысли.

Например, вы решаете задачу «Как ускорить разработку». Креативный процесс можно разделить на четыре этапа (модель психолога Уолласа):

1. Подготовка — собираете материалы про процессы, фреймворки и прочее.
2. Инкубация — подсознание перемалывает задачу, пока вы спите. Или кушаете. Или бегаете. Связи образуются сами, без вашего участия.
3. Эврика — озарение! Вы поняли, как ускорить разработку.
4. Валидация — вы проверяете, что ваше озарение реально работает. Знаю людей, которые отрицают этот этап; постарайтесь не попасть в их число.

ИИ отлично ускоряет первый этап. Но начисто УДАЛЯЕТ второй. Никто не будет думать неделю, если можно спросить ИИ и получить ответ за минуту.

И это катастрофа, потому что именно стадия инкубации формирует ваш профессиональный ВКУС. Вкус — это не абстракция. Это результат тысяч микрорешений, через которые вы прошли сами. Когда ты отсмотрел тысячи MR'ов, ты начинаешь безошибочно видеть плохое решение — не потому что выучил правила, а потому что прожил последствия. Тысячи раз.

Но если за тебя идею вынашивал ИИ, у тебя нет чувства вкуса. Зато есть быстрый результат!

Поэтому подрастающее поколение инженеров (и не только) рискует получить результат, но не сформировать вкус: ни в коде, ни в архитектуре, ни в управлении.

Армия специалистов без вкуса — вот проблема. Потому что для человека со вкусом, ИИ — ускоритель. Остальным ИИ масштабирует безвкусицу.

OpenAI говорит, что 10x-инженеры — это прошлый век. Теперь есть 1000x. А скоро будут миллион-x.

Фраза принадлежит вице-президенту OpenAI в официальном интервью: "There are easily 1,000x engineers now. I don't even know if that's the limit. There may be 1,000,000x engineers coming." То есть он ТОЧНО не шутит и реально так думает.

Давайте на секунду отнесемся к этому серьезно. Да, это тяжело, но давайте пробовать.

1000x-инженер — это один человек, который работает как тысяча. Тысяча! Средняя компания в тысячу инженеров — это годовой фонд оплаты труда в сотни миллионов. И нам говорят, что один парень с Codex заменяет их всех.

В самом OpenAI при этом работает 1200 человек. Заменит ли их всех компания на одного миллион-х инженера?

Дальше — больше. Нам говорят, что Codex написал 90% кода собственного приложения. Любой, кто хоть раз катил что-то в прод, знает: написать код — это 20% проекта. Остальные 80% — понять что строить, не сломать прод и починить когда сломалось. И вот именно этих 80% AI не касается.

Более того — в том же интервью инженеры OpenAI сами признают: новый bottleneck — code review, security, CI/CD. Все то, что требует человеческого суждения. А суждение в 1000 раз не масштабируется. Ни с каким агентом.

Это как сказать, что принтер сделал писателей в 1000 раз талантливее. Печатать быстрее — да. Писать лучше — с чего бы.

Но продавать "1000x" выгодно. Потому что по ту сторону стола сидит CEO, который не понимает ограничений. Он слышит "1000x" и думает: так, у меня 200 инженеров, значит мне нужен один. Или ноль, если агент справится сам. Экономия!

Поэтому всегда важно помнить: у всех заявлений про 1000-х инженеров ровно одна цель — чтобы компании заносили бабки в кассу OpenAI.

// мой ChatGPT 5.4 редактор оценил пост "6/10 как фактологически неуязвимый текст". Интересно, почему? Фактология вся тут, если что.

Самый опасный контракт — тот, который вы не подписывали, а клиент уже считает действующим.

Допустим, у вашего сервиса нет явного SLO. Но вы решили: 99.9% аптайма вам достаточно. Значит, сервис может лежать 2 часа в квартал. Может, это окно под обслуживание. Может — плата за более спокойные релизы. И это нормально.

Но ни клиенты, ни заказчики ничего не знают про ваш SLO. Он живет у вас в голове.

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

А потом сервис падает всего на час.

В вашем мире все хорошо: вы не нарушили SLO ни на копеечку!

В мире вашего клиента (стейкхолдера) все не так. Инженеры уже не молодцы, инженеры — бездельники на зарплате, которые не могут нормальный сервис предоставить. Клиентов нельзя винить — вы ПОКАЗАЛИ им высокий аптайм. Они привыкли к нему. А ваши SLO были только у вас в голове. Их никто не видел.

И ведь это не только SLO касается.

Роадмап «в общих чертах» превращается в обещание. Быстрые фиксы багов — в ожидание, что так будет всегда. Ответы в ночное время — в контракт на круглосуточную доступность. Паттерн один: если что-то хорошее происходит регулярно, оно становится обещанием.

Про «надежда — не стратегия» вы слышали. Так вот мой новый лозунг: «Лучше разочаровать словами, чем подвести делом».

Поэтому: транслируйте SLO заранее. Поставьте «subject to change» на роадмап большими красными буквами. Скажите стейкхолдеру срок, который ему не понравится — но который вы сможете реализовать.

Команда, которая открыто называет свои ограничения — не слабая. Она единственная, которая реально управляет ожиданиями, а не управляется ими.

Мне нравятся такие статьи. Но они не набирают просмотров — потому что открыто говорят «мы не знаем» вместо тотальной паники.

MIT Technology Review поговорили с экономистом из Чикаго. Вопрос простой: AI реально заберет рабочие места или нет?

Ответ неудобный: мы понятия не имеем.

Смотрите: OpenAI и Anthropic измеряют «exposure» — какой процент задач в профессии AI теоретически может выполнить. Допустим, 50% разработчика может выполнить AI. Выглядит научно. Выглядит как данные. Но это НЕ ТЕ данные.

Это даже не тот вопрос.

Для нас с вами ключевой вопрос такой: если AI делает разработку дешевле, спрос на софт вырастет или нет? Потому что если вырастет сильно — компании наймут БОЛЬШЕ инженеров (или будут больше платить). Если не вырастет — уволят (или станут меньше платить). Это называется эластичность спроса по цене. Ее обычно в районе 10-го класса проходят. Проблема экспертов-паникеров в том, что для большинства профессий данных по эластичности просто не существует.

Высокий exposure ИТ в AI может говорить о том, что инженеров массово сократят. Но так же он может говорить, что миру потребуется в два раза больше инженеров.

Без данных об эластичности спроса мы просто не знаем ответа.

Экономист в интервью говорит: «нам нужен Манхэттенский проект по сбору этих данных.» Задача нерешаема без вливания тонны ресурсов, которые вливать никто не будет. А пока — все прогнозы про AI и работу это гадание. Это весело и интересно (и давайте честно: сейчас мы все это делаем), но к будущему отношения не имеет.

Так что когда в следующий раз кто-то уверенно скажет вам «через 5 лет AI заменит всех» — спросите его: покажи мне эластичность спроса в этой области. Ответом будет тишина.

ИИ — это автомобиль.

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

Человек пройдет везде: овраги, леса, горы; машине нужна инфраструктура. Но при наличии инфраструктуры (и инженеров, которые ее поддерживают), машина может проехать тысячу км в день. И еще тысячу на следующий день. А у человека ножки, мы так не умеем.

Но люди продолжают строить тропинки для людей, мало кто пытается проложить дороги.

Например: заметки со встреч фиксируются в лучшем случае у кого-то в трекере. Но ваш Claude Code не знает, что вы вчера договорились «никогда больше не использовать /api/v2/users». Если вы хотите кататься на ИИ, придется автоматизировать выгрузку таких договоренностей куда-то в базу знаний ИИ.

И кстати, ИИ не умеет ходить по тропкам «эту инфу знает только Вася, спроси у него». Придется выгружать Васю в документацию.

Я своими глазами увидел, на что способен ИИ, которому люди проложили дорогу. Он за 2 дня сделал то, что человек делал бы два месяца: переписал наш сервис на питон вместо шарпов.

Что вновь возвращает меня к мысли, которую я повторяю последний год: ИИ нас не заменит.

Мы для него еще даже дороги не проложили.

Ой да кому мы нужны...

И другие фразы, с помощью которых можно забить на ИБ.

Правда, есть нюанс.

Сегодня Booking.com подтвердил утечку клиентских данных: имена, email, адреса, телефоны и детали бронирований. Пострадавших уже предупреждают о фишинге — в том числе через мессенджеры, с точными деталями поездки. Сколько людей затронуто, компания не раскрывает.

Но я тут не злорадствую. Этот пост — напоминание, что информационная безопасность разрушается в тишине. Грохот мы слышим только когда становится слишком поздно.

Начните завтрашний день с ревью ИБ тикетов вашего проекта.

Потому что некоторые риски любят, когда их называют «не срочно».

Признавайтесь, чей ИБ отдел?

Приносите на работу себя целиком.

Красивый тезис, но очень плохой совет.

Аутентичность в компаниях любят. Но редко могут внятно объяснить, что вообще имеют в виду. Психолог Маслоу (тот самый) определяет аутентичность как «отсутствие фальши». Коллективное бессознательное дает иное определение:

Не беспокойся о мнении окружающих, будь честен с собой и окружающими, будь НАСТОЯЩИМ собой, будь ЦЕЛЫМ собой. И всегда придерживайся своих ценностей!

Давай прям по частям разбирать, что ли.

Всегда будь честен с собой и другими!

Посыл интересный, но проверять не рекомендую. Например, Стив Джобс честно говорил «this work is shit» (цитата) и вряд ли сотрудники были в восторге от такой честности. Если работа реально is shit, все равно дать аккуратную ОС. Вам ведь нужно чтобы человек сделал работу хорошо, а заявление про is shit его демотивирует, хотя и будет честным. Не рекомендую.

К тому же, когда Стив Джобс говорит человеку «this work is shit», человек идет переделывать. Если так говорит не Стив Джобс, человек совершенно справедливо идет в HR.

Не парься, что о тебе подумают!

Прикольно звучит, но не очень прикольно работает. Я работал с людьми, которые на мою обратную связь отвечали «Ну вот такой я человек!». Причем обратная связь была, что не надо прям в открытую говорить стейкхолдерам, что они тупые. Я не утрирую, кстати. Мне потребовались месяцы, чтобы нарастить на мощные харды человека софт-скиллы. Но сначала мне пришлось воевать с позицией «Ну вот такой я человек!»

Всегда следуй своим ценностям!

Очень опасная позиция для лидера. Я понимаю, что мои ценности кончаются там, где заканчиваюсь я сам. Например, моя ценность — работа. Много работы, меньше отдыха. Если я буду следовать своим ценностям, я буду строить команду трудоголиков. Но загонять людей в переработки из-за собственных ценностей неправильно .

Поэтому для себя я думаю вот как:

Приноси на работу не всего себя, а лучшую версию себя.

И у меня для вас есть личная история.

Зимой 2019 года мне было довольно фигово из-за некоторых проблем.

Но я уже был тимлидом и где-то на уровне ощущений понимал, что нельзя тащить мое уныние в команду. Так что я загуглил примерно такое: «как перестать быть унылым, если очень надо». Гугл ответил: если ты будешь улыбаться, через 5-10 минут тебе станет нормально. Звучало странно, но проверка ничего мне не стоила. И я попробовал.

А потом всю зиму выходил из метро на станции Савеловская и всю дорогу до офиса улыбался. Да, прохожие странно на меня смотрели. Но в офис я входил уже без грустной морды, так что метод для меня сработал.

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

Именно это я и называю «приносить лучшего себя». Такая аутентичность мне нравится.

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

ЗАНЯТОСТЬ = ПРОГРЕСС

Но между прогрессом и занятостью нет прямой связи. Зато рост занятости приносит пользу и менеджеру, и сотруднику — и за это занятность так горячо любят.

Занятость полезна сотруднику: она как минимум служит индульгенцией перед руководством. «Я занят» означает, что я отрабатываю свою зарплату. В жалобе «Я занят» порой сквозит гордость; человек сигнализирует, что востребован и важен, его жизнь наполнена делами.

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

Единственный, кто не рад тотальной занятости — это компания.

Потому что когда все заняты, некому задать очень громкий вопрос: «Господа, а не херню ли мы тут делаем?» Этот вопрос не влезет между встречами. Ему нужно уделить время.

А у занятого человека нет времени на сомнения.

Я своими глазами видел что происходит, когда у команды нет этого времени (всем примерам 3 года и более, если что):
• Команда полгода долбила по инерции задачи, которые приносили МЕНЬШЕ денег, чем компания тратила на содержание команды. Но все были заняты.
• Менеджер соглашался на все влеты от стейкхолдеров и в итоге тратил весь ресурс команды на влеты. Почти за год такой работы ни одного крупной фичи команда не выкатила, только небольшие хотелки больших начальников.

Если вы — руководитель, у вас ОБЯЗАНО быть время на подумать. В идеале, вы должны обеспечивать его и вашим сотрудникам.

Нет никакой разницы, насколько много вы работаете, если вы работаете не в ту сторону.

// кстати, если система поощряет занятость, она получит максимальную занятость. Польза в сделку не входила.

Аргументы и камни

Представьте, что вы пишете стратегию. Хорошей идеей станет добавить в начало блок «проблемы» или «вызовы» — ведь хорошая стратегия обязана отвечать на вызовы или решать проблемы.

Вопрос: сколько проблем перечислять?

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

Но это неправда.

Рационально посыл верный: больше аргументов — лучше. Но Канеман давно доказал: человек — не рациональный агент. По крайней мере, не всегда. Если аргументов будет слишком много, они рассеят внимание ваших слушателей и приведут к обратному результату. Люди не складывают аргументы как числа в таблице.

После определенного порога новые аргументы уже не усиливают позицию, а размывают ее.

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

Поэтому я всегда советую делать так:
1. Соберите все аргументы (проблемы, вызовы и так далее), чем больше — тем лучше. Это ваши камешки.
2. Кластеризуйте аргументы по смыслу. Это будут ваши валуны.
3. Позже в тексте раскройте каждый аргумент. Иначе ваши валуны останутся полыми и не пробьют стену сомнения.

Давайте для примера.

Вот было:

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

А вот стало:
• Мы медленно поставляем изменения и скорость снижается
• Наша система стала хрупкой: падает каждый третий релиз
• Команда не масштабируется, новые люди въезжают в проект по полгода

Три булыжника такого калибра помогут проломить стену «да вроде все нормально в команде».

Я попробовал Claude/GPT/etc и сделал за вечер то, что раньше целая команда делала неделю

В том или ином виде я эту фразу слышу по всей индустрии. И я ее искренне не люблю по двум причинам:
• Это правда
• Это не вся правда

Где правда: Claude или Codex действительно позволяют одному человеку собрать за вечер то, на что раньше у команды уходили дни. Такую правду любят рассказывать на конференциях или строить на ней крайне амбициозные планы. Полезная правда.

Но есть ма-а-аленький нюанс.

Полностью цитата должна звучать так:

Я за вечер собрал прототип, который целая команда собирала неделю

Потому что в 95% случаев рассказчик имеет в виду «У меня получилось собрать первое рабочее решение». Но если вы когда-то писали код, вы знаете, что между «первым рабочим решением» и «можно катить решение в прод» пропасть, которая доверху заполнена коммитами final_fix, final_final_fix и pls work I want home.

И давайте вспомним наше любимое правило 80 на 20: 20% усилий приносят 80% результата.

Да, в продукте нам часто не нужно 100% фичи. Но если вы катите в прод, вам нужно полностью пройти минимальный порог надежности: тесты, безопасность, интеграции, мониторинг, откат, поддержку. Через пропасть нельзя перепрыгнуть на 80%.

Поэтому мне не нравится начальная цитата. Она скрывает необходимость перепрыгивать пропасть полностью. «Напилить MVP за вечер» != «выполнить работу целой команды».

Задача инженерных лидеров (я говорю про всех лидеров, а не только руководителей) сделать так, чтобы ИИ в компании помогал перепрыгивать пропасть полностью. А для этого ИИ должен прорасти вообще везде: в ревью, в архитектурные решения, в CI/CD, релизы, тушение пожаров и много другое.

Потому что собирать первую итерацию умеет любой ИИ-агент. Но агент не сможет трансформировать свою организацию так, чтобы ИИ (почти) автономно решал задачи за пределами MVP.

Если вы думали, что найм сломан, то у меня для вас новость.

Его скоро доломают окончательно.

Шведский стартап Fika прям щас строит платформу для собеседований. Но так как мы живем в 2026-ом, то без ИИ не обойдется: на платформе соискателя будет собеседовать ИИ. И не просто собеседовать, а на обязательном видео-звонке.

Работать будет так:
1. Вы обнаруживаете в себе тягу в скором времени поменять рабочее место
2. Вы откликаетесь на вакуху в линкедине
2. Fika читает ваш профиль и составляет список вопросов под вас
3. Fika назначает вам звонок
4. На звонке вас опрашивает Gemini-модель.

Но это еще не самое проклятое.

Самое проклятое в финале: Fika нарезает интервью на ШОРТСЫ и отправляет работодателю. Непонятно, на что расчет: типа, зумеры-руководители не смогут посмотреть 10 минут интервью не через шортсы?

Fika подняли 4 миллиона долларов на пре-сид раунде. Венчурные дядьки такие суммы пацанам с улицы не дают. Это не мелочь. По меркам венчура в 2026 — это прям выше среднего. Венчурные дядьки почуяли иксы, поэтому стартап точно продолжит расти в ближайшее время.

Но — поводов расстраиваться нам с вами я не вижу.

Fika может стать (а может и не стать) хорошим инструментом в потоковом найме. Но до ИТ оно вряд ли докатится. Fika это решение для массового найма с похожими требованиями. Для найма кадров с высокой квалификацией, использовать Fika — стрелять себе в ногу.

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

Но системно Fika у нас не приживется.

Сами подумайте: если компания начинает общение с хорошим инженером через заход «Поговори с нашим ИИ, а мы потом посмотрим нарезку шортсов с тобой» — захочет ли инженер тратить время на такую компанию?

Вот и я думаю, что нет.