Это, прямо скажем, очень фиговый фидбек, потому что вообще непонятно, что иммется в виду. Научите своего руководителя модели фидбека SBI или COIN, сразу станет легче и давать и понимать
цель, конечно же, не в карьере. Просто человеку свойственно расти над собой до какого-то момента, и часто бывает так, что на определенной позиции становится "тесно". Вы крутой спец, много умеете, много знаете, хочется большего, потому что есть силы на свершения. И тогда вы растете, переходите на новый уровень карьеры (будь то менеджмент или техническая ветка).
А бывает так, что вы дошли до удобного уровня. Вам нравится ваша работа, вам нравится ваш доход, тогда и рост не нужен. Расти (и растить) из под палки - самая тупая вещь, которую можно себе придумать :)
конечно это не про смену лычки, а про увеличение ответственности на каждом новом уровне. Вот Иван пишет, что синьор работает на уровне команды, Lead на уровне отдела, а Principal - на уровне всей компании. И влияние у этих ролей соотствествующее. Одно дело улучшать один конкретный продукт (или его часть), а другое - участвовать в определении всей технической стратегии компании.
Я тоже работаю в Букинге. У нас рост в Principal – это не про "я чот хочу расти, дайте лычку". Это про "я уже делаю дофига крутых вещей и влияю на континенты, я заслужил". То есть промоушн – это признание заслуг. Но и закрепление за тобой статуса, что после промоушна от тебя ожидаются те же высокие высоты.
Ну смотри. Ученик - student, учитель - teacher. Mentor и mentee - самостоятельные понятия, отличающиеся от обучения (мы кстати про это пытались говорить в этом видео).
Мне самому не очень радует глаз слово менти, и я иногда использую слово ученик в текстах (дабы избегать частого употребления менти), но в то же время хочется быть максимально близко к оригиналу в смыслах, так что почему бы и не внедрить новый термин? Ментор же прижился :)
Отличное замечание, сейчас попробую объяснить.
Оба термина используются тут сознательно. Ментор — потому что так короче, созвучно с доменом и уже достаточно неплохо устоялось в обиходе. При этом я периодически использую слово «наставник» как тождественное (правда есть люди, которые считают будто наставник и ментор это разное, но я не такой).
А вот по поводу менти сложнее. Когда я только запустил сервис, я сразу задумался о том, а каким же словом называть человека, кто обращается за помощью ментора. Первое что приходит на ум — ученик. Но на мой взгляд это не совсем правильно, потому что ментор — не учитель. Подопечный? Возможно, но тоже не совсем корректно, потому что ментор не опекает, он наставляет. Наставляемый? Наиболее близко, но очень длинно и неудобно. Был ещё вариант Телемах, но как-то не пошло :)
Мы долго обсуждали это нашей командой менторов, но в итоге пришли к мнению, что ничего лучше менти пока не подбирается. Но может тут в комментах что-то родится?
Не знаю какая там предпосылка была у той статьи (кстати весьма неплохой), но эту я написал в корп. блог исключительно потому, что мы делали митап (на основе которого и родился текст) совместно с компанией SkillFactory и Игорь Полянский (ментор) как раз оттуда, делает там курс. Это не попытка хайпануть на теме, это рассказ о менторстве как части обучения, чем и занимается SkillFactory.
(дисклеймер, я к SkillFactory не имею никакого отношения, кроме того, что мы сделали митап вместе)
Коуч — эксперт в коучинге, то есть в задавании открытых вопросов, которые вызывают мыслительные процессы у человека. Суть таких вопросов — посмотреть на ситуацию со стороны.
Мне, конечно, немного проще, потому что я ещё и более менее эксперт в айтишечке, но классический коучинг действительно близок к психотерапии по принципу работы (но без копания в причинах), нацеленный на поиск пути к цели.
В статье очень сильно не хватает глубины. Под каждым пунктом 1-6 надо написать, зачем он нужен и почему именно так надо делать. Без этой информации вся статья — список личных рекомендаций основанный ни на чём.
В MS/FB/A/Booking.com — раз в пару недель, это я знаю по личному опыту и опыту друзей. Как в IBM — не знаю, но если раз в полгода, то это не очень правильно
Вообще 1-на-1 надо проводить часто (но раз в неделю по умолчанию — все же перебор). Мой личный дефолт — раз в пару недель, и потом варьирую по уровню необходимости. С кем-то раз в неделю (пока не устаканится и не выйдем на 2 недели), а с кем-то раз в месяц.
Не надо путать 1-на-1 с performance review, который и правда проходит раз в квартал/полгода/год.
Тут мы сейчас должны прояснить терминологию. То, как я понял роль РП — это продукт оунер, иными словами ответственный за продукт. И такой человек действительно не должен напрямую следить за людьми (именно как людми, а не ресурсами на диаграмме Гантта). Для людей есть тимлид.
Если РП — это что-то другое, и в его задачи входит управление людьми тоже, то может тогда тимлид в такой команде и не нужен вовсе.
Конечно. РП отвечает за проект, а не за команду. Поэтому тимлид — очень важная роль в таком сетапе. Он отвечает за людей, за динамику команды, чтобы проект двигался вперёд плавно и слаженно. Ну и чтобы люди были довольны, замотивированы и росли.
Не совсем понятно какую проблему решает? Допустим для TL, как сказано — «он так же как и мы», а для остальных участников?
Примерно ту же — что все мы тут люди, у всех есть свои проблемы. Обнажить уязвимость, чтобы сплотиться на человеческом уровне.
Кажется сомнительным, что явные издевки (тыкание пальцем, откровенные смешки) могут привести к чему-то полезному.
Да, тут я плохо видимо сказал. Суть не в издевках, а в том, чтобы не помогать активно, а дать человеку возможность самому сделать что-то. Но естественно если это какая-то проблема, то тимлид может помочь советом, коучингом (но желательно не решить все за человека, а именно подтолкнуть к решению)
В каком смысле? Если надо что-то сделать в области ответственности другой команды (например, выкатить фичу на страницы соседней команды), то тот, кто собирается это делать (разработчик нашей команды) идет и разговаривает голосом с разработчиком соседней команды (или с их продактом, зависит), и если все согласны, то наш разработчик пишет код и выкатывает (или меняет подход, чтобы все были довольны)
В случае, если наш продукт зависит от разработки соседней команды (что происходит крайне редко), то опять же, говорим голосом, пробуем прийти к общим срокам, эскалируем через ПО если необходимо
почему суровые? это произносится с шуткой, никакого издевательства над животными и в мыслях не было. Да и доля правды в таком подходе есть — зависящее от вас существо (будь то животное или человек) научится гораздо большему сам, чем когда за него сделают всю работу
Это, прямо скажем, очень фиговый фидбек, потому что вообще непонятно, что иммется в виду. Научите своего руководителя модели фидбека SBI или COIN, сразу станет легче и давать и понимать
цель, конечно же, не в карьере. Просто человеку свойственно расти над собой до какого-то момента, и часто бывает так, что на определенной позиции становится "тесно". Вы крутой спец, много умеете, много знаете, хочется большего, потому что есть силы на свершения. И тогда вы растете, переходите на новый уровень карьеры (будь то менеджмент или техническая ветка).
А бывает так, что вы дошли до удобного уровня. Вам нравится ваша работа, вам нравится ваш доход, тогда и рост не нужен. Расти (и растить) из под палки - самая тупая вещь, которую можно себе придумать :)
конечно это не про смену лычки, а про увеличение ответственности на каждом новом уровне. Вот Иван пишет, что синьор работает на уровне команды, Lead на уровне отдела, а Principal - на уровне всей компании. И влияние у этих ролей соотствествующее. Одно дело улучшать один конкретный продукт (или его часть), а другое - участвовать в определении всей технической стратегии компании.
Я тоже работаю в Букинге. У нас рост в Principal – это не про "я чот хочу расти, дайте лычку". Это про "я уже делаю дофига крутых вещей и влияю на континенты, я заслужил". То есть промоушн – это признание заслуг. Но и закрепление за тобой статуса, что после промоушна от тебя ожидаются те же высокие высоты.
Ну смотри. Ученик - student, учитель - teacher. Mentor и mentee - самостоятельные понятия, отличающиеся от обучения (мы кстати про это пытались говорить в этом видео).
Мне самому не очень радует глаз слово менти, и я иногда использую слово ученик в текстах (дабы избегать частого употребления менти), но в то же время хочется быть максимально близко к оригиналу в смыслах, так что почему бы и не внедрить новый термин? Ментор же прижился :)
Оба термина используются тут сознательно. Ментор — потому что так короче, созвучно с доменом и уже достаточно неплохо устоялось в обиходе. При этом я периодически использую слово «наставник» как тождественное (правда есть люди, которые считают будто наставник и ментор это разное, но я не такой).
А вот по поводу менти сложнее. Когда я только запустил сервис, я сразу задумался о том, а каким же словом называть человека, кто обращается за помощью ментора. Первое что приходит на ум — ученик. Но на мой взгляд это не совсем правильно, потому что ментор — не учитель. Подопечный? Возможно, но тоже не совсем корректно, потому что ментор не опекает, он наставляет. Наставляемый? Наиболее близко, но очень длинно и неудобно. Был ещё вариант Телемах, но как-то не пошло :)
Мы долго обсуждали это нашей командой менторов, но в итоге пришли к мнению, что ничего лучше менти пока не подбирается. Но может тут в комментах что-то родится?
Сначала надо стать нашим ментором ;) https://getmentor.dev/bementor
Это сила коммьюнити :) Мы просто кинули ссылку на статью во внутренний чатик менторов и первые плюсы прилетели оттуда
(дисклеймер, я к SkillFactory не имею никакого отношения, кроме того, что мы сделали митап вместе)
Отзывы именно на мою работу есть у меня на сайте (ссылка есть в статье) или вот тут, например https://vas3k.club/post/5877/
Коуч — эксперт в коучинге, то есть в задавании открытых вопросов, которые вызывают мыслительные процессы у человека. Суть таких вопросов — посмотреть на ситуацию со стороны.
Вот, например, как это делаю я:
https://www.youtube.com/watch?v=9r8Znzdc7C0
Мне, конечно, немного проще, потому что я ещё и более менее эксперт в айтишечке, но классический коучинг действительно близок к психотерапии по принципу работы (но без копания в причинах), нацеленный на поиск пути к цели.
В статье очень сильно не хватает глубины. Под каждым пунктом 1-6 надо написать, зачем он нужен и почему именно так надо делать. Без этой информации вся статья — список личных рекомендаций основанный ни на чём.
В MS/FB/A/Booking.com — раз в пару недель, это я знаю по личному опыту и опыту друзей. Как в IBM — не знаю, но если раз в полгода, то это не очень правильно
Вообще 1-на-1 надо проводить часто (но раз в неделю по умолчанию — все же перебор). Мой личный дефолт — раз в пару недель, и потом варьирую по уровню необходимости. С кем-то раз в неделю (пока не устаканится и не выйдем на 2 недели), а с кем-то раз в месяц.
Не надо путать 1-на-1 с performance review, который и правда проходит раз в квартал/полгода/год.
Тут мы сейчас должны прояснить терминологию. То, как я понял роль РП — это продукт оунер, иными словами ответственный за продукт. И такой человек действительно не должен напрямую следить за людьми (именно как людми, а не ресурсами на диаграмме Гантта). Для людей есть тимлид.
Если РП — это что-то другое, и в его задачи входит управление людьми тоже, то может тогда тимлид в такой команде и не нужен вовсе.
Конечно. РП отвечает за проект, а не за команду. Поэтому тимлид — очень важная роль в таком сетапе. Он отвечает за людей, за динамику команды, чтобы проект двигался вперёд плавно и слаженно. Ну и чтобы люди были довольны, замотивированы и росли.
Примерно ту же — что все мы тут люди, у всех есть свои проблемы. Обнажить уязвимость, чтобы сплотиться на человеческом уровне.
Да, тут я плохо видимо сказал. Суть не в издевках, а в том, чтобы не помогать активно, а дать человеку возможность самому сделать что-то. Но естественно если это какая-то проблема, то тимлид может помочь советом, коучингом (но желательно не решить все за человека, а именно подтолкнуть к решению)
В случае, если наш продукт зависит от разработки соседней команды (что происходит крайне редко), то опять же, говорим голосом, пробуем прийти к общим срокам, эскалируем через ПО если необходимо