Сколько стоит твой HR-бренд?

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

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

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

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

Например, «мой бренд в два раза дороже бренда сбера» )))

Бренд OpenAI, например, стоит для ai-специалистов на сотни миллионов долларов дороже бренда Meta.

А сколько стоит твой?

Подкаст о неочевидных проблемах на карьерном пути менеджера

У карьерно-ориентированных менеджеров встречается два вопроса:


1. Как вырастить свою зону ответственности?

Первый и очевидный вопрос, который задают примерно все амбициозные менеджеры в поисках роста.

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

Есть разные рабочие способы это сделать, от «очень много херачить», до «растить личную и командную эффективность и системность своей работы». Я стараюсь учить второму, но чем моложе менеджеры, тем более они склонны к первому 🙂


2. Как сохранить рассудок, компетенции и личную жизнь, если рост все же случился?

Вопрос, к которому, к сожалению, обычно приходят люди после того, как вырастают, а не до этого. Причем нередко – когда добираются уже до очень высоких позиций и проблемы становятся БОЛЬШИМИ.

Про особенности менеджерского карьерного трека, сложности, встречающиеся на нем и способы выживания мы будем говорить в прямом эфире с Сашей Поломодовым (CTO T-Банк, автором @book_cube) в подкасте Code of Leadership.

В ближайшую среду в 19:00 МСК. Подключиться можно будет по ссылке ниже:

ссылка

Приходите и задавайте свои вопросы)


// а поговорить лично про вопросы первого, второго типа или любые другие – можно здесь

AI и менеджеры

К своему большому удивлению, в соцсетях и коридорах встретил более одной дискуссии на тему «заменит ли AI менеджеров?»
Вопрос сначала показался мне смешным, но длина тредов намекает, что я не прав. Посмотрим, выйдет ли такой же длинный тред здесь :)

––

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

1. Принимающие решения и создающие ценность
2. Администраторы

Менеджер-администратор – это тот самый человек из мема: «парни, какой статус?»/«я переложил график в логарифмическую шкалу»/«я нарисовал красивый тренд со сторипоинтами, потраченными за последние полгода»

Полезны ли занятия администратора? Конечно, да – не построив план, ты в план не попадёшь. А не спросив о статусе вовремя, узнаешь о проблеме слишком поздно. И каждый менеджер, принимающий решения, неминуемо становится ещё и администратором на этапе его реализации. Я один раз даже слышал реплику: «когда компания была небольшой, я просто работал. Когда команда выросла, я начал 40% личного капасити тратить просто на то, чтобы шестеренки вращались, а не на интеллектуальную работу». То есть, на самом деле, менеджер, принимающий решения, часть времени работает и администратором тоже. И я не вижу, как в ближайшие единицы лет такого менеджера можно будет чем-нибудь заменить (его-то и как человека найти тяжело, не то, что сеть обучить на данных:))

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

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

А что думаете вы?

Напоминаем, что стрим – уже сегодня в 19:00!

Проходить будет здесь: https://www.youtube.com/live/fi6hua5yGRk?si=2dGTX3XgH22nFgV5

Для тех, кто:

– Сомневается, стоит ли становиться руководителем вообще

– Уже, не дай бог, стал руководителем и хочет лучше понять, как жить и расти на этом треке

– Хочет заработать свой первый миллион быстрее, чем свою первую паническую атаку

– В последний раз был в отпуске 5 лет назад

– Просто хочет о чем-то поговорить или послушать

Всех ждем вечером :)
Запись – будет!

Самое интересное за месяц в канале:

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

– Самый важный софт-скилл
– Как поднять эффективность команды?
– О проблемах с самооценкой
– О командах специального назначения
– Слайды о сложностях перехода руководителей с первого на второй уровень
– Стрим с Борисом («Борис опять») о хорошем и плохом менеджменте
– Аналитика трендов AI 2025
– Что НЕ нужно эффективному руководителю?
– Календарь менеджера
– Сколько стоит твой HR-бренд?
– Заменит ли AI менеджеров?
– Стрим с Сашей Поломодовым о менеджерской жизни

За последний месяц нас стало на тысячу больше – посмотрим, будет ли контент так же полезен и дальше. Приводите друзей 🙂

––

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

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

О толерантности к риску

Одна из неудобных мыслей про карьерный рост:

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

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

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

Перспективы: справишься – вырастешь. Нюанс: справляться будет тяжело и успех не гарантирован. В случае провала ты будешь искать новую работу.

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

– Будь я сейчас на твоем месте – я бы уже поменял работу

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

– Это твоя первая работа и ты хочешь как можно быстрее собрать набор best practice от успешных игроков
– Ты уже находишься на высокой позиции (не M1) и не против следующие ~три года провести примерно в ней же
– Ты не фокусируешься на максимизации карьеры и денег, тебе важна личная стабильность, время на семью/спорт/другие штуки. Каждый день и в предсказуемом количестве

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

Продолжаем интересное чтение.

Engineering Leadership Report 2025 – опрос-исследование менеджеров и прочих людей из engineering leadership на западе. Совсем небольшой документ (по традиции, положу его прямо сюда), с забавными результатами:

– Сокращений разработчиков в 2025-м году – меньше, чем было в 2024-м. А вот сокращений менеджеров – больше. Причем чем ниже в иерархии, тем больше сокращений было. А говорят, cto/vp – в самой рискованной позиции на рынке труда :)) Думаю, что связано с выжиманием эффективности и трендом на более плоские структуры

– Возможно, связанное с предыдущим: у 65% опрошенных менеджеров вырос объем/сложность зоны ответственности. У 40% – выросло количество прямых подчинённых. И примерно те же 40% стали заметно больше работать (про рост зп умалчивается). Эмоционально-выжатыми на работе хотя бы раз в неделю себя чувствуют 47% опрошенных менеджеров. Интересно было бы узнать, как себя чувствуют разработчики этих менеджеров

– бОльшая часть leading engineering staff с интересом смотрит на ai-тулзы для повышения эффективности разработки, однако..60% эту эффективность пока не ощутили на себе и своих командах 🙂 Самое интересное для них – конечно же, AI coding tools (кстати, интересно, что AI в тестировании пробовали в два раза меньше, чем AI в разработке. Я, например, в него верю). Самый большой консерн относительно AI технологий – качество продукта, получающихся у его использующих разработчиков, а не сокращение рынка труда и изменение профессии. Вообще говоря, экономический спад пока что вызывает у людей больше опасений относительно айтишного рынка, чем развитие AI

А что кажется наиболее интересным вам?

О росте

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

– Увеличение количества стэков, на которых ты можешь писать код – это не рост

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

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

– Незначительное увеличение оклада за точно такую же работу – это тоже не рост

Если ты был лидом команды из 5 человек и получал за это 400 тысяч рублей в месяц, а потом сменил команду на точно такую же за 500 тысяч в месяц – ты не стал качественно лучше. Более того, ты и финансово приобрел довольно мало. Для руководителя один миллион в год – это микрооптимизация.

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

– Иногда даже увеличение количества людей в команде – это не рост

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

«В прошлом году в моей команде было 20 человек. А сейчас в ней – 100».

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

Сравни это с:

«В прошлом году я отвечал за один продукт, генерирующий 5% GMV компании, а сейчас моя команда выросла, мы запустили три новых направления и генерируем уже 50% GMV»

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


––

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

Достаточно ли просто учиться качественно более сложному, чтобы расти? Конечно, нет, себя нужно еще и продавать. Но чтобы что-то продавать, нужно, чтобы тебе было, что продавать. А о продажах будет в другом посте 🙂

Горизонтальные связи и нетворкинг

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

Например, ты не внедряешь bdui, а три твоих знакомых cto – внедряют. Или наоборот: ты веришь в llm в рекомендациях, а трое твоих знакомых cto – не верят. Вероятно, надо пересмотреть свою картину мира и поискать ошибку.

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

––

К слову о совместных проектах в медийке и моих вылазках из берлоги: недавно познакомился и рекомендую канал Андрея – руководителя с большим опытом, работавшего в X5, IPONWEB и Rambler.

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

– Смысл 1х1 встреч и эксперимент по их удалению
– Поведенческие интервью как способ оценки компании кандидатом
– Гайд как знакомиться на конференциях

Если этот пост наберет какое-то приличное количество лайков – запишем с Андреем подкаст про софт-скиллы для руководителей!

Подбросим монетку..Или можно и не подбрасывать?

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

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

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

––

И выглядит он так:

Выпиши в явном виде вариант решения «ничего не делать. Просто оставить всё как есть еще на полгода». И сравни положительные стороны и потери от него с существующими решениями.

Внезапно, такое упражнение приводит к одному из двух исходов:

1. Значимых потерь от «оставить как есть» нет. В целом и так будет все нормально и не факт, что хуже, чем при любом из изменений

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

2. Значимые потери от «как есть» – есть! Либо мы упускаем выгоду, либо то, что есть, постепенно становится хуже

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

––

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

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

Об ответственности

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

Написал совсем небольшой постик, который, я надеюсь, хотя бы некоторых из них вернёт к жизни и хорошей работе: https://habr.com/ru/articles/925846/

Коммуникации для больших и маленьких менеджеров

Короткая инструкция о том, как общаться на работе.
Для менеджеров и не только. Когда я думаю о том, сколько денег и времени она бы мне сэкономила, я..стараюсь перестать об этом думать.

––

Как попросить или спросить

1. Поздороваться
2. Максимально ёмко и понятно основной запрос
3. В двух словах – зачем тебе это нужно
4. Если есть жесткий дедлайн – в явном виде прописать его и два слова про то, откуда он взялся

Строго одним сообщением. Пропустить можно только пункт «поздороваться», если ты не в настроении быть вежливым)

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

– делай так!

«Привет!»

– не делай так!

«<10 непрочитанных сообщений>»

– и так тоже не стоит!

«Привет! Тут такое дело: <трактат в трех томах о таком деле>. Так вот, мне, кажется, нужно, чтобы ты..>

– и так не делай :)


––

Как ответить на вопрос или запрос

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

Только в таком порядке.

– Когда выкатите фичу?

«Послезавтра. Разработку закончили сегодня, нужен день на тестирование и день на релиз»

– делай так!

«Послезавтра. Разработку закончили сегодня, нужен день на тестирование и день на релиз. А почему ты спрашиваешь – что-то случилось и нужно asap?»

– так тоже можно.

«Мы сегодня заканчиваем разработку. Потом еще день на тестирование. Потом день на релиз…<еще какое-то количество слов>. Послезавтра»

– так не надо!

«А почему ты спрашиваешь?»

– и так тоже не стоит :)

––

Делай так – и твои коллеги и менеджеры будут счастливы. Поделись с командой :)

О неприятной работе

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

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

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

––

Как разрешить себе отдавать неприятную работу?

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

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

3. Ты тоже можешь быть басфактором. Басфактор-руководитель – ничем не лучше (а иногда и хуже) басфактора-разработчика. Что будет, когда ты пойдешь в отпуск, заболеешь или уволишься? Начинать делегировать такую работу за неделю до отпуска – поздно. С первого раза она обычно не удается и ей тоже нужно учиться

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

––

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

Приближается конец недели – отдай немножко неприятной работы и позволь себе, наконец, выходные :)

Советы про найм:

1. Не измеряй опыт во времени

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

2. Никогда не останавливай собеседования и планы развития

Ты круглый год должен интервьюировать или хотя бы знакомиться с людьми.
А ещё – нужно регулярно искать и растить перспективных сотрудников внутри.

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

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

Если человек не знает технологию, но имеет хорошую базу и очень хочет разобраться – он разберётся.
Если человек всё знает, но работать ему неинтересно – сворачивать горы ты его никак не заставишь.

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

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

Это всегда даст тебе больше релевантной информации, чем решение кейсов из учебников

5. Если человек тебе не нравится, не нанимай

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

––

Если пост вам понравится, позже выйдут советы про увольнения :)

О погружении в новую и старую зону ответственности

Пара слов о том, что идет не так у руководителей, приходящих на новую работу. А также – о том, что идет не так у тех, кто работу давно не менял 🙂

1. Работа в новой зоне ответственности

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

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

Неправильный флоу: любой другой.

Не-следование этому совету – одна из топ двух-трех причин, по которой новые руководители не приживаются в компании

2. Работа в старой зоне ответственности

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

Путь нужно повторять. Причем чем чаще меняются части системы – тем чаще нужно заново разбираться.

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

––

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

Visibility

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

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

На менеджерских позициях так больше не работает.

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

– Во-вторых, на твое продвижение и оценку начинает сильно влиять не только твой прямой руководитель, но и лиды уровнями +2/+3, вплоть до c-level. Большинство решений о продвижении руководителей в компаниях и реоргах, выгодных или не-выгодных для них принимается с одобрения и участия менеджеров высокого уровня, тк риск ошибки очень велик (бесконечно больше, чем неправильный найм IC)

––

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

Так что важная часть работы руководителя любого уровня – «public relationships» для себя и своей команды.

––

Полезные проверочные вопросы:

– Давно ли ты общался с руководителями уровня выше твоего прямого о том, что крутого происходит в твоей команде? А о том, что происходит в компании в целом?

– Присутствуют ли в публичном пространстве истории о достижениях твоей команды? Публичное пространство – это общие встречи масштаба компании / статьи на внутренних и внешних ресурсах / другие массовые площадки

– Знают ли тебя и твою команду с положительной стороны руководители соседних команд?

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

Источник – важен

Есть иллюзия, которая складывается у людей в современных компаниях и мешает эффективно защищать свои идеи и внедрять изменения. Звучит (и транслируется в компаниях) она примерно так:

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

Это неправда. Вернее, не совсем правда. Голоса важны, но не одинаково важны, и важны не все :)

––

Когда человек – любой, будь то ceo компании или продакт-менеджер – принимает решение, он не оценивает мнения коллег одинаково. Предложения от людей, которых он хорошо лично знает, по умолчанию принимаются за стоящие рассмотрения. Идеи малознакомых/удаленных по иерархии коллег, в лучшем случае, проходит 10 фильтров. А в худшем – по умолчанию отправляются в корзину. Это просто особенность психики, она не связана с корпоративной культурой

––

Как непонимание этой концепции мешает менеджерам и рядовым сотрудникам?

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

––

Как отличить первую ситуацию от второй?

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

Что делать, если ты попал во вторую ситуацию?

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

Долгосрочно – расширять свою сеть контактов в компании. Человек, который 10 раз по 15 минут поговорил с тобой о делах в компании за последние полгода, даже если вы просто поговорили и ты пару раз очень незначительно ему помог, рассмотрит твою идею с ЧУДОВИЩНО большей вероятностью, чем человек, с которым ты этого не делал.

Если ты еще не успел завести друзей-менеджеров в компании – самое время это сделать :)

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

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

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

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

––

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

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

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

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

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

––

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

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

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

––

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

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

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

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

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

––

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

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

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

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

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

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