Lead’s Notes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

––

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

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

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

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

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

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

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

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

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

––

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

––

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

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

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

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

––

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

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

––

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

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

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

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

––––

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эмоции, How To

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

––

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

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

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

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

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

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

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

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

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

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

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

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

––

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

––

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

О сожалениях

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

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

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

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

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

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

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

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

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

Lead’s Notes pinned «Время очередного дайджеста! Контент прошедшего месяца: – О толерантности к риску – Читаем Engineering Leadership Report 2025 – О том, что является или не является настоящим ростом – О решениях с вариантами «50 на 50» – Об ответственности руководителей – Правила…»

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

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

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

––

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

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

Свой бизнес

Периодически у меня спрашивают:

– Стоит ли мне строить карьеру в корпорации, чтобы потом открыть свой стартап?

Или даже:

– Что лучше – работать менеджером в найме ли строить свою компанию?

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

––

Недавно я познакомился с Андреем Резинкиным – ранним инвестором в стартапах Educate Online (США, Индия, ARR $100 млн), EBAC (Бразилия, Мексика, ARR $20 млн), XOR, InTon, автором канала Money For Startup и одноимённого клуба tech-фаундеров

Независимые венчурные инвесторы из России – для меня – что-то уникальное из красной книги, мимо проходить нельзя 🙂

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

В канале полно интересного, например:

– Желтые и красные флаги для инвесторов при питчах
– Много классного про product market fit
– Состав и размер стартапных команд

И, конечно же, многое другое 🙂

Как закончить безумный день

Для тревожных менеджеров:

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

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

Есть лайфхак, позволяющий выбраться из этой ситуации:

––

1. Выписать список задач, которые не отпускают тебя с работы
2. Напротив каждой написать первый шаг, который ты сделаешь, занявшись с задачей
3. Забронировать себе час-два в календаре на следующее утро под выполнение первых шагов

Всё.

На выходе получается что-то типа:

1. Согласовать бюджет на проект X – запросить у Васи детали по подсчету хедкаунта в команде А, у Пети – детали по команде Б
2. Найти способ впихнуть в бэклог проект Y – свести в табличку топ бэклогов команд А и Б, поискать самый низкоприоритетный
3. Уговорить смежников взять в работу проект Z – завести тикет с описанием проекта, эффектом, попросить Петю уточнить формулировки

И слот в календаре со ссылкой на этот туду-лист


––

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

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

Пользуйся и не забывай бывать дома :)

Видео-контент про менеджерскую карьеру

Вышло длиннющее (почти два часа) интервью каналу StepOne про менеджерскую карьеру: https://youtu.be/Ll2JQDpcBLc

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

С некоторыми вещами бороться бесполезно

Наткнулся на классную статью о корпоративных культурах и ограничениях для разработчиков https://newsletter.pragmaticengineer.com/p/how-to-become-a-more-effective-engineer

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

––

Несколько хайлайтов из статьи:

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

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

– Помимо неформальной иерархии, обычно есть еще и неофициальный набор правил принятия решений. И он тоже может быть не-инженерно-обоснованным. Например «по умолчанию мы задачи типа А на стэке Б»; «в сервисах X и Y за баги у нас расстреливают, а в сервисе Z можно и забить»; «большинство фичей мы катим через А/Б, но если её принес воооот этот человек – то надо просто взять и релизнуть»; и тд. Покопавшись, под некоторыми из них ты обнаружишь логику, под некоторыми – ничего не обнаружишь, но..бороться с идеологией почти всегда бесполезно. Unless ты являешься руководителем, которого наняли её поменять. И, как и в случае с неформальной иерархией – эти правила нужно изучить и научиться решать проблемы, учитывая их, иначе ты, опять же, «неожиданно» будешь получать палки в колеса

– Самый ценный в современно IT скилл – умение работать в бардаке. Да, сервисы не документируют не только в твоей команде. И – да, тонна легаси закопана почти в любом успешном и выросшем бизнесе. И..да, неформальная иерархия и процессы очень часто не соответствуют формальным. Это не «тебе с текущим местом не повезло» – это почти везде так. Так что быстро изучать неформальные правила и проблемы, разгребать кучу недокументированного говнокода – это базовые навыки для успешной карьеры

В статье гораздо больше (вместе с полезными ссылками на другие материалы), советую прочесть полный вариант 🙂

Микроменеджмент или не микроменеджмент

Я много раз слышал слово «микроменеджмент», но, на самом деле, не думаю, что существует универсальный чрезмерный уровень контроля.

Бывает подходящий и не-подходящий уровень менеджента для каждой конкретной ситуации.

Мне помогает примерно следующий простой фреймворк:

––

Рассматриваю конкретного человека и задачу. Оцениваю два критерия:

1. Насколько человек компетентен для выполнения задачи?

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

2. Насколько человек мотивирован ее выполнять?

Он смотрит на задачу с горящими глазами, сразу начинает генерировать идеи решения, или говорит «да не, фигня какая-то, ну так уж и быть, попробую»?

––

Если и первое и второе у человека есть – его не надо трогать. Можно просто раз в несколько дней/неделю/две (зависит от масштаба исполнителя и задачи) глянуть на прогресс, убедиться, что тебе понятно происходящее и пойти дальше. БОльший контроль может повредить

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

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

––

Дисклеймер 1: разумеется, по возможности стоит искать исполнителя с большой мотивацией сделать задачу. И на самом старте её «продавать». Но реальность такова, что такой будет у тебя не всегда, надо работать с тем, что есть

Дисклеймер 2: предложенное не относится к работе со стажерами и джунами. Там, понятно, люди еще не умеют даже проблемы эскалировать и статусы вовремя репортить самостоятельно и контроля нужно много. Для всех позиций выше это уже должно быть бейзлайном, поэтому критерий «человек базово осознанный и ответственный» не рассматриваем