«Если рядом с вами нет джунов, вы не сеньор». Эту фразу Жером Петаццони, в прошлом инженер Docker, услышал на конференции в 2014 году и пересмотрел своё отношение к наставничеству. Сейчас нечто похожее может быть указано прямо в карьерной лестнице компании. Но чтобы менторство засчитали, о нём лучше договориться заранее, пока джуны ещё не пишут вам в одиннадцать вечера.
«Если рядом с вами нет джунов, вы не сеньор». Эту фразу Жером Петаццони, в прошлом инженер Docker, услышал на конференции в 2014 году и пересмотрел своё отношение к наставничеству. Сейчас нечто похожее может быть указано прямо в карьерной лестнице компании. Но чтобы менторство засчитали, о нём лучше договориться заранее, пока джуны ещё не пишут вам в одиннадцать вечера.
В статье есть ссылки партнеров. Это значит, что если вы что-то покупаете с нашей помощью — вы также поддерживаете dev.by. (Вот другой способ).
При этом редакция и авторы независимы в выборе темы, концепции материала, фокуса описания, подхода к услугам или товарам. Прежде чем что-то советовать, мы много читаем и смотрим по теме, говорим с экспертами.
Редакция может выражать свое мнение и пробовать всё на себе.
Если рекомендательный материал обновляется, мы указываем, что и когда поменялось, в самом начале.
С опытом легко попасть в ловушку: вы знаете систему лучше других, поэтому вопросы несут вам. Отвечаете быстро, поэтому несут снова. Через полгода половина команды ходит к вам за готовыми решениями, а ваш календарь выглядит соответственно.
Менторство, когда оно работает, действует в обратную сторону: человек постепенно справляется сам, и вопросов к вам становится меньше.
Это напрямую связано с карьерой. После сеньора у инженера, который не хочет уходить в менеджеры, обычно идёт уровень Staff. От него теперь ждут влияния за пределами своей команды и своего репозитория: замечать общие проблемы, менять процессы, делать сильнее других. Уилл Ларсон, технический директор финтех-компании Imprint и автор книги «Staff Engineer», пишет, что изменить долгосрочную траекторию компании гораздо вероятнее, вырастив инженеров вокруг себя, чем личным геройством.
По дороге тренируется то, чего ждут от Staff и лида: объяснять сложное простыми словами, давать обратную связь так, чтобы её услышали, и развивать людей без микроменеджмента.
Есть и совсем приземлённая выгода. Когда устройство сервиса знает не один человек, кодовая база перестаёт зависеть только от вас. Чёрных ящиков, которые открываются одним ключом, становится меньше, и остаётся время на задачи уровня Staff.
Если трое коллег научились решать задачи без вас, при оценке это сильный аргумент. Но только если в вашей компании так считают.
Проверить это проще всего по карьерной лестнице, документу, где расписано, чего ждут от каждого грейда. У блог-платформы Medium лестница публичная (правда, сама компания с 2019 года ею не пользуется). Менторство там — одна из шестнадцати осей оценки. На нижней ступени инженер помогает новичкам освоиться, на верхней выстраивает в команде культуру обучения, например учит уже самих менторов. А на второй написано то, что пригодится дальше: подводить людей к выводам, а не выдавать ответ.
Если в вашей лестнице развитие коллег входит в ожидания от Staff, менторство становится частью аргументов за повышение. Если менеджер считает его добровольным хобби, число созвонов на повышение не повлияет.
Что бывает, когда этого не проверили, рассказывает Таня Райли, автор книги «The Staff Engineer’s Path». В докладе «Being Glue» она приводит историю, по её словам, «не совсем правдивую, зато сложенную из многих правдивых».
Героиня пишет документы для новичков, заводит программу менторства, помогает застрявшим коллегам сдвинуться с места. Проект выходит в срок, и все хвалят коллегу, которому она расчистила дорогу: «Молодец, Awesome Coder!» А ей на разговоре о повышении говорят: «Софт-скиллы у тебя выдающиеся. Просто мы не считаем тебя инженером. Может, тебе в проджект-менеджеры?»
У Ларсона есть и наблюдение про спонсорство: самые эффективные Staff-инженеры сочетают умеренное количество менторства с заметно большим спонсорством. Разницу хорошо объясняет Лара Хоган, бывший вице-президент по инженерии в Kickstarter. Ментор советует. Спонсор продвигает: зовёт человека вести новый проект, даёт рассказать о своей работе на общей встрече, пересылает его отчёт тем, кто иначе бы его не увидел.
Поэтому о том, будет ли менторство учитываться в оценке, лучше спросить менеджера — сразу до того как вы согласились взять ещё двух человек.
Чтобы менторство не стало второй работой, правила обсуждают заранее. Сложная методика для этого не нужна. Многое можно подсмотреть у GitLab, компании, которая делает одноимённую платформу для разработки. Менторская программа компании описана в открытом справочнике для сотрудников.
Как часто встречаться. GitLab предлагает раз в две недели по 30–45 минут, а всю программу рассчитывать на три–шесть месяцев. Вопрос, который не горит, ждёт встречи.
Кто готовит повестку. Подопечный. В GitLab так же устроены встречи один на один с руководителем: ведёт их подчинённый. Если человек пришёл без темы, можно посмотреть, как продвигаются дела, придумывать ему занятие на ходу не нужно.
Где общаться между встречами. В одном месте и с понятным сроком ответа, например «пиши в личку, отвечу до конца дня». Всё, что тянет на разговор, переезжает на следующую встречу.
Что входит в менторство. Технический и карьерный рост. Разбирать личные конфликты, раздавать задачи и отвечать за проект подопечного должен его руководитель. GitLab советует с самого начала развести, за что отвечаете вы, а за что менеджер подопечного.
Когда всё пересмотреть. Если менторство регулярно заходит на вечера, мешает вашим задачам или превращается в постоянную поддержку, формат меняют.
Всё это помещается на одну страницу: цель, частота, рамки, каналы и то, по чему вы поймёте, что получилось. В Мичиганском университете в США такой план ждут от каждой пары «аспирант — научный руководитель», и в руководстве для менторов есть готовый шаблон: как связываться, в какой срок ждать ответа, нужна ли повестка. Такую страницу удобно потом показать своему менеджеру.
Такое сообщение приходит в самый неудобный момент и выглядит как пять минут работы. Открыть IDE и поправить самому и правда быстрее. Райли в «The Staff Engineer’s Path» это признаёт, но забирать задачу всё равно не советует: сегодняшние джуны — будущие сеньоры, и учатся они на том, что решают своими руками.
Дешевле всего ответить вопросом. Что уже пробовал? Какие видишь варианты? Почему выбрал этот подход? Соблазн открыть редактор и починить всё самому никуда не денется, но тогда через неделю будет такой же вопрос.
Часть вопросов можно отсечь ещё до того, как они дойдут до вас. Perl-разработчик Нил Бауэрс сформулировал правило пятнадцати минут: застрял — побейся ещё четверть часа, даже если кажется, что стучишь головой в стену. А потом обязательно спроси, но сначала запиши, что пытаешься сделать и что уже пробовал. Вторая половина правила так же важна, как первая: джун, который два дня молча сидит над ошибкой, тоже проблема.
Бывает, что вопрос решается в процессе формулировки. Джефф Атвуд, сооснователь Stack Overflow, пересказывал историю инженера Энди. Тот пришёл с вопросом к начальнику, а начальник показал в угол, где стояло чучело утки: спроси её. Утка, по словам Энди, была «действительно набитой и очень мёртвой». Начальника звали Боб, утку — Bob Junior. Спрашивать полагалось вслух, и на середине вопроса Энди сам понял ответ. С тех пор правило было такое: сначала спроси утку, а если не поможет, приходи.
Сейчас это называют методом резиновой уточки: объясни проблему вслух кому угодно, хоть игрушке на мониторе.
Если вопрос всё-таки дошёл до вас, пригодятся советы Джулии Эванс, программистки и автора технических комиксов-зинов. В тексте о том, как отвечать на вопросы, она предлагает сначала уточнить, о чём на самом деле спрашивают, и выяснить, что человек уже знает. Показать, как вы ищете ответ: какой лог открыли, где смотрите документацию. И не изображать изумление. После «ты не знаешь, что такое LINUX KERNEL?!!!?!!!???» (пунктуация Эванс) спрашивать что-то ещё уже не хочется.
Свизек Теллер, инженер и автор книги «Senior Engineer Mindset», описывает свой подход совсем коротко: предупреждай, но не блокируй; ты советуешь, они решают. Если подопечный выбрал спорный вариант, пусть попробует. По словам Теллера, ничто так не объясняет, что программирование растянуто во времени, как необходимость разгребать собственные глупые решения пять месяцев спустя. Зато ваше «а, наступил на грабли, вот почему» запомнится навсегда.
Больше всего, по Теллеру, ментор успевает сделать за десять минут разговора об устройстве решения, пока человек ещё не сел писать код. И ещё из его практики: в одном код-ревью хватит одного-двух уроков.
Менторство от бесплатной поддержки проще всего отличить по тому, как ведёт себя подопечный.
Когда всё нормально, человек приходит с проблемой, рассказывает, что уже попробовал, и предлагает варианты. Через несколько месяцев ваша помощь нужна ему всё реже.
Когда нет, он пишет «не работает, посмотри», ждёт готового решения, приносит код на ручную чистку и через неделю возвращается с тем же вопросом.
У Эми Хой, дизайнера и разработчицы, для таких людей есть название: «вампиры помощи». В 2006 году она написала о них сатирический определитель, с признаками заражения и способами перевоспитания. Эми рассказывала про open source-сообщества, но в рабочем Slack портрет узнаётся не хуже. Совет у неё неожиданно мирный: вампир ведёт себя так на автомате, поэтому ненавидеть его не нужно. Протыкать колом тоже.
Второй сигнал подаёт менеджер. Фразу «ну вы же сеньор, вам несложно помочь» слышно часто, а в целях, в оценке и в разговоре о повышении ваша помощь не появляется. Это та самая невидимая работа из доклада Райли.
О менторстве обычно вспоминают в конце года, когда пора писать самооценку. И на ум приходит что-то вроде «кажется, я кого-то там менторил».
Джулия Эванс предлагает вести brag document (дословно «документ, чтобы хвастаться»), то есть список того, что вы сделали. Её довод простой. Вы забудете, что сделали, а если забудете вы, то менеджер, каким бы хорошим он ни был, скорее всего, тоже. Эванс признаётся, что писать такое поначалу странно, будто объявляешь: «Эй, посмотрите, сколько классного я сделал за год».
Ларсон советует пойти дальше и начать писать промо-пакет на Staff, то есть документ с обоснованием повышения, задолго до того, как повышение станет реальным, и вести его так же, как brag document.
Каждую встречу записывать не нужно. Хватит нескольких строк:
Запись «менторил двух джунов» почти ничего не говорит. Лучше так: «Выстроил регулярное техническое менторство для двух инженеров. Они сами прошли онбординг, взяли на себя сервисы и стали реже эскалировать проблемы по этим компонентам». С цифрами будет ещё убедительнее.
Особенно это пригодится тем, кто недавно переехал. На новом месте никто не знает, что вы делали раньше, а такие записи покажут это лучше, чем «участвовал» и «помогал». К тому же люди, которых вы менторили, могут подтвердить ваш вклад.
Отказаться от менторства нормально, сеньором вы от этого быть не перестанете. Если свои проекты горят, менеджер менторство не учитывает, а подопечный ждёт готовых решений, честный отказ бывает полезнее согласия.
В руководстве для менторов Мичиганского университета прямо сказано, что ментор должен ясно говорить, что может дать, а что нет, и понимать, когда лучше направить человека к кому-то ещё. Отказ может звучать, например, так: «Сейчас не смогу уделять этому достаточно времени, а быть полезным наполовину не хочу. Поговори с Машей, у неё как раз опыт с этим сервисом». Это лучше, чем согласиться и через три месяца отвечать на сообщения всё реже.
Если хочется разобраться в менторстве глубже, на Coursera есть курсы на эту тему.
Coaching and Mentoring for Workplace Success — курс индийской образовательной компании EDUCBA на Coursera. В нём разбирают, чем коучинг отличается от менторства, приёмы работы с подопечным и то, как выстроить отношения на доверии.
Может подойти, если вы только начинаете превращать стихийную помощь коллегам в осознанную практику. Курс вводный: тем, кто менторит давно, он может показаться слишком простым.
Coaching & Mentoring Practice — курс Microsoft на Coursera. В нём модели GROW и CLEAR (схемы коучингового разговора: от того, чего человек хочет, к конкретным шагам), ситуационный коучинг, устройство сети взаимного менторства, где коллеги одного уровня учат друг друга, и способы измерить эффект. В конце участник собирает план развития людей.
Может подойти сеньору, который уже регулярно помогает коллегам и хочет превратить это в процесс. Правда, рассчитан он скорее на руководителей и HR и местами опирается на инструменты Microsoft вроде Viva и Power BI. Как разбирать код с джуном, там не расскажут.
Для начала хватит одного-двух подопечных, встречи раз в две недели, повестки от подопечного, понятных рамок и договорённости с менеджером о том, как это учтут в оценке.
Дальше видно по динамике. Если через несколько месяцев люди стали самостоятельнее, вы реже тушите чужие пожары, а менторство появилось в вашей оценке, значит, всё работает.
А если вы стали человеком, которому в любой момент можно написать «у меня не работает, посмотри», пора вернуться к договорённостям. Иначе менторство так и останется чужим бэклогом, который незаметно переехал в ваш вечер.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.
Правильный ответ: никак.
Единственное исключение - это когда менторишь своих собственных учеников, с которых потом будешь снимать пользу. Но это про-активный процесс, его никогда не предлагают.