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

Примерно 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% команд в компании просто потому, что это – сложно. А ещё – я ни разу не видел, чтобы процессы шли хорошо, если лид команды самоустранялся от них и всё отдавал продакту/проджекту/скрам-мастеру. Не потому, что люди – плохие, а потому, что надо уметь не только строить пайплайн работы и набор встреч, а ещё и сутево хорошо понимать, что делают ребята, вовлечённые в процесс.

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

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

3. Технические вопросы

Грубыми подсчетами получаем, что около 30% времени должно оставаться на технические задачи у лида первого уровня с командой в ~5 человек. И, до тех пор, пока ты находишься на таком уровне, это время стоит правда инвестировать в технику. Просто потому, что в противном случае ты по квалификации быстро отстанешь от своих прямых подчинённых и превратишься из руководителя команды в руководителя проектов

To Sum Up

50-20-30 люди-процессы-техника у лида средней команды первого уровня

––

Завтра выйдет продолжение про M2+ руководителей

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

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

M2+ руководитель:

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

Для начала – 10% на прямого подчинённого, как у M1.
А ещё – у твоих прямых подчинённых теперь есть команды. И туда надо заглядывать, измерять температуру, помогать своим подчиненным-лидам находить проблемы, отмечать быстрорастущих непрямых подчинённых и т.д.

Добавим 3-5% налога на работу с командой. Итого – 15% на директ-репорта

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

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

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

Накидываем 5-10% на процессы к цифрам M1. По крайней мере, до тех пор, пока вы с командой очень плотно не сработались и не начали понимать друг друга с полуслова (а это – займёт время).

Итого – 25-30% на процессы

3. Техника

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

To Sum Up:

У M2 руководителя, который не выстроил команду до идеального состояния, с четырьмя direct-reports:

60-30-10 люди-процессы-техника

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

Важно: 5 прямых подчиненных дадут тебе загрузку больше 100%. Я не встречал хороших M2, которые работают с текущей командой меньше года, имеют 5 прямых подчиненных и укладываются в 40-часовую рабочую неделю. Это примерно невозможно

Как следствие: норма прямых подчиненных у M2 всегда меньше – чем у M1. Выше по лестнице – правило сохраняется

––

Схемы M1 и M2 намеренно упрощены, тк на самом деле есть ещё найм, публичные активности, пятничное пиво с командой и тд. Они ситуативно отъедают проценты. Но с ними пост превратился бы в очень-много-буков-и-сложные-формулы или..в часовой подкаст, которых я пока не выпускаю)

Я устал от ограничений на размер поста и накатал статью на хабр: https://habr.com/ru/articles/813731/

Будем делить контент на два вида: покороче – в телеге, подлиннее – в журнале)

Кстати, говорят, лайки и комменты на хабре тоже помогают)

Очевидное и не очень

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

Например:

– Руководитель не проводит регулярные 1x1 с подчинёнными
– Разработчик отдаёт на ревью код без тестов
– Продакт приносит в команду задачи в последний момент, а в описании – только ссылка на фигму
– Проджект делает круглые глаза, когда ты спрашиваешь у него, где посмотреть гант по важному проекту

––

Мне и многим моим знакомым – случалось! Я даже слышал, что это влияло и влияет на оценки людей на ревью :)

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

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

––

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

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

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

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

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

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

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

Но бывают ситуации сложнее:

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

––

Что делать?

Внедрять практику менторства

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

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

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

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

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

А человек примет обратную связь не от руководителя?

1. В большинстве случаев – примет, если правильно и честно объяснить мотивацию: «Я хочу помочь тебе вырасти, но моего ресурса на это сейчас не хватает. А вот у Васи – есть возможность и он успешно работает в компании на позиции X. Переняв его экспертизу, ты сможешь вырасти. Более того – Вася может тебе помогать, а уволить тебя за косяки – не может, он же не руководитель) Как тебе идея?»

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

––

На дистанции – конечно, стоит растить менторов и из людей в своей команде, если сейчас их нет 🙂

Делитесь в комментариях своими практиками!

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

Как синьору стать лидом? В какие навыки инвестировать?

Моё мнение про харды M1:

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

Если ты уже синьор – хардов тебе хватает.

Синьора от лида отличают управленческие скиллы. В них входят навыки:

– Переговоров
– Проектного управления
– Организации процессов
– Выдачи обратной связи людям

Как приобрести эти навыки и стать лидом

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

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

Вам с лидом нужно сделать две вещи:

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

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

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

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

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

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

Обещал пост про мотивацию перехода в управленческий трек и людей, которым стоит (или не стоит) это делать.

Сказано – сделано: https://habr.com/ru/articles/814911/

Лайки на хабре помогают не меньше лайков в канале – менеджерский контент там не всегда жалуют 🙂