Lead’s Notes

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

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

––

Например:

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

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

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

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

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

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

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

––

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

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

––

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

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

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

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

#Длиннопост

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

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

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

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

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

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

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

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

––

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

––

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

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

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

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

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

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

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

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

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

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

––

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

––

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

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

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

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

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

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

Channel created