Lead’s Notes

Отличие сильного руководителя от слабого

Доброе утро!

Не любишь понедельники? Вот тебе инсайт вместо кофе:

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

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

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

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

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

Ты больше, чем твои эмоции. Команда их забудет или простит. Команда запомнит твои действия.

А теперь – делай то, что правильно. Удачной недели!

Как провести 1х1 с человеком, перекладывающим ответственность

Часть 2.

Если при разговоре, описанном в предыдущем посте, возникло сопротивление, разберись в мотивации сотрудника:

Боюсь, что смежники пошлют меня куда подальше

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

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

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

Нет, все равно не буду. Я согласен только писать код и ничего кроме этого

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

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

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

Как провести 1х1 с человеком, перекладывающим ответственность

Часть 1.

Продолжаем отвечать на вопросы.

Бывает, что сотрудник затягивает сроки, проваливает проекты, а потом говорит:

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

Cоветую прозрачно сказать сотруднику, что его работа – не просто написать свою часть кода. Его работа – это:

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

Пункт (а) – cамый простой.

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

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

Пункты (c) и (d) обязательно объяснять на примерах. Для этого нужно вместе с инженером рассмотреть несколько свежих кейсов и показать, как можно было поступить:

1. Здесь – стоило прийти и попинать Петю, напомнить ему про дедлайн и вашу договорённость. Не сработало – эскалируешь в меня

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

3. Здесь – можно было написать дизайнеру. Не помогло – эскалируешь

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

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

#ЧтоПосмотреть

Наступил вечер пятницы, так что..развлекательный контент!
За не-развлекательным – просто полистай канал вверх 🙂

Пост про книги уже был, теперь – про кино.

Айтишного, думаю, тебе хватило и за неделю, так что вечером будет не-айтишное.

––

Одержимость – анти-инструкция про работу с топ-перформерами и выгоранием. И в целом очень крутой фильм. А тебе доводилось сталкиваться с такими руководителями?)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

––

Что делать?

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

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

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

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

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

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

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

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

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

––

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

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

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

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

Например:

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

––

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

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

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

––

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

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

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

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

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

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

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

Баланс между техникой и пипл-менеджментом у лидов разного уровня. Часть 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 намеренно упрощены, тк на самом деле есть ещё найм, публичные активности, пятничное пиво с командой и тд. Они ситуативно отъедают проценты. Но с ними пост превратился бы в очень-много-буков-и-сложные-формулы или..в часовой подкаст, которых я пока не выпускаю)

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

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

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

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

To Sum Up

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

––

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что делать?

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

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

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

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

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

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

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

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

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

Как?

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

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

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

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

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

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

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

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

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

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

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

––

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

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

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

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

–

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

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

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

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

–

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

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

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

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

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

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

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

––

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

1. https://pragprog.com/titles/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/

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

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

––

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