Время очередного дайджеста!

Контент прошедшего месяца:

– О толерантности к риску
– Читаем Engineering Leadership Report 2025
– О том, что является или не является настоящим ростом
– О решениях с вариантами «50 на 50»
– Об ответственности руководителей
– Правила коммуникаций
– О неприятной работе
– Советы про найм
– О погружении в старую и новую зону ответственности
– Visibility
– Про влияние источника информации на восприятие
– О гранях между микро и не-микроменеджментом
– О корпоративной культуре и прочих ограничениях, которые не сдвинуть
– Интервью про менеджерскую карьеру
– Лайфхак для завершения тяжелого рабочего дня

––

Прийти поговорить: тык

К прошлому дайджесту: тык

О сожалениях

Личная статистика результатов сложных решений за весь карьерный трек:

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

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

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

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

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

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

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

Надеюсь, что-то из этого поможет тебе принять следующее решение :)

Что почитать на выходных

1. Эффективный конфликт

Лучший туториал по управлению конфликтами для душнил.

Если поместить в голову схему огромной распределенной системы тебе легко, а распознать настроение человека по паре слов и взгляду – тяжело – my bet, что конфликты (эмоциональные и не очень) тебя порой сильно удивляют. Подозреваю, что среди айтишных менеджеров таких людей хватает 🙂 По крайней мере, у меня долгое время было так.

Если бы Юра (у него, кстати, еще есть классный переговорный клуб в оффлайне в Москве) выпустил эту книгу лет на 10 раньше, моя жизнь шла бы намного легче.

Однозначный маст-рид по коммуникациям для менеджеров с не-космическим эмоциональным интеллектом. Супер-понятно и практично

2. Думай медленно…решай быстро

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

А если не научит – я не знаю, что тебе поможет 🙂

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

Если у тебя книга тоже уже год лежит в лонглисте и не хватает сигнала, чтобы до неё добраться – это он!

––

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

Делиться недовольством

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

Делая так ты, отчасти, делаешь свою жизнь хуже (и из-за того, что сдерживаться вредно, а ещё твоя мотивация будет неуклонно снижаться с такими событиями), а отчасти..упускаешь возможности. Возможности что-то улучшать в компании и в то же время растить свою репутацию ценного и конструктивного сотрудника.

––

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

Попробуй в следующий раз сделать следующее:

– Принести проблему не в паблик, а лично человеку, который «что-то делает не так» лично или как руководитель имеет полномочия менять то самое «не так» где-то в команде
– Сформулировать сообщение не в формате «у нас тут полная хрень творится и все плохо», а в виде «мне не нравится X. Я думаю, что это плохо потому, что А, Б, С. Мне кажется, что можно было бы улучшить это так и так. Поделись, пожалуйста, своим видением ситуации – может быть, я тут чего-то не понимаю или мы можем поменят ее как-то еще»

Внезапно, когда проблемы доносятся лично (в идеале – при разговоре, а не чатом) и доезжают от твоих ощущений («я думаю X» / «мне не нравится Y» / «мне неприятно, когда происходит Z»), а не от характеристики собеседника («ты принял плохое решение» / «ты неправильно проводишь синки» / …) + содержат конкретные предложения, это ломает большинство барьеров и люди, если и не исправляют ситуацию сразу, как минимум внимательно тебя слушают и готовы подумать о проблеме вместе. Более того, такие разговоры могут, внезапно, улучшать ваши отношения

Вечернее терпапевтическое. О решениях и ощущениях нормальных руководителей

– При выборе между двумя болезненными решениями (уволить одного члена команды и испортить жизнь ему, или сохранить его и испортить жизнь другим 5 людям) колебаться вредно, нужно принимать логически более полезное. Но при этом нормально переживать и чувствовать себя плохо

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

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

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

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

До тех пор, пока внутреннее не остается надолго, не мешает делать внешнее и со временем становится лучше – всё из этого можно считать нормальным. Хорошей пятницы!

Эмоции, How To

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

Короткий ответ: нужно их доставать, стараясь не разнести при этом все вокруг и «работать над ошибками».

Как это делать:

1. В моменте, если сильно прижало:

Дождаться или организовать себе (ты же менеджер и сможешь, правда?) 10-15 минутный перерыв между встречами. В этот перерыв нужно дать себе интенсивной физической нагрузки.

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

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

2. На средней дистанции, если возможно:

Ставлю на то, что в 8 случаев из 10 твои эмоции вызваны словами или действиями других людей. Так вот, если возможно (грубо говоря, если вы коллеги и сидите на одном этаже, а не увиделись один раз в жизни; или если человек – не руководитель +10 уровней от тебя), когда выдохнешь – стоит вернуться и поговорить. Формат – смотри здесь. Донести проблему через ощущения и возможные негативные последствия, не характеризуя при этом собеседника, и предложить вместе обсудить, как избежать таких ситуаций в будущем.

Во многих случаях это нормально сработает. Если нет – ты, по крайней мере, будешь знать, что хорошая попытка была сделана :)

3. На длинной дистанции, если (1) + (2) не помогает, или (2) невозможно, или (2) идет неудачно:

Дневник. Если сильная эмоция или ощущение снова и снова возвращаются, в конце дня нужно сесть и (идеально, если руками на бумаге, но необязательно) как можно детальнее описать свои эмоции и ситуацию, их вызывающую. После этого так же в письменном формате порассуждать:

– Почему именно такая ситуация вызывает именно такие эмоции? Она объективно делает твою жизнь хуже? Она конфликтует с твоими личными морально-этическими убеждениями? Что-то еще? (ответ не обязательно должен быть рациональным, подойдет любой, который ты внутренне примешь)

– Что должно было (и может быть в будущем) по-другому, чтобы ощущения не повторились? Остановить ситуацию быстрее и что-то сказать собеседнику? Ничего не менять, но самостоятельно переоценить происходящее по другому? Перестать работать с конкретным человеком? Поменять что-то другое?

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

4. Если возможно: с кем-то поговорить о том, что получилось в (3)

Лучший друг / партнёр / родственник / психолог – любой человек, которому ты очень доверяешь и можешь поделиться личным. Буквально прийти и «подумать вслух» о том, что ты самостоятельно надумал к текущему моменту. Получив взгляд со стороны, можно, во-первых, зачастую убедиться, что не сходишь с ума и что-то делаешь правильно, а во-вторых – получить больше идей, как дообработать проблемы. В эмоциональных вещах взгляд со стороны очень может помогать

Если такого человека нет – отправляй в любимую LLM :)

––

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

p.p.s: все написанное не является профессиональной терапевтической рекомендацией. Абсолютно субъективный опыт и вещи, которые для меня работают

Приоритизация

Один из самых критичных для работы менеджера навыков.
Чем выше по иерархии – тем важнее. Причем как для работы, так и для личной жизни.

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

Полезное упражнение:

1. Выпиши последние 5-10 вещей, которые ты «не успел» на работе и за ее пределами
2. Замени в каждом предложении «не успел» на «деприоритизировал» / «не смог приоритизировать»
3. Подумай о том, какими проектами/активностями/встречами ты занимался в то же время, когда «не успевал». Это – вещи, которые ты приоритизировал над остальными. Если бы ты мог вернуться на неделю назад – может быть, ты бы разменял какие-то из них на активности из пункта (1)?

Когда в разговорах (хотя бы с самим собой) начинаешь говорить в терминах «приоритизировал»/«не приоритизировал», «выделил время»/«не выделил время» вместо «успел/не успел», появляется больше ответственности и, одновременно, возможностей управлять своим временем.

Приоритизируй осознанно :)

Сделай прямо сейчас

Распространенная менеджерская привычка, когда во время встречи понимаешь, что нужно что-то сделать – записать это в заметки.

– TODO: прислать Вите описание задачи
– TODO: посмотреть сколько мы заплатили за железо в прошлом месяце и пнуть Ваню, если сумма больше Х
– Спросить у Саши, сделал ли он Y (дело Y при этом – на 5 минут)
…

Чем «больше» менеджер, тем агрессивнее становится привычка.

«Маленький», но очень мощный лайфхак для больших менеджеров: маленькие дела лучше делать как можно раньше. В идеале – сразу во время встречи.

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

Попробуй в следующий раз, заметив, что записываешь тудушку на 3 минуты, остановить запись и сразу сделать. Прям попросить минутку на встрече и сделать (собеседники, почти всегда, тебя поймут). Кстати, прием работает и в обратную сторону: если собеседник говорит, что сделает что-то позже, но звучит это просто, попробуй спросить: «А можем прямо сейчас? Это долго?»

Такой подход увеличивает как количество выполненных дел, так и качество жизни :)

Подготовка к переговорам

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

– Какое решение ты хочешь получить на переговорах?

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

––

– Какое обоснование будет у моего решения?

Для каждого предложения, которое ты выносишь на переговоры, нужно уметь ответить на вопрос "почему?". Даже если тебе оно кажется очевидным. Даже если кажется абсолютно очевидным (если бы оно было очевидно не только тебе – переговоры, может быть, и не понадобились бы вовсе).

– У нас в команде нет фронтендеров, а появился важный проект на разработку веб-сайта. Мне нужен бюджет на fe-инженера.
– А почему бы без фронтендера не разработать веб-сайт? Какие-то разработчики же есть

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

––

– В чем интерес второй стороны? И как он может конфликтовать с моим предложением?

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

––

– Что я буду делать, если договоренность не случится?

Очень важно не входить на встречу с настроем "у меня нет варианта не договориться". Если у тебя нет плана Б, ты в конечном итоге, примешь почти любые встречные условия. В том числе сильно ухудшающие твое положение.

План Б может быть в разной степени радикальным, от "если мы не согласимся на опции А, Б или В, я запишу все консерны обоих сторон и вернусь на второй раунд через неделю" до "если мы не согласимся как минимум на Б, я буду договариваться с другими людьми / попробую совсем другой путь".

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

––––

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

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

(Не)очевидные советы про архитектуру:

Пачка случайных советов людям, недавно проектирующим сложные штуки:

Попробуй предварительно нарисовать команду:

Если в твоем продукте три экрана – это не значит, что тебе нужно три микросервиса. Если все три делают два человека – им будет нормально и в одном. А если над продуктом будут работать три команды по 5 человек – лучше резать.

Учитывай этап развития бизнеса:

Сервис, "создающий заказ", для одного rps, для 1000 rps и для 100000 rps – это три разных архитектуры. Проектировать несвоевременно вредно как в большую, так и в меньшую сторону

Выбирая технологию, думай об уровне результата

Если твоя цель – сделать сервис "не хуже", чем другой известный тебе (или другой, который ты делал раньше) – можно брать те же технологии и подходы, что используются в другом сервисе

Если нужно "строго лучше" – это может быть хорошим поводом попробовать что-то поменять

(дисклеймер для ковбоев: если у тебя космические требования надежности – это, скорее всего, означает подход "не хуже")

Расскажи об архитектуре не-техническим руководителям

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

Оформи дизайн-документ

RFC/RFD/C4/в пэйнте, не важно. Артефакт, который, во-первых, могут поревьюить (в том же смысле, что и код, а не на словах!) другие инженеры, и который у вас останется – это почти что лучшая документация для технарей, которым лень писать документацию

Погугли как у конкурентов и спроси у GPT

Нет, не для того, чтобы не думать самому и просто скопипастить. А чтобы быстро увидеть, в каких направлениях вообще можно подумать, проектируя такую систему, и не забыл ли ты очень важный кусок. Зачем ограничиваться ревью дизайн-документов от людей?)

Один нюанс при выборе технологического решения

– Запилим сервис сами или купим облачный?
– Построим платформенное решение на три команды или разрешим каждой делать своё?
– Напишем сервис на node.js или python?
– ...

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

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

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

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

Такой сервис, теоретически, возможно запилить за квартал, есть даже команда, которая такое смогла. Но насколько твоя команда похожа на неё?

Обобщенную библиотеку и правда можно написать. Но в каких отношениях находятся лиды, которые будут ее испольовать?

––

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

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

Сколько это стоит?

Есть ли у тебя несколько человек в команде (или целая команда), которая "вроде как" что-то делает, но результат так себе? За квартал в целом что-то выпустили, но планировали в 4 раза больше. Фичу вроде шипнули, но 10 раз переделывать пришлось

Если бы не сделано было абсолютно ничего – ты бы уже давно ее пересобрал. Но вроде пользы "больше нуля"...

Упражнение для технического руководителя / cto / любого другого инженерного управляющего:

1. Посчитай, сколько вы заплатили за содержание команды за тот же период времени. Зп + налоги + премии + сопутствующие вещи типа железок, страховки, прочего-прочего (если не можешь сходу посчитать сам – спроси у hr's, они такое умеют).

2. Представь, что к тебе приходит внешний клиент и просит под заказ разработать ровно то (и ровно с тем качеством – например, забив на все некритичные баги), что сделала команда. Как именно ты это будешь делать (позовешь пару своих знакомых и отдашь всю работу им, а себе просто оставишь процент от сделки; часть по-быстрому запилишь сам, а остальное отдашь сделать другу; и тд) – ему безразлично. Ты можешь назвать ему любую адекватную сумму денег и пообещать результат. Ты не хочешь слишком уж сильно "нагревать" клиента (допустим, тебе нужны долгосрочные отношения с ним и ты рассчитываешь на новые контракты), но кое-что подзаработать – не стыдно. Какую сумму ты попросишь?

3. Сравни цифры (1) и (2).

С очень высокой вероятностью после этого ты преисполнишься решимости оживить команду)

––

// конечно, мы понимаем, что оптимизировать нужно не только кост и разработка гораздо сложнее. Есть еще качество, уровень компетенции команды, скорость поставки ценности и прочее-прочее. Но если последнее начало хромать – попробуй посмотреть еще и на кост :)

Как (не) думать вместе с GPT:

GPT (мне, кстати, субъективно нравится gemini, а вам?) – очень крутой помощник в обдумывании идей и решений. Одним запросом можно быстро получить набор идей/подходов к проблеме, или узнать подробнее про какой-то из них. Я и многие мои знакомые используют его каждый день, но..есть один паттерн, который кажется мне жутким:

Часть менеджеров явно использует gpt не как "еще один [негарантированной надежности] источник информациио проблеме", а как конечное решение. Я буквально в ряде чатов, в том числе рабочих, вижу, как люди присылают сообщения, написанные gpt. Может быть, немного отрефакторенные (но не всегда!)

Если ты так тоже делаешь:

– Во-первых, gpt – не узко-экспертная нейросеть, обученная решать задачи из твоего домена. Да, у нее реально есть много информации (почти всегда больше, чем у тебя), но она не обучена максимально эффективно ее применять для решения задач твоей предметной области. By design general-purpose llm может хорошо и красиво тебе собрать инфу по нужной теме и попытаться сделать логические выводы, но..ты ведь уже пытался на старте карьеры принимать решения так, без накопленной личной практики, правда?) И, наверное, помнишь, что из этого иногда выходит

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

GPT – классный инструмент, чтобы дособрать информацию, получить больше мнений и о чем-то детальнее узнать. Используй его как источник информации и как самую базовую логическую проверку своих идей. Не как decision maker, который выдает тебе финальный ответ и решение!

Что общего у плохого резюме и плохого описания вакансии?

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

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

– Разработка кода на Java
– Проведение Code Review
– Написание юнит-тестов
– ...you name it

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

На одном и том же стэке технологий можно разработать

– Платежный процессинг
– Городское такси
– Систему управления роботом
– Да в целом примерно что угодно

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

Если у меня на (виртуальном) столе лежат два резюме, и автор одного из них "разрабатывал код на языке X, писал автотесты с использованием библиотеки Z, формировал функциональные требования", а автор второго – "на языке X разработал сервис рассчета цен на доставку еды, благодаря чему GMV сервиса вырос на 5%" – я, скорее всего, не встречусь с первым человеком.

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

И то же самое справедливо для нанимающих менеджеров, которые думают или не думают о том, что конкретно код их людей будет делать 🙂