Я тут узнал, что эта история всё ещё актуальна для сегмента людей, в том числе из очень больших компаний в некоторых географиях! О том, как я сто лет назад в лайве повайбкодил впервые

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, все это провернуть. Но таких людей на всех никогда не хватает.

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

————

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

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

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

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

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

А у вас как?

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

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

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

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

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

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

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

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

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

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

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

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

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

—————

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

————

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

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

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

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

———

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

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

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

———

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

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

———

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

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

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

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

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

———————

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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