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

Примерно 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 однажды при устройстве в не очень технологичную компанию, только начинавшую собирать мобильную команду, собеседовал внешний приглашенный эксперт, не сотрудник компании. Это – нормально!