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

Примерно 4 года назад я, в качестве эксперимента, начал записывать свои обещания другим людям и обещания других людей мне.
Результат превзошёл ожидания: я думал, что немного приведу себя в тонус и перестану просыпать 10% коммитов, а на деле..я на какое-то время перестал выходить с работы и отдыхать.

Оказалось, что потерянных договорённостей..более половины!

Я регулярно открывал заметки и обнаруживал вещи, о существовании которых не подозревал: отправить презентацию руководителю / пнуть смежников по тикету, связанному с ИБ / чекнуть, как дела с задачкой вооон у того парня (кажется, он начинает выгорать / проверить, как протестировали задачу X… Оказалось, что моё представление о том, что я теряю процентов 10 обещаний основано только на тех вещах, о которых люди мне сами напоминают (или о которых я постфактум вспоминаю). На самом деле, есть огромное количество вещей, которые просто уходят в никуда! А многие из них обсуждались не просто так и правда несли пользу

––

Что делать, чтобы не быть как я? Или быть как я, но лучше, чем я 4 года назад?

Начни прямо сейчас работать с тудушницей. Например, https://www.rememberthemilk.com/ – простое как валенок и бесплатное, я сидел на нём довольно долго

Или возьми любое другое, которое понравится (можно даже текстовый файл завести)

Даже если написанное выше кажется бредом – просто попробуй в течение пары недель поработать по фреймворку:

– Если что-то можно сделать сразу – сделай
– Если что-то надо бы сделать, но для этого нужно попинать людей/чего-то почитать/дождаться ответа в чатике/поресерчить/etc – сразу запиши в тудушницу с дедлайном

И посмотреть, что изменится в жизни:)

Что может быть хуже, чем процесс увольнения конфликтного и/или недостаточно перформящего сотрудника в команде?

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

Если ты думаешь, что андерперформер/токсик/в-любом-ином-смысле-не-фит сотрудник – это только твоя, как руководителя, головная боль и она может быть меньше головной боли от поиска замены – ты, к сожалению, ошибаешься 🙁

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

Действительно ли ты готов избегать неприятных разговоров ценой перформанса и мотивации всей команды?

Напоминать о своих задачах и проблемах смежникам – не стыдно. Более того: это обязательно нужно делать :)

У большинства твоих коллег (за исключением, может быть, джунов и стажеров) – очень, очень много задач. Многие из них эти задачки ещё и не записывают в тудушницу (читай – теряют половину :) ). Задача – это не только тикет в таск-менеджере. Это и непрочитанное сообщение в мессенджере. И данное кому-то в коридоре обещание. И еще 100 разных договорённостей, возникающих в разговорах с людьми

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

А почему люди считают что-то важным?

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

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

Что делать, если в ответ на напоминание люди попросят тебя пойти куда подальше? Рассказать им, почему задачу и правда важно сделать. Ты же не делаешь ненужных задач, правда?)

#Длиннопост

Про матричные роли и делегирование

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

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

Например:
У меня есть три команды.

1. Продуктовая команда бэка
2. Продуктовая команда фронта
3. Команда инфры

Мы затеваем большую перестройку, прошивающую почти весь продукт и задевающую кусочек инфры. Распределение нагрузки между ними: 40-40-20.

У меня возникал следующий ход рассуждений:

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

––

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

––

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

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

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

Ребята, у нас есть большой и сложный проект. Нам нужно, чтобы один человек взял на себя головную боль ведения этого проекта, собрал большую картинку, как технически работает система end to end и проследил, что мы правда к этой картинке придём. Этим займётся Вася и станет матричным руководителем проекта. Пожалуйста, всячески содействуйте ему, не игнорируйте вопросы и предложения, и будьте командой, В случае конфликта – эскалируйте в меня

– проходит абсолютно нормально.

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

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

Матричное управление применимо не только на уровне тимлидов. Оно вполне может работать и с несколькими IC.

Важные пререквизиты:

1. Между людьми в команде должны быть доверительные отношения. Если сотрудники находятся в состоянии политической борьбы, матричные роли не работают
2. Со всеми ключевыми участниками проекта нужно в явном виде проговорить конфигурацию и ожидания друг от друга
3. Делегируя проект, ты не должен терять его детали и контекст

––

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

О плохих ответах и хороших вопросах.

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

––

Например:

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

– Ну..это займет три месяца разработки. Будет готово в Q5

Думаешь: Ну тут какой-то буллшит. Ну как может это занимать три месяца?! Что-то идет не так. Хотя..может – это я дурак и не понимаю специфики сервиса. Хотя..всё таки уточню

– Ребята, а почему так долго?
– У нас достигли предела масштабирования балансные транзакции; нужно переделывать интерфейсы абстрактных фабрик биллинговых адаптеров; а ещё – 10 миграций в базе придется сделать

Балансные транзакции? Интерфейсы биллинговых адаптеров? Чего вообще?

А 10 миграций в базе им зачем?

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

––

Знакомая ситуация?

Для меня и половины людей, которые при мне меняли роль на более масштабную – знакомая :)

––

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

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

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

Вести разговор нужно ровно до тех пор, пока ты всё не поймёшь и не поверишь в решение!

#ЧтоПочитать

«Если б про управление было что-нибудь хорошее почитать – я бы уже и сам давно почитал!» (с)

––

Я не читал ни одной очень крутой книги по управлению.
Но есть несколько не совсем кринжовых / содержащих полезные мысли.
По пятницам я ленюсь, так что будет всего 3, top of mind:

1. https://pragprog.com/noscripts/jsengman/become-an-effective-software-engineering-manager/

Из книги ты узнаешь:

– В чем состоит работа тимлида
– Как проводить 1x1 и почему к нему нужно готовиться
– Что такое zone of proximal development

Нужно делать поправку на культурные различия. Описанный в книге менеджер живет очень чилловой жизнью и много парится про work life balance. Много ли таких успешных менеджеров ты видел в России?)

Нормального перевода я, в своё время, не видел. Но ты же давно в IT, правда?

2. https://teamtopologies.com/

Из книги ты узнаешь:

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

Книга – душная. Перевод на русский – плохой, читай в оригинале. Но другой хорошей по теме я не видел
Я тебя предупредил)

3. https://www.radicalcandor.com/

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

Самая чилловая книга в списке (и, возможно, единственная, переведённая на русский)

––

Пиратские ссылки на книги не прилагаю, чтобы случайно чего-то не нарушить, гугл в помощь:)

Уже умеешь управлять сложными проектами и командами?

Круто!
Есть ещё один важный проект, которым нужно управлять: твоё эмоциональное состояние

–

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

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

Твоё настроение (в отличие от явно выданных вербально указаний 🙂 ) во многих случаях очень эффективно распространяется и принимается командой.

Если протух руководитель – со временем, к сожалению, протухнет и команда.

–

Как не протухнуть?

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

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

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

3. Не забывать делать приятные для себя вещи. Любишь пить пиво? Значит, нужна регулярная задача – всё бросить и пойти пить пиво. Любишь играть в футбол? Внеси тренировки в рабочий календарь и прекрати их пропускать. Артхаус-кино? Фото-выставки? Вкусная еда? Короче, ты ведь знаешь, что делать – не пропускай!

Отношения в команде
––

Крепкие и открытые отношения сотрудников в твоей команде влияют на:

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

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

Хочешь большую и эффективную команду? Поработай над отношениями в ней.

Как?

Делюсь методами, которые работали в моих командах. Есть и другие, но размер поста ограничен :(

1. Матричные роли и проекты. Описание – тут.

Практика бустит автономность команды.

2. Культура горизонтальных фидбеков:
a. Начни собирать с людей фидбек о работе с их коллегами
b. Попроси ребят начать давать фидбеки друг другу. Помоги тем, у кого не получлиось

Рекомендации, которые стоит дать команде:

– Фидбек нужно давать голосом
– Фидбек нужно давать не ультимативно, а в виде совета: «Я заметил X в совместной работе. Думаю, это может мешать твоей эффективности и росту. Если позволишь, я поделюсь с тобой практикой, которую применяю сам в таких ситуациях. Буду рад, если она тебе поможет»
– Фидбек могут не принять – это нормально

Практика бустит открытость отношений и рост людей в команде

3. Тусовки без тебя

a. Убедись, что у команды есть периодические веселые мероприятия с пивом/настолками/whatever you like. Если их всё ещё нет – срочно создай чат и собирай всех в следующую пятницу

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

Практика улучшает отношения и растит доверие между людьми

––

Детальные посты про эти техники выйдут отдельно

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

Ошибки растущих лидов: процессы vs детали

Часто лиды, умеющие круто настраивать процессы, отличающие скрам от канбана и velocity от capacity – это люди, управляющие немаленькими командами (10+ человек). На меньшем масштабе можно справиться и уровнем: «держу всё в голове и пользуюсь здравым смыслом»

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

Быстрый тест: выпиши 3-5 самых важных последних проектов команды и для каждого ответь на вопрос: насколько хорошо ты технически понимаешь, как работают эти системы? Есть несколько ответов «понимаю очень приблизительно или не понимаю совсем»? Детали, вероятно, просыпаны)
––

Почему это важно?

Процесс – это «форма» того, как работает команда. Без контроля «содержания» он может стать неэффективным или вредным.

– Трекаешь velocity, оно растёт? Уверен, что команда не начала на всякий случай умножать оценки на 2, сохранив или просадив реальный перформанс?
– Команда взяла цель «растить метрику X, не поднимая количество обращений в саппорт» и цифры в порядке? Уверен, что вы правда делаете хороший продукт, а не просто отключили кнопку «обратиться в поддержку»?
– Смотришь на количество коммитов разрабов и выделяешь топ-перформеров? А ты уверен, что написанный код – не полное говно?

Список можно долго продолжать.

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

Что делать?

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

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

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

Важно не путать погружение и микроменеджмент. О микроменеджменте – в другом посте :)

Собеседования и резюме

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

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

Почему?

Я видел senior+ разработчиков Intel, которые зависали, когда разговор заходил об алгоритмах более сложных, чем «написать вложенный цикл». И инженеров из noname стартапов, которые могли побить 70% моей команды по навыкам проектирования распределённых систем. Внимательное чтение резюме до собеседования создаёт у тебя в голове предвзятое отношение к кандидату, это мешает объективно оценивать его навыки и повышает вероятность незаслуженно накинуть или не-накинуть грейд. Если твоя цель – собрать самую сильную (а не самую титулованную / дорогую) команду, прекращай оценивать людей по резюме.

Внимательно читай резюме после собеседования, если остались сомнения. Не до него!

Как проверить релевантный опыт кандидата без резюме?

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

– «Расскажи подробно, как ты выстраивал процессы в команде?»
– «Ты работал с технологией X? А для чего в последний раз её применил? А какие альтернативы рассматривал?»

Это правильнее, чем просто поверить строчке в CV.

А если я не знаю, как задать хороший вопрос для проверки скилла кандидата?

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

А давайте устроим немножко интерактива в канале. Нас уже за сотку перевалило – глядишь, кто-нибудь да напишет:

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

Ответы выйдут в отдельных постах

#ОтветыНаВопросы

Как вырасти от M1 до M2? Часть 1

M1 Engineering Manager – обычный тимлид
M2 Engineering Manager – руководитель лидов M1

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

1. Твоя команда – классно работает

Звучит тривиально, но:

a. Попадаешь ли ты на 80% в свои коммиты стейкхолдерам? Касается и продуктового бэклога, и техдолга. Всё ли хорошо с визибилити и пониманием стейкхолдерами состояния твоих дел?
b. Перестают ли твои андерперформеры быть таковыми за несколько месяцев? // прокачать перформанс – нормально; расстаться – нормально; сохранять статус кво – плохо
c. Всё ли хорошо со стабильностью сервисов?
d. Растут ли по скиллам твои подчинённые? А если растут – считают ли тебя при этом компетентным?

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

2. Твоя команда может работать без тебя

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

Если кандидатов несколько – начни с того, чтобы распределить управленческую нагрузку между ними (например, Вася ревьюит и помогает вести проекты по скоупу разработки А; Петя – ревьюит и помогает вести проекты по скоупу разработки Б) и понаблюдать, как и насколько быстро будет расти каждый из них. Важно: нужно очень прозрачно коммуницировать всем в команде зоны ответственности и следить, чтобы люди не толкались локтями по задачам, чтобы избежать политической борьбы в команде

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

#ОтветыНаВопросы

Как вырасти от M1 до M2? Часть 2

3. Ты успешно ведёшь проекты на стыках нескольких команд

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

Это, как и пункт (2) – полноценная часть опыта работы M2-руководителя

4. Регулярно общаться с руководителем о том, что ты хочешь попасть на уровень M2

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

Нормально выглядит разговор следующего вида:

«
Я хочу дорасти до руководителя более высокого уровня.

– Я знаю, что в моей текущей зоне ответственности есть такие-то проблемы. Вот так, я думаю, можно их решить, и я собираюсь это сделать. Есть ли другие, значимые по твоему мнению?
– Прямо сейчас команда не может самостоятельно жить без меня. Я собираюсь распределить вещи X, Y, Z; из Васи я попробую вырастить заместителя (или, как минимум, частичного заместителя), и вот почему я думаю, что это может сработать
– Мне видится важным получить опыт и показать, что я могу вести проекты с другими лидами моего текущего уровня. Можешь ли ты помочь мне подобрать проекты в компании (например, через несколько месяцев, когда я продвинусь по пунктам 1 и 2 и освобожу времени), чтобы я попробовал? Если увидишь, что я тебя подвожу, открутим всё обратно
– Какие ещё вещи, по твоему мнению, важны в нашей компании и нашем контексте, чтобы я смог вырасти?»

Первые три пункта – must have почти независимо от того, с какими задачами ты работаешь. Твой руководитель, вероятно, добавит других вещей, специфичных для компании, её текущих болей и потребностей, особенностей людей в вашем отделе и тд

5. Что делать, если руководитель мне откажет?

Спросить, почему)

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

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

#ОтветыНаВопросы

Баланс между техникой и пипл-менеджментом у лидов разного уровня. Часть 1

Начнём с M1-руководителя:

1. Сколько времени тратить на людей

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

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

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

Получается, если в команде 3 человека – на работу с ними нужно 30% ресурса. Если людей у тебя 7 – 70%. Поэтому больше 6-7 подчинённых иметь не рекомендуется

2. Процессы и работа со стейкхолдерами

Помимо работы с подчинёнными у тебя есть процессы – планирования/дейлики/груминги и тд. Ну и, собственно, взаимодействие с менеджерами и другими заказчиками. Если команда не огромная и ты с ней не первый день – в 15-20% времени будешь укладываться

Процессы идут хорошо, если перформанс команды растёт, сходимость проектов растёт (или достигла уровня 70%+ и держится там) и люди в команде и за её пределами хорошо понимают, что происходит. Если это не верно – ты либо воюешь своими процессами не в ту сторону, либо недостаточно в них инвестируешь. По личному опыту – процессы идут хорошо не более, чем у 50% команд в компании просто потому, что это – сложно. А ещё – я ни разу не видел, чтобы процессы шли хорошо, если лид команды самоустранялся от них и всё отдавал продакту/проджекту/скрам-мастеру. Не потому, что люди – плохие, а потому, что надо уметь не только строить пайплайн работы и набор встреч, а ещё и сутево хорошо понимать, что делают ребята, вовлечённые в процесс.