Lead’s Notes

Ещё одна причина, по которой ты зарабатываешь меньше, пока кому-то "хуже" больше "везёт"

Приоткрываю завесу страшной тайны на высоких уровнях.
Она звучит так: многие возможности имеют окна. Иногда — в неделю, день или даже час. Это узнаёшь, когда активно занимаешься чем-то, близким к денежным потокам и центрам принятия решений.

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

"Прямо сейчас хороший момент предложить тебе работу — внутри много сомнений нанимать/не нанимать человека извне, но вчера был факап а сегодня отвалился внутренний кандидат, я могу тебя протолкнуть"

Даже банальнее "мы прямо сейчас обсуждаем стратегию большой интеграции. Если мы собьем её на этой неделе, есть хорошие шансы защитить, выделить ресурс и поехать".

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

Знаете, что из этого следует? Есть ваша, как партнёра/исполнителя/подрядчика особенность, напрямую, на равных (не преувеличиваю) с хардами, а иногда и больше чем харды, влияющая на то, получаете вы "возможности" или нет. И это — скорость вашей реакции.

Кому я пишу первым: CTO, который обычно отвечает по 8 дней, или C-1, у которого скиллов поменьше, но "мне, в принципе, хватит", всегда возвращающемуся тем же вечером? Очевидно, сначала второму, а потом первому — пока CTO сообразит, мы с его подчинённым уже новый value stream запустим. А там я ещё раз подумаю, нужен ли мне менеджер потолще.

Как я делаю выводы "кто может вовлекаться в возможности" и "кто не может"? Банально по среднему времени ответа. Мне неважно, что это за ответ. Ответ "нет, не смогу" или даже "не понял, можешь пояснить X, Y" через четыре часа лучше с точки зрения этой метрики, чем ответ "да, давай попробуем" через 12 дней. Если я человеку пару раз что-то предложил или спросил и он не ответил вообще или ответил через 3 недели — я больше предлагать не буду, даже если по хардам он хороший фит. Какая разница, сколько у тебя навыков и ресурсов, если они недоступны? Но если я предложил и он ответил "не могу" — это другое дело, и я буду предлагать другое, когда случится.

Управляйте временем эффективно, разбирайте регулярно инбокс, и уже на горизонте полугода что-то для вас изменится и "везти" начнёт чуть чаще. Хорошего понедельника!

Суббота – отличное время сказать «нет»

Если у тебя висит ряд вопросов/предложений по проектам или сотрудничеству/запросов на помощь, которые ты сначала просыпал, а потом «уже просто неудобно», в выходной можно по ним пройтись и каждому вежливо отказать. «Сорри, не было/нет ресурса/возможности помочь. Если что, мы при этом умеем X, Y, пишите, если будет нужно»

Срока давности нет, это во многих случаях срабатывает и сохраняет отношения.

Я как-то раз понял, что зря потерял контакт, ЧЕРЕЗ ДВА ГОДА так ответил и мы тут же начали обсуждать другой проект.

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

Не надо принимать больше решений, надо принимать другие

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

Потому что плохое "решение", во-первых, часто дороже, чем криво написанный код (оно влияет на кучу людей, которые пишут потом кучу плохого кода), а во-вторых, качественно принять его ты можешь только в своей голове. Все то, что автоматизируется, на самом деле, с точки зрения затрат энергии для тебя и так не очень дорого. И как человек, осознанно и глубоко, ты в единицу времени обдумывать больше никак не начнешь. За счет нейронок, скриптов и прочего быстрее собирать информацию в кучу — да. Делать правильные выводы — нет. Можешь быстро начать делать неправильные или некачественные, но этого ли ты хочешь? (у меня, кстати, иногда бывают экстренные ситуации, и я выдаю людям ответ вида: здесь я считаю так, здесь я считаю так, а здесь — у меня нет времени подумать и я никак не считаю, вот что думает опус, мне поверхностно кажется, что это похоже на правду, но перепроверьте 10 раз и ни в коем случае не пересылайте дальше без этого. Кстати, верните мне обратно поревьюить что сами об этой части головой подумаете).

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

Менеджер редко масштабируется сам по себе, он масштабируется с командой, причем часто — без её роста. Подумай, может быть, вместо того, чтобы выдавать ещё больше слопа, ты лучше попросишь часть вещей решать кого-то другого, а остальное начнешь делать лучше или больше?

———

p.s.: во вторник в 19:00 UTC+3 будет закрытый стрим про эту и другие проблемы и ошибки менеджеров, которые уже управляют другими менеджерами. Дам 4 инвайта опытным менеджерам не-из-сообщества, которые успеют мне куда угодно прислать свои имейлы.

Держу в курсе: Practice Day по теме прикладного AI — будет!

Есть кое-какой спрос и даже в количестве спикеры из сообщества, причем очень разные — от руководителя мобильной разработки, до основателя небольшой студии (и при этом не-инженера).

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

Stay tuned :)

К слову о басфакторах и рисках

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

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

Сила в приоритизации, а не в самостоятельности

Есть множество мемов про бигтехи. Свои движки для C++, свои парсеры и прочее-прочее. Короче, "всё сделаем сами".
Они, во-первых, не полностью соответствуют правде, во-вторых, порождают очень опасное заблуждение в головах "идейных" предпринимателей и технических директоров компаний второго-третьего-пятого тиров.

На самом деле, бигтехи не пытаются все и идеально сделать inhouse. Они прекрасно покупают всякие amocrm, ispring, привлекают аутсорсеров и не колеблются там, где задача — либо "не кор бизнес", либо "не наша кор-компетенция". Например, не умеют железо делать — покупают, для начала, китайское. Кое-где у них кор-бизнес там, где люди не ожидают. Если ты самый большой в стране поисковик — тебе реально может быть нужен свой фреймворк, который под твой сценарий лучше всего, что есть в опенсорсе. А если тебе при этом нужна crm-ка простая или даже "маленький экспериментальный сервис" — ты можешь и прикупить, а там решить как будет. Вы вот знали, что один из самых больших на сегодня технологичных сервисов доставки еды в РФ, был сделан внешней студией с участием аутсорсеров, потом куплен бигтехом как есть, а уже только потом переписан на что-то модное? А таких примеров много.

Майндсет "большой и крутой tech всё делает сам — и мы тоже будем", который порой заимствуют CEO и CTO, не полностью понимая игру и желая повторить успех, часто — ошибка. Вот строишь ты, например, завод по производству втулок. Или коров выращиваешь (вы не думайте, что это стёб, это огромные бизнесы и серьёзное дело, и там есть IT). У тебя IT-бренда никогда не было, есть "какая-то" IT команда. Ты нанял одного идейного CTO, можешь, при желании, нанять ещё пару технарей хороших. И узнал, что, вообще-то, можно себе хитрый ML прикрутить и эффективность производства поднять.

Решение вида "я сам соберу in-house топ ml команду на рынке" — не смелость, это чрезмерная самонадеянность. Собирать хорошую и сильную команду при том, что бренда у тебя нет, а в штате никто не умеет, ты будешь долго, не меньше года. "Просто поднять ставки выше рынка" не поможет — высосешь безработных ноунеймов, уволенных из хороших компаний. Качественный найм "с нуля" — это сложно, надо и штучно искать людей, и строить для них мотивацию, и убеждать их поверить, и тд и тп. И к тому же, если идея для тебя экспериментальная — а вдруг не полетит?

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

Если чего-то не умеешь и пока непонятно, насколько хорошо оно тебе подойдет — не торопись тратить миллиард на in-house. Top Tech устроен не всегда так, как тебе кажется, и тебе так не нужно.

Один из топ-предикторов времени жизни члена команды:

Количество качественных личных взаимодействий с руководителем с другими членами команды в неделю/месяц.
Об этом, кстати, неплохо пишут в книгах с исследованием культов и сект, легальных и не очень (почти что угодно с большой фанбазой — попадает в это определение; любая команда, где сотрудники живут больше года или двух — попадает в это определение).

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

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

Если что, на удалёнке с этим можно бороться, я, когда ковид был, даже пиво по зуму пил, что было странновато, но работало. И у себя дома мог команду собрать, если в офисе было нельзя. Работать над engagement и регулярными горизонтальными взаимодействиями обязательно, всегда и везде, если вы имеете любого вида профит от продолжительности жизни члена в сообществе. Такие дела. Поэтому, кстати, 1-1ы отменять нельзя и руководитель, который их не проводит, потому что "важной адженды не нашел", реально не делает часть своей обязательной работы.

————

p.s.: напоминаю, что на завтрашний вечер есть ещё несколько открытых слотов на стрим не-для-членов-сообщества об ошибках и подходах к управлению IC для линейных руководителей и не только. Можете написать мне куда угодно и записаться, пока успеваете :)

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

Hi Andrew,
I'd be glad to connect here and discuss the opportunity for a business dinner.
Unfortunately, LinkedIn limits the number of characters, so I can’t fully explain what I’d like to share. I’d appreciate the chance to connect and continue the conversation in more detail.

Парню везёт. Написано ДО ТАКОЙ СТЕПЕНИ глупо, что мне становится жаль, я просто из интереса отвечаю: "Привет, что у тебя?"
Знаете, какое следующее сообщение?

. Would you be open to a short intro here and sharing your thoughts on it?

Fucking hell, я же ответил на твоё первое сообщение (хотя оно провальное), ну почему у тебя описание продукта не в следующем? (за многоточием — не оно, там просто нет полезного контекста)

Я прошу что-нибудь показать.
После чего человек спрашивает, когда я могу встретиться, и я, разумеется, встретиться с ним не cмогу никогда. Зачем?

Увольте своего sales или bizdev, если он похож на это.

Официальный гайд о полезных спорах на работе и за её пределами:

0. Не делать этого, если можете этого не делать.

1. Если вы всё же это делаете не ради развлечения:

a. Выберите конкретный тезис или несколько, с которыми не согласны.

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

"Все сейлзы — скользкие людишки" — тезис без физического смысла и непроверяемый. Спорить с ним бессмысленно, даже если он вам не нравится. Можно, конечно (и иногда стоит), поговорить о другом — "нормально ли высказывать такие тезисы в офисе", но это уже не совсем спор на эту тему :)

"Сейлзы не умеют писать код на C++" — тезис со смыслом и проверяемый. С ним можно спорить (если это вам зачем-то нужно и почему-то выгоднее, чем просто покинуть комнату и заняться делами поважнее). Кстати, он сильно отличается от "Большинство сейлзов, которых я знаю, не умеют писать код на C++" и даже от "ни один сейлз, которого я встречал, не умеет писать код на C++"

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

"Нет" — это шляпа, а не контртезис, смысла в этом слове нет.

"Нет, не все сейлзы не умеют писать код на C++. Я знаю сейлза по имени Володя и он умеет" — это контртезис

Если их много, постройте лесенку от того, в котором вы уверены больше, к тем, где сильнее сомневаетесь

c. Предложите какой-то важный вывод, следующий из того, что ваши контртезисы не совпадают с тезисами

Если вам предлагают построить большую систему на 7 основаниях, из которых 5 неверны, но из замены всё равно следует, что надо строить точно такую же систему — обсуждение можно пропустить и сэкономить время.

А вот если из пяти конкретных пунктов, с которыми вы не согласны, СЛЕДУЕТ, что строить её не нужно "и если вы согласны со мной здесь, то бюджет проекта не сойдется" — поспорить уже стоит

Если выбрать (a), (b) или (c) не выходит — может, лучше не участвовать в обсуждении?

Одна из самых частых ошибок менеджеров — забыть рассказать человеку, что он должен делать

Помните такое словосочетание странное "должностные инструкции"?
Их никто не пишет и не читает, и не надо.
Но банально проговорить хотя бы раз в квартал: "я ожидаю, что ты займешься этим и этим, и буду считать тебя молодцом, если случится такое" — база. База, которую люди постоянно пропускают.

Вы НЕ ПРЕДСТАВЛЯЕТЕ, какую шляпу люди могут думать о своей работе.
Как вам, например, тот факт, что бывают разработчики, искренне удивляющиеся фидбеку: "Серёжа, если ты сказал, что сделаешь до пятницы, а до пятницы не сделал — это ПЛОХАЯ работа"?
А тот, что бывают CTO, удивляющиеся фидбеку: "Саша, нам насрать на твои личные инженерные навыки, ты должен организовать разработку так, чтобы мы зарабатывали больше"?
И ещё 10 таких же.

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

———————

Кстати, во вторник вечерком в сообществе устраиваю закрытый стрим про ошибки управления для руководителей любых уровней, даже линейных. Раздам щедро штук 5-7upd: 3 инвайта на этот вечер, по традиции, для тех, кто успеет и сможет мне написать :) Чтоб не только для C контент делать, а то некоторые расстроились закрытому стриму в пятницу

Им нужно, ты зря не спрашиваешь

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

Если тебе кажется, что есть что-то прикольное и "жаль, что твоей команде это не нужно", проверь: а ты им вообще это предлагал?

———

"У меня никому не интересно делать модную микросервисную архитектуру, новые фреймворки пробовать и тд, сидим в болоте"

А ты им предлагал это как вариант вообще, показывал, спрашивал, что они думают?

Мой личный опыт: в каждом втором случае, когда руководитель говорит, что все плохо, в команде болото и опасается сопротивления, если я прихожу к его же подчинённым и говорю: "вам как сейчас вообще? Вот тут вы согласны, что есть проблема? А здесь? А еще какие видите?" проблемы они прекрасно видят. Если я после этого могу ещё и набросить более-менее красочно идей о том, как могло бы быть ("а прикинь, бывают еще вот такие релизы, ты бы так хотел у себя?", "а вот на реакте тебе интересно было бы попробовать это сделать?", "а если тут temporal?"), люди хотят это сделать. В то же самое время руководитель абсолютно уверен, что идею не продаст.

———

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

В немалой доле случаев руководители этих людей не думают, что им оно нужно (хотя могли бы спросить). Да ладно руководители — их друзья об этом не подозревают. У меня в менеджерском сообществе есть несколько человек, в том числе блоггеров, которые, когда я спрашиваю фидбек, и рекомендовали ли бы они это друзьям, говорят: "у тебя тут крутые вещи, но у меня аудитория чистых инженеров, и друзья мои такие же, им ничего такого не нужно". Знаете, какая часть аудитории "IC, которым, на первый взгляд такое не очень нужно", в этом канале? Больше 30%. Более того, из них процентов 5-10 пришло "по рекомендации друга-инженера" (в то время, как этот друг считает, что рекомендации такой не давал и его друзьям, в отличие от него, это неинтересно, а просто между делом слово обронил).

———

Короче: если ты делаешь что-то классное и думаешь, что твои коллеги/друзья/etc зря этого не делают, а также сами этого не хотят — с высокой вероятностью им просто никто не предлагал. Не бойся сопротивления, пока оно реально не возникло, в половине случаев его нет.

Получил сегодня на встрече-знакомстве по консалтингу один из лучших возможных фидбеков:

В некоторых блогах очень умные люди пишут что-то очень умное.
А ты в своём пишешь то, что, по-моему, похоже на правду, и есть сильное предположение, что ты это делал.

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

————

Кстати, ещё одно место для cXo осталось вот сюда для тех, кто найдёт дорогу :)

Люди вот говорят, что я "Lag Measure" слишком пессимистично называю

А я встретил ещё лучшее название для некоторых метрик: Vanity Metrics (с переводом справитесь, это как Vanity Fair). Не сам придумал, к сожалению.

Это метрики типа общего количества ваших пользователей/регистраций/подписок: они вроде как "целевые", но решения на них вы в работе принимать не можете и следует из них, по большому счёту, одно из двух: "вы были в этом полугодии охуенным молодцом" или "вы были чуть меньшим молодцом". Аптайм, кстати, в целом — примерно такая же метрика.

Поэтому, если вы на дейли/викли говорите о какой-то метрике типа той, что я привожу выше— это плоховато. По крайней мере, если разговор не совмещён с какими-то daily показателями, на которые вы реально своей работой завтра можете повлиять и которые, в идеале, декомпозируются быстро в какую-то информацию "а что конкретно тут не так"

Если человек считает/анализирует метрики, финансы и другие сложные численные показатели через ии, при этом не знает что такое grounding и НЕ пишет скучные детерминированные tools, а также сам не имеет чего-то похожего на техническое образование

Бегите от него, это пиздец.

Я думал привести примеры в этом посте, потом вспомнил, что за такие цифры вешают, и просто предлагаю поверить мне на слово.

Как вы понимаете, пишу это, пересчитывая цифры в пятый раз за сегодня.

Закрытый стрим для C-level: очевидные и не очень ошибки c-level, на примерах тех, что совершают CTO.

Я за последнее время кое-что писал (раз, два) об очевидном и не очень мышлении C-level.
Коротенечко затронули тему на панельке у Стратоплана, но контента у меня осталось значимо больше, чем вышло.

Уже несколько недель я не предлагал не-членам сообщества поучаствовать в стриме, впервые сделаю частично-доступным контент уровня Senior Managers & Directors для тех, кто успеет:

В пятницу, 19:00 UTC+3 мы на примере того, что делают (или не делают) зря CTO поговорим в community об ошибках топов, не слишком характерных или очевидных для людей уровнями ниже. Возьму троих человек UPD: ещё одного человека не из сообщества, только с опытом релевантного уровня (вы буквально были cXo или, как минимум, C-1, управляли не IC-шниками и отвечали за значительный бюджет). Выдам инвайт в порядке fifo трем людям, которые найдут любой способ со мной связаться через канал, заявки и что угодно ещё. Запись будет только на соответствующем уровне сообщества. See you!

Всё ещё дефицитные знания, которые, на самом деле, нетрудно получить

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

— Продуктовые метрики, и всё то, что про "data driven"

Покажи бэклог, как в нем приоритизированы задачи? А почему? А это на что влияет? А почему?
А вот это вы выкатили, да? А как поняли, что работает? А как поняли, что работает хорошо?

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

— Всё, что связано с infra & devops

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

— Качество и безопасность Agentic систем в проде на пользователях. Grounding, evals, governance и тд.

Многие уже придумали писать, что они строили и строят невероятный AI, но простой вопрос "как тестировал, как в оффлайне и онлайне следишь за деградацией" ломает 7 из 10 моих интервью.
Нет, недостаточно их руками тестировать. Нет не просто "палец вверх" (хотя его прицепить в целом тоже можно).
То, что люди делают, в среднем, выпускать в продакшен ни в коем случае нельзя. И разница между "слепил агента для себя и двух тиммейтов" и "выпустил, хотя бы, на сотню пользователей, которые реально ВЕРЯТ и сами НЕ МОГУТ перепроверить" — огромная.

— Переговоры и конфликты

С этим бывает плохо вообще на всех уровнях. Люди всё ещё не знают, что тему можно поизучать не только на рынке возле дома.

— Методы целеполагания для людей и команд; методы отслеживания прогресса и эффективности

Ну вы и сами знаете, как вам цели ставят :)

—————

Примерно по любой теме вы с помощью гугла или своей любимой нейросети найдёте МНОГО и ЛЕГКО. Дальше нужно самостоятельно почитать и попробовать применить. Станете на голову выше среднего кандидата почти на любую позицию.

Следующим за продажами будет вебинар "как быть джуном проджект-менеджером"

Я с каждым годом большие и большие деньги готов платить за навык "мы договорились, что ты поставишь встречу, на которой произойдет X — ты, б..ть, поставил эту встречу и всех пропинал, чтобы они пришли". Или "мы договорились, что ты заведешь вот такой-то регулярный процесс и сделаешь его видимым — ты завёл его или сказал, что не понимаешь как".

// нет, я НЕ думаю, что работа проджекта состоит только в этом, это просто кусочек, который нужно уметь сделать

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

А у вас как?

Managed by C-Level

Приведу вам анонимизированный реальный пример работы с эффективностью.
И на нём сразу различие реакций и решений, которые легко понимают и принимают C-1 и C+.
Это будет жестковато, "несправедливо", и, возможно, часть из вас даже бывала внутри таких ситуаций.

===

Кейс:

Технически-сложный продукт для очень квалифицированных, high networth b2b и b2c пользователей.
Метрик мало, в основном финансовые по всему бизнесу в целом. Команды на земле как-то трекают сами свою производительность, но наверх это никогда не приносят.
На интуиции при этом — "команда tech неэффективна" (она самая дорогая), тратим много, намного больше зарабатывать не начинаем. Финансы давят, надо оптимизировать бюджет.

Идём исследовать, "а где у нас хорошо или плохо работают, какие точки оптимизации есть".

===

Начинаем исследовать:

Быстро на коленке + интервью + простейших метриках оцифровываем, где перформят/не перформят.

На метриках перформанса (пока только в плане поставки кода, фичей и тд) отчетливо видно, например, две полярные команды:

1. Тяжелая алгоритмическая кор-команда. ОЧЕНЬ нестабильная производительность, оч разного качества люди, перформанс сомнительный (то выпускают, то не выпускают; половина тикетов мима дедлайнов; карты коммитов у части людей странные)
2. Команда ребят повеселее, разрабатывающая пользовательские интерфейсы. Там классические бэки-фронты, что-то знают про скрам, двигаются, перформят "на метриках эффективности" сильно лучше команды 1

===

Что на этом этапе интуитивно хочет начать делать Head of Engineering?

Заняться оптимизацией первой команды, похвалить вторую. Либо обе защитить — первая же ресёрчерская, там непонятно что делать, вот они и нестабильные.

// CTO при этом нет. Так бывает, и он как раз должен был бы сделать следующий переход.

===

Что делает CEO?

Правильно: "давайте, всё-таки, дождёмся ROI каждой команды".

"Дождаться" не так просто — ты эффект на бизнес, как код из репозитория, коммитами не соберешь. Оценки где-то есть, а где-то нет. Эксперименты где-то есть, а где-то нет. ОС пользователей где-то есть, а где-то нет. Считаем что можем. Смотрим что менялось по факту после релизов. Если где-то были эксперименты и метрики, берём их. Анализируем старые и даже где-то проводим интервью с пользователями:

Видим вот что:

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

Часть из них вообще не в курсе, что интерфейс за последний год менялся, а те, кто знает, считают это просто "nice" штукой. Ну и по метрикам, откровенно, если не считать косяки, откровенно ломающие конверсию, не видно, чтобы интерфейсные изменения приводили к скачкам. Они просто платят вообще не за интерфейс. И приходят не кликнув случайно.

===

Что это значит:

Самая неэффективная с точки зрения бизнеса команда — это команда очень приятных людей, которые хорошо перформят в коде и тасках. А самая эффективная — "непонятный кор", он приносит практически все деньги.

===

Что происходит дальше:

Жесткий cost cut на команде интерфейсов. Почему: эффектов нет и не предвидится. Пересаживать их в кор нельзя — слишком разный скиллсет. В других частях компании запроса нет.

ОЧЕНЬ осторожная оптимизация производительности и процессов в core (о том, как можно оптимизировать работу очень интеллектуальных людей, в которой регулярно бывает ресёрч, поговорим как-нибудь в другой раз).

Компания живёт, финансы не треснули, я, из интереса, даже перепроверил, что живы, когда писал этот пост :)

===

Обязательно ли для этого был нужен именно CEO:

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

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

————

Как вам такой контент, сколько у нас релевантной аудитории?)