Привет 👋 Меня зовут Тёма Пулявин, и последние 3 года я — технический директор в каршеринге Ситидрайв.
— «Перейдём на "ты", комфортно будет?» — с этой фразы я начинаю свои вопросы на собеседованиях. Мне привычнее общаться на «ты», поэтому и здесь я буду придерживаться этой практики. Спасибо за понимание 😊
Возможно, мы уже пересекались с тобой, когда я работал в Mail.Ru Group, Alpina Publisher или Mamba.
А может — в одном из многих стартапов, всех и не упомнишь, где я участвовал как engineering manager или даже как founder: Explory, PayText.Ru, FoodFox, Unitemp, FoodMate, Oprosso.
Или ты проходил мой курс по back-end разработке на Otus — или смотрел его в записи. А может, видел меня выступающим на DevConf, «Стачке» или Frontend Conf.
В любом случае, где-то мы с тобой точно пересекались!
За 20 лет в разработке программного обеспечения удалось многое увидеть и во многом разобраться. Всё увиденное и усвоенное я решил упаковывать в последовательные, надеюсь, полезные заметки — и делиться ими здесь.
Буду тебе очень признателен, если ты будешь оставлять реакции — грустно видеть посты без единого emoji. Я даже придумал четырёхбальную систему оценки — интересно, зайдёт ли. Давай попробуем:
Писать буду о том, что точно не оставит равнодушными тимлидов, инженеров, продакт- и проджект-менеджеров.
Ну что, поехали 🚀 Подписывайся!
P.S. На фотографии — я в средней образовательной школе где-то в Бенине.
— «Перейдём на "ты", комфортно будет?» — с этой фразы я начинаю свои вопросы на собеседованиях. Мне привычнее общаться на «ты», поэтому и здесь я буду придерживаться этой практики. Спасибо за понимание 😊
Возможно, мы уже пересекались с тобой, когда я работал в Mail.Ru Group, Alpina Publisher или Mamba.
А может — в одном из многих стартапов, всех и не упомнишь, где я участвовал как engineering manager или даже как founder: Explory, PayText.Ru, FoodFox, Unitemp, FoodMate, Oprosso.
Или ты проходил мой курс по back-end разработке на Otus — или смотрел его в записи. А может, видел меня выступающим на DevConf, «Стачке» или Frontend Conf.
В любом случае, где-то мы с тобой точно пересекались!
За 20 лет в разработке программного обеспечения удалось многое увидеть и во многом разобраться. Всё увиденное и усвоенное я решил упаковывать в последовательные, надеюсь, полезные заметки — и делиться ими здесь.
Буду тебе очень признателен, если ты будешь оставлять реакции — грустно видеть посты без единого emoji. Я даже придумал четырёхбальную систему оценки — интересно, зайдёт ли. Давай попробуем:
😎 — Тема в точку и раскрыта как надо
🤔 — Неплохое чтиво на вечер
🤨 — Мог бы и лучше, уверен
🥴 — Вообще мимо, не зацепило
Писать буду о том, что точно не оставит равнодушными тимлидов, инженеров, продакт- и проджект-менеджеров.
Ну что, поехали 🚀 Подписывайся!
P.S. На фотографии — я в средней образовательной школе где-то в Бенине.
2😎25🤔1
Выгорание подчиненного — это факап его руководителя…
… прочитал как-то тут я на днях в одном из блогов про менеджмент. Мне кажется, нельзя допускать такие однозначные формулировки в такой сложной теме. И вот почему.
Да, конечно и безусловно, руководитель должен максимально изолировать от внешнего хаоса своих подчиненных – собирать на своём управленческом уровне информацию и в понятном, удобоваримом и отфильтрованном виде доносить её до своих подчинённых, чтобы их повседневная деятельность была чуть предсказуемей и когнитивно проще, чем у их руководителя.
Тем не менее, есть масса внешних факторов, где руководитель бессилен, внезависимости от уровня своей руководящей позиции, и никак или крайне слабо может повлиять на не выгорание своих подчинённых, например, это может быть определенный этап в жизни компании, команды или самого сотрудника, который нужно преодолеть или же сложный и приоритетный проект для компании, который непонятно откуда прилетел, в конце концов, выгорать – может быть частью корпоративной культуры!
Но отдельно хочу отметить не такой редкий, как кажется на первый взгляд, фактор – самовыгорание. Существуют такие сотрудники, которые склонны к самоэксплуатации. Да их единицы, но они сразу заметны. Они берут больше, несут дальше, взваливают на себя груз всё тяжелее и тяжелее, даже когда их об этом никто не просит. При этом, пытаются поддерживать высокий уровень требовательности к результату своей деятельности.
И что мы имеем в этом случае? Сделать все дела на свете – невозможно, сделать их к тому же качественно – тем более! Нервная система сотрудника начинает утомляться от такого количества задач, теряется концентрация, работа начинает выполняться некачественно, плодятся ошибки, сотрудник бежит исправлять эти ошибки, исправление ошибок порождает новые ошибки, а тут ещё и нерешённые задачи и на всё это давит высокий уровень требовательности к себе. И в итоге — выгорание.
И пусть ты 100500 раз чуткий руководитель – следишь за нагрузкой сотрудника и не даёшь ему взвалить на себя непосильную ношу, но с такими сотрудниками бывает так – отвернулся ты на часок на обед, а сотрудник уже соседнему отделу пятилетку за три года пообещал выполнить по совместным проектам. Да, ты запрещаешь ему так делать. Да, он тебе не сказал про это, потому что понимает, что ослушался тебя, да и в голове у него уже: «Делов-то на пять минут. Помогу, выручу ребят». И вот теперь сидит пыхтит он в одно лицо и выполняет обещания, и не важно, что у самого свой собственный план задач есть – тут уже ничего не поделаешь, всё равно выгорит.
Полностью контролировать сотрудника, ограничивая каждое его движение, особенно во время твоего обеда — не то, к чему стоит стремиться. Гораздо важнее — развивать в команде зрелую самостоятельность.
И ходят такие сотрудники по рынку, со стабильной регулярностью меняя компании и не понимают, что дело на самом деле может быть в них самих – кто-то успокаивает себя обидой на прошлую компанию, а кто-то даже и не задумывается о причинах.
Что делать руководителю с такими сотрудниками? Прикладывать больше усилий – не выжимать самому из сотрудника максимум, ограничить прямой поход в него сотрудников из смежных отделов и развивать в нём способность осознанно управлять своей нагрузкой. И если он не склонен к самоэксплуатации, то он поймёт, как расставлять приоритеты и держать баланс нагрузки, а если всё безуспешно и твоя поддержка, влияние и развитие не помогло и выгорание всё-таки случилось – то спокойно отпускать и не корить себя факапом.
Отпуская — обязательно нужно проанализировать, почему так произошло. И если ты провожаешь второго такого уникального сотрудника за год — то тут уже всё-таки нужно задуматься о системе, в которой сотрудник оказался или бежать за лотерейным билетом – сегодня тебе везёт!
… прочитал как-то тут я на днях в одном из блогов про менеджмент. Мне кажется, нельзя допускать такие однозначные формулировки в такой сложной теме. И вот почему.
Да, конечно и безусловно, руководитель должен максимально изолировать от внешнего хаоса своих подчиненных – собирать на своём управленческом уровне информацию и в понятном, удобоваримом и отфильтрованном виде доносить её до своих подчинённых, чтобы их повседневная деятельность была чуть предсказуемей и когнитивно проще, чем у их руководителя.
Тем не менее, есть масса внешних факторов, где руководитель бессилен, внезависимости от уровня своей руководящей позиции, и никак или крайне слабо может повлиять на не выгорание своих подчинённых, например, это может быть определенный этап в жизни компании, команды или самого сотрудника, который нужно преодолеть или же сложный и приоритетный проект для компании, который непонятно откуда прилетел, в конце концов, выгорать – может быть частью корпоративной культуры!
Но отдельно хочу отметить не такой редкий, как кажется на первый взгляд, фактор – самовыгорание. Существуют такие сотрудники, которые склонны к самоэксплуатации. Да их единицы, но они сразу заметны. Они берут больше, несут дальше, взваливают на себя груз всё тяжелее и тяжелее, даже когда их об этом никто не просит. При этом, пытаются поддерживать высокий уровень требовательности к результату своей деятельности.
И что мы имеем в этом случае? Сделать все дела на свете – невозможно, сделать их к тому же качественно – тем более! Нервная система сотрудника начинает утомляться от такого количества задач, теряется концентрация, работа начинает выполняться некачественно, плодятся ошибки, сотрудник бежит исправлять эти ошибки, исправление ошибок порождает новые ошибки, а тут ещё и нерешённые задачи и на всё это давит высокий уровень требовательности к себе. И в итоге — выгорание.
И пусть ты 100500 раз чуткий руководитель – следишь за нагрузкой сотрудника и не даёшь ему взвалить на себя непосильную ношу, но с такими сотрудниками бывает так – отвернулся ты на часок на обед, а сотрудник уже соседнему отделу пятилетку за три года пообещал выполнить по совместным проектам. Да, ты запрещаешь ему так делать. Да, он тебе не сказал про это, потому что понимает, что ослушался тебя, да и в голове у него уже: «Делов-то на пять минут. Помогу, выручу ребят». И вот теперь сидит пыхтит он в одно лицо и выполняет обещания, и не важно, что у самого свой собственный план задач есть – тут уже ничего не поделаешь, всё равно выгорит.
Полностью контролировать сотрудника, ограничивая каждое его движение, особенно во время твоего обеда — не то, к чему стоит стремиться. Гораздо важнее — развивать в команде зрелую самостоятельность.
И ходят такие сотрудники по рынку, со стабильной регулярностью меняя компании и не понимают, что дело на самом деле может быть в них самих – кто-то успокаивает себя обидой на прошлую компанию, а кто-то даже и не задумывается о причинах.
Что делать руководителю с такими сотрудниками? Прикладывать больше усилий – не выжимать самому из сотрудника максимум, ограничить прямой поход в него сотрудников из смежных отделов и развивать в нём способность осознанно управлять своей нагрузкой. И если он не склонен к самоэксплуатации, то он поймёт, как расставлять приоритеты и держать баланс нагрузки, а если всё безуспешно и твоя поддержка, влияние и развитие не помогло и выгорание всё-таки случилось – то спокойно отпускать и не корить себя факапом.
Отпуская — обязательно нужно проанализировать, почему так произошло. И если ты провожаешь второго такого уникального сотрудника за год — то тут уже всё-таки нужно задуматься о системе, в которой сотрудник оказался или бежать за лотерейным билетом – сегодня тебе везёт!
52😎10🤔2
Если проблему можно решить деньгами — то это не проблема…
Я думаю, на таком обжигались все. Работает у тебя в команде Серёжа — давно работает, многое сделал полезного, таски закрывает исправно. Но со временем что-то меняется: в глазах Серёжи тускнеет искра, производительность падает — нет уже того энтузиазма и энергии, что раньше. И вот однажды приходит к тебе Серёжа с оффером из другой компании. Проект, по твоим ощущениям, скучнее, позиция мутная, но денег там предложили немного больше.
Ты, недооценив ситуацию, решаешь, что вопрос в деньгах, и легко докидываешь ему сверху — Серёжа успешно удержан, а ты горд собой. Но вот спустя три месяца он снова приходит — и на этот раз уходит не просто из компании, а вообще из ИТ, решил вялить мясо и продавать его в пивбары.
Тут ты уже ничего сделать не можешь: сделал всё, что было в твоих силах — проблема оказалась не в тебе, а в Серёже. И ты с лёгкостью отпускаешь его в этот новый, дивный мир.
Не было такого? А вот у меня — это реальный случай из практики.
Суть здесь в том, что первопричина желания Серёжи уйти была вовсе не в деньгах. Он просто основательно подустал. А ты, по сути, лишь продлил его мучения и довёл до полного выгорания.
Что стоило сделать, когда Серёжа впервые пришёл с оффером? Важно понять, что его до этого состояния довело:
👉 Может, это сложный проект с бесконечным количеством правок, который тянется последний год;
👉 Может, ты недавно повесил на него дополнительную ответственность, и это дало перегруз;
👉 А может, это затяжной эмоциональный конфликт с соседней командой.
Причин может быть множество, и важно её найти. Найди, что именно можно поменять — и как быстро. Обсуди свой план с сотрудником: он должен почувствовать, что ситуация разрешима, и ты готов её решать. Отправь его в отпуск на пару недель, а сам за это время разрули проблему, насколько это возможно.
Если ты правильно определишь и устранишь причину, сотрудник сможет ещё долго и эффективно работать, и всё у вас будет хорошо.
💡 И ещё, пусть даже немного — но подними Серёже зарплату. Это будет для него сигналом, что перемены не только на словах. Это всё равно выйдет дешевле, чем искать нового и учить всему заново.
Конечно, проще всего сказать: «надо просто не допускать таких ситуаций» и следить повнимательнее за тем, как сотрудникам живётся в команде. Но все мы люди, и тут всегда важно находить баланс между автономией и микроменеджментом. Но самое важное – вовремя подхватить.
Я думаю, на таком обжигались все. Работает у тебя в команде Серёжа — давно работает, многое сделал полезного, таски закрывает исправно. Но со временем что-то меняется: в глазах Серёжи тускнеет искра, производительность падает — нет уже того энтузиазма и энергии, что раньше. И вот однажды приходит к тебе Серёжа с оффером из другой компании. Проект, по твоим ощущениям, скучнее, позиция мутная, но денег там предложили немного больше.
Ты, недооценив ситуацию, решаешь, что вопрос в деньгах, и легко докидываешь ему сверху — Серёжа успешно удержан, а ты горд собой. Но вот спустя три месяца он снова приходит — и на этот раз уходит не просто из компании, а вообще из ИТ, решил вялить мясо и продавать его в пивбары.
Тут ты уже ничего сделать не можешь: сделал всё, что было в твоих силах — проблема оказалась не в тебе, а в Серёже. И ты с лёгкостью отпускаешь его в этот новый, дивный мир.
Не было такого? А вот у меня — это реальный случай из практики.
Суть здесь в том, что первопричина желания Серёжи уйти была вовсе не в деньгах. Он просто основательно подустал. А ты, по сути, лишь продлил его мучения и довёл до полного выгорания.
Что стоило сделать, когда Серёжа впервые пришёл с оффером? Важно понять, что его до этого состояния довело:
👉 Может, это сложный проект с бесконечным количеством правок, который тянется последний год;
👉 Может, ты недавно повесил на него дополнительную ответственность, и это дало перегруз;
👉 А может, это затяжной эмоциональный конфликт с соседней командой.
Причин может быть множество, и важно её найти. Найди, что именно можно поменять — и как быстро. Обсуди свой план с сотрудником: он должен почувствовать, что ситуация разрешима, и ты готов её решать. Отправь его в отпуск на пару недель, а сам за это время разрули проблему, насколько это возможно.
Если ты правильно определишь и устранишь причину, сотрудник сможет ещё долго и эффективно работать, и всё у вас будет хорошо.
💡 И ещё, пусть даже немного — но подними Серёже зарплату. Это будет для него сигналом, что перемены не только на словах. Это всё равно выйдет дешевле, чем искать нового и учить всему заново.
Конечно, проще всего сказать: «надо просто не допускать таких ситуаций» и следить повнимательнее за тем, как сотрудникам живётся в команде. Но все мы люди, и тут всегда важно находить баланс между автономией и микроменеджментом. Но самое важное – вовремя подхватить.
😎8
Отпуск — это для слабаков!
«Сделай хобби работой, и тебе больше не придётся работать», — говорили они. В каждой шутке, как известно, лишь доля шутки — всё остальное правда. Но мы не машины с фиксированным набором функций. Даже если ты занят по-настоящему увлекательным и вдохновляющим делом, переключение необходимо. Это помогает мозгу перезагрузиться и взглянуть на привычные задачи под новым углом. Как итог — новые идеи и новый виток вдохновения.
Переключаться можно по-разному – почитать книжку, сходить в спортзал, посмотреть фильм или же погулять по парку. Но важно делать длительные переключения, минимум на неделю, вырывать себя из привычного контекста и уходить в отпуск.
Работая в корпорациях, под высокой нагрузкой, с постоянным переключением контекста и большим потоком задач, которые нужно порешать, я выработал для себя идеальную формулу хождения в отпуск. Я хожу в отпуск минимум 4 раза в год и минимум на неделю. Каждые три месяца я беру дни между праздниками и соединяю их с выходными. Так я получаю ту самую заветную минимум неделю для переключения контекста.
❗️Тут важно понять, что отпуск – это про терапию, а не про хирургическое вмешательство. Нет смысла думать, что месяц отпуска после года работы без передышки может полностью тебя восстановить и исцелить – скорее всего нет. Отпуск надо принимать регулярно по графику небольшими дозами и ни в коем случае не пропускать – только тогда он даёт эффект и предохраняет от выгорания.
💡 Но важно не только следить за выполнением своего графика отпусков, а ещё и своих подчинённых! Если кто-то засиделся и последние полгода в отпуск не ходил — самое время напомнить, насколько это важно, и отправить сотрудника отдыхать.
P.S. На картинке это не галлюцинация AI с третьей рукой — просто cabana boy принёс пинаколаду и скромно ушёл из кадра 🙃
«Сделай хобби работой, и тебе больше не придётся работать», — говорили они. В каждой шутке, как известно, лишь доля шутки — всё остальное правда. Но мы не машины с фиксированным набором функций. Даже если ты занят по-настоящему увлекательным и вдохновляющим делом, переключение необходимо. Это помогает мозгу перезагрузиться и взглянуть на привычные задачи под новым углом. Как итог — новые идеи и новый виток вдохновения.
Переключаться можно по-разному – почитать книжку, сходить в спортзал, посмотреть фильм или же погулять по парку. Но важно делать длительные переключения, минимум на неделю, вырывать себя из привычного контекста и уходить в отпуск.
Работая в корпорациях, под высокой нагрузкой, с постоянным переключением контекста и большим потоком задач, которые нужно порешать, я выработал для себя идеальную формулу хождения в отпуск. Я хожу в отпуск минимум 4 раза в год и минимум на неделю. Каждые три месяца я беру дни между праздниками и соединяю их с выходными. Так я получаю ту самую заветную минимум неделю для переключения контекста.
❗️Тут важно понять, что отпуск – это про терапию, а не про хирургическое вмешательство. Нет смысла думать, что месяц отпуска после года работы без передышки может полностью тебя восстановить и исцелить – скорее всего нет. Отпуск надо принимать регулярно по графику небольшими дозами и ни в коем случае не пропускать – только тогда он даёт эффект и предохраняет от выгорания.
💡 Но важно не только следить за выполнением своего графика отпусков, а ещё и своих подчинённых! Если кто-то засиделся и последние полгода в отпуск не ходил — самое время напомнить, насколько это важно, и отправить сотрудника отдыхать.
P.S. На картинке это не галлюцинация AI с третьей рукой — просто cabana boy принёс пинаколаду и скромно ушёл из кадра 🙃
1😎10
В жизни каждого лида наступает тот самый неожиданный момент, когда приходит HR и говорит: «А напиши-ка список обязанностей к кандидату для новой вакансии разработчика в твою команду».
И часто получается вот такой списочек обязанностей:
🔸Разрабатывать и поддерживать микросервисы на Python 3.x, используя лучшие практики и принципы SOLID, DRY, KISS
🔸Писать чистый, хорошо документированный и тестируемый код
🔸Участвовать в code review, обеспечивая высокое качество кода
🔸Решать задачи по оптимизации производительности и масштабируемости микросервисов
🔸Участвовать в разработке и улучшении архитектуры микросервисов
🔸Вносить свой вклад в создание и улучшение технической документации
🔸Активно участвовать в обсуждениях и принятии технических решений
Вроде всё логично и привычно — ничего особенного. Настолько ничего, что это реальный список обязанностей, который я нашёл в первой же вакансии на HeadHunter. Я лишь выкинул последних пунктов пять, чтобы текст в заметку влез — можете сами найти оригинал, выкинутые пункты только усиливают ту проблему, о которой я дальше расскажу.
Что здесь не так? Давай разбираться.
☝️Во-первых:
Уверен, это далеко не всё, чем предстоит заниматься разработчику на этой позиции. Много внимания уделено хард-скиллам и бесконечному улучшению всего, что есть в сервисе, но ничего не сказано про процессы в команде — будет ли сотрудник грумить задачи, участвовать в планировании и оценке, делать демо? Или вот: код должен быть чистым, документированным и тестируемым — а чтобы он был безопасным с точки зрения ИБ, это разве не нужно? Само собой подразумевается — скажешь ты. ОК, тогда едем дальше.
✌️Во-вторых:
Один и тот же смысл повторяется разными словами в разных пунктах, например:
🔶«Решать задачи по оптимизации производительности и масштабируемости микросервисов»
🔶«Участвовать в разработке и улучшении архитектуры микросервисов»
Или же одно — это просто обобщение другого. Например, выполнение принципов DRY и KISS — это частный случай написания тестируемого кода.
Список обязанностей для вакансии — это лишь один из видов списков, которые тебе предстоит составлять. Есть ещё регламенты, инструкции или тезисы для аргументации расширения найма в команду.
И чтобы все твои списки выглядели убедительно, они должны соответствовать следующим правилам:
👉 Убедись в полноте списка (Collectively Exhaustive) — в нём должно быть всё, чтобы покрыть предмет описания. Если пунктов много — сгруппируй их по логике
👉 Сгруппировал? Теперь проверь, что уровень абстракции и гранулярности у всех пунктов одинаковый — чтобы не вышло что-то вроде: лето, зима, январь, осень
👉 И напоследок — пробегись по списку и убедись, что пункты не пересекаются и не дублируют друг друга (Mutually Exclusive), и что один не является обобщением другого
Эти правила описывают принцип MECE (Mutually Exclusive, Collectively Exhaustive), который был разработан в McKinsey и уже более 50 лет используется консультантами для чёткого и логичного структурирования информации.
❓А твои списки соответствуют принципу MECE?
И часто получается вот такой списочек обязанностей:
🔸Разрабатывать и поддерживать микросервисы на Python 3.x, используя лучшие практики и принципы SOLID, DRY, KISS
🔸Писать чистый, хорошо документированный и тестируемый код
🔸Участвовать в code review, обеспечивая высокое качество кода
🔸Решать задачи по оптимизации производительности и масштабируемости микросервисов
🔸Участвовать в разработке и улучшении архитектуры микросервисов
🔸Вносить свой вклад в создание и улучшение технической документации
🔸Активно участвовать в обсуждениях и принятии технических решений
Вроде всё логично и привычно — ничего особенного. Настолько ничего, что это реальный список обязанностей, который я нашёл в первой же вакансии на HeadHunter. Я лишь выкинул последних пунктов пять, чтобы текст в заметку влез — можете сами найти оригинал, выкинутые пункты только усиливают ту проблему, о которой я дальше расскажу.
Что здесь не так? Давай разбираться.
☝️Во-первых:
Уверен, это далеко не всё, чем предстоит заниматься разработчику на этой позиции. Много внимания уделено хард-скиллам и бесконечному улучшению всего, что есть в сервисе, но ничего не сказано про процессы в команде — будет ли сотрудник грумить задачи, участвовать в планировании и оценке, делать демо? Или вот: код должен быть чистым, документированным и тестируемым — а чтобы он был безопасным с точки зрения ИБ, это разве не нужно? Само собой подразумевается — скажешь ты. ОК, тогда едем дальше.
✌️Во-вторых:
Один и тот же смысл повторяется разными словами в разных пунктах, например:
🔶«Решать задачи по оптимизации производительности и масштабируемости микросервисов»
🔶«Участвовать в разработке и улучшении архитектуры микросервисов»
Или же одно — это просто обобщение другого. Например, выполнение принципов DRY и KISS — это частный случай написания тестируемого кода.
Список обязанностей для вакансии — это лишь один из видов списков, которые тебе предстоит составлять. Есть ещё регламенты, инструкции или тезисы для аргументации расширения найма в команду.
И чтобы все твои списки выглядели убедительно, они должны соответствовать следующим правилам:
👉 Убедись в полноте списка (Collectively Exhaustive) — в нём должно быть всё, чтобы покрыть предмет описания. Если пунктов много — сгруппируй их по логике
👉 Сгруппировал? Теперь проверь, что уровень абстракции и гранулярности у всех пунктов одинаковый — чтобы не вышло что-то вроде: лето, зима, январь, осень
👉 И напоследок — пробегись по списку и убедись, что пункты не пересекаются и не дублируют друг друга (Mutually Exclusive), и что один не является обобщением другого
Эти правила описывают принцип MECE (Mutually Exclusive, Collectively Exhaustive), который был разработан в McKinsey и уже более 50 лет используется консультантами для чёткого и логичного структурирования информации.
❓А твои списки соответствуют принципу MECE?
2😎5🤔2
О чём говорить с сотрудником на one-on-one?
Да о чём угодно, серьёзно! О спорте, рыбалке, прочитанной книге на выходных или о финансовых показателях компании за последний квартал. 1:1 — это ещё один инструмент в арсенале руководителя, и каждый сам решает, как именно его использовать.
На самом деле важно не то, о чём ты говоришь с сотрудником, а то, как ты адаптируешь встречу под конкретного человека и что полезного она даёт вам обоим.
Если, к примеру, сотрудник заинтересован в твоём менторстве, опыте и росте, а ты каждый раз рассказываешь, как прошёл очередной уровень в Split Fiction, при этом не вникая в его рабочие проблемы и тревоги — всё это прямая дорога к его демотивации. Как следствие — выгорание, конфликты, уход.
Где-то встречал мысль, что идеальное распределение на 1:1 — это когда 30% времени говорит менеджер, а 70% — сотрудник. Тут всё индивидуально и зависит от самого сотрудника, его уровня зрелости и текущей ситуации:
☝️ Иногда сотруднику нужно просто выговориться — тогда у него 100%, у тебя 0%
✌️ Иногда сотрудник приходит со списком вопросов — и ты в ответ говоришь 90% времени
🤟 А бывает, обсуждаете что-то по-партнёрски — 50% на 50%
Но если все ваши 1:1 проходят в формате, где ты непрерывно говоришь, а сотрудник только кивает — это тревожный сигнал. Твоя задача — понять, что происходит, а не просто делиться своим мнением. Дай сотруднику пространство, не перебивай, не спеши “лечить” советами.
💡И главное — не бойся тишины.
Один из моих бывших руководителей как-то сказал: «Для взрослых людей молчание — это тоже разговор». Твоя задача — услышать сотрудника, ведь чем больше говоришь ты, тем меньше раскрывается он. Если сотрудник задал вопрос — не спеши с ответом, возьми паузу. Если он задумался — не заполняй тишину своим комментарием. Используй паузу как инструмент — пусть он сам её заполнит.
Свои 1:1 я всегда начинаю с вопроса: «Привет! Как настрой, какие новости?», давая сотруднику полную свободу выговориться в свободной форме, а сам в это время слушаю, фиксирую уточняющие вопросы и задаю их только после того, как он полностью выскажется — не перебивая.
❗️Помни, сотруднику важно твоё личное внимание, оценка его работы и мнение по событиям в команде или компании, но не занимай всё пространство собой — встреча не про то какой ты классный 🙃
Да о чём угодно, серьёзно! О спорте, рыбалке, прочитанной книге на выходных или о финансовых показателях компании за последний квартал. 1:1 — это ещё один инструмент в арсенале руководителя, и каждый сам решает, как именно его использовать.
На самом деле важно не то, о чём ты говоришь с сотрудником, а то, как ты адаптируешь встречу под конкретного человека и что полезного она даёт вам обоим.
Если, к примеру, сотрудник заинтересован в твоём менторстве, опыте и росте, а ты каждый раз рассказываешь, как прошёл очередной уровень в Split Fiction, при этом не вникая в его рабочие проблемы и тревоги — всё это прямая дорога к его демотивации. Как следствие — выгорание, конфликты, уход.
Где-то встречал мысль, что идеальное распределение на 1:1 — это когда 30% времени говорит менеджер, а 70% — сотрудник. Тут всё индивидуально и зависит от самого сотрудника, его уровня зрелости и текущей ситуации:
☝️ Иногда сотруднику нужно просто выговориться — тогда у него 100%, у тебя 0%
✌️ Иногда сотрудник приходит со списком вопросов — и ты в ответ говоришь 90% времени
🤟 А бывает, обсуждаете что-то по-партнёрски — 50% на 50%
Но если все ваши 1:1 проходят в формате, где ты непрерывно говоришь, а сотрудник только кивает — это тревожный сигнал. Твоя задача — понять, что происходит, а не просто делиться своим мнением. Дай сотруднику пространство, не перебивай, не спеши “лечить” советами.
💡И главное — не бойся тишины.
Один из моих бывших руководителей как-то сказал: «Для взрослых людей молчание — это тоже разговор». Твоя задача — услышать сотрудника, ведь чем больше говоришь ты, тем меньше раскрывается он. Если сотрудник задал вопрос — не спеши с ответом, возьми паузу. Если он задумался — не заполняй тишину своим комментарием. Используй паузу как инструмент — пусть он сам её заполнит.
Свои 1:1 я всегда начинаю с вопроса: «Привет! Как настрой, какие новости?», давая сотруднику полную свободу выговориться в свободной форме, а сам в это время слушаю, фиксирую уточняющие вопросы и задаю их только после того, как он полностью выскажется — не перебивая.
❗️Помни, сотруднику важно твоё личное внимание, оценка его работы и мнение по событиям в команде или компании, но не занимай всё пространство собой — встреча не про то какой ты классный 🙃
2😎6
Не забывай хвалить сотрудников
Причём сразу — не жди 1-2-1, ревью или какой-то другой формальной встречи.
Похвала — это про обучение, а не про мотивацию. Она даёт понять, что для тебя важно как для руководителя, и показывает сотруднику, что он движется в нужном направлении.
Хуже всего — подвешенные сотрудники, которые вообще не получают никакой обратной связи. Это как самурай без цели — путь вроде бы есть, но куда он ведёт — непонятно. Но раз ты читаешь эту заметку — твои сотрудники точно не самураи. Им важно понимать, куда они идут. А без понимания — выгорание, конфликты и в итоге — уход.
А если хвалить не за что?
Ну тогда у меня к тебе, как к руководителю, вопросики. Особенно если этих людей ты сам нашёл и нанял. Они делают свою работу, но не дают повода для похвалы и ты при этом ничего не предпринимаешь, чтобы их развить или заменить?
Начни хотя бы с пересмотра своих ожиданий от них. Поверь, фича, которая вовремя уехала в прод без инцидентов — это уже вполне себе повод для похвалы.
Поэтому,
👉 если тебе важно, чтобы сотрудники проявляли инициативу — и кто-то её проявил, похвали
👉 если тебе важно, чтобы в команде помогали друг другу — и кто-то помог, похвали
👉 если сотрудник нашёл элегантное решение проблемы — скажи, что это именно тот уровень, который ты хочешь видеть
Но⚡️Важно не просто отправить эмоджи сердечка в мессенджере или похлопать рукою по плечу — важно объяснить, за что именно ты хвалишь и почему это важно: тебе лично, команде или компании в целом.
Обычные фразы вроде «Круто, молодец!» или «Супер, так держать!» — не говорят, что именно было сделано хорошо, и не дают сотруднику ориентира, чтобы он мог повторить этот успех снова.
Так, а как хвалить? Да как тебе удобно:
👉 можешь — публично, а можешь — приватно, на 1-2-1
👉 можешь — написать в мессенджере, а можешь — проговорить голосом
Тут я большой разницы не вижу — главное, чтобы суть была донесена.
Единственное — будь осторожен с публичной похвалой.
Тут важно учитывать два момента:
👉 есть сотрудники, которые не любят избыточного публичного внимания, и для них публичная похвала — это стресс. В таких ситуациях человек в следующий раз может сознательно избегать проявления инициативы, лишь бы снова не попасть под свет софитов твоей похвалы
👉 выделяя вклад одного сотрудника, убедись, что этим ты не обесцениваешь вклад другого. Кто-то из команды может посчитать, что поработал не хуже, а может и лучше, чем тот, кого ты хвалишь — и в итоге затаит обиду, потому что его не заметили и он не получил ни внимания, ни похвалы.
Так что, если видишь риск хотя бы по одному из этих пунктов — лучше перенеси похвалу в приват.
💡И последнее — чем младше должность сотрудника, тем чаще его нужно хвалить, потому что он ещё мало что понимает и ему особенно нужна поддержка и чёткий ориентир с понятной причинно-следственной связью: сделал шаг в правильном направлении — похвалил, сделал в неправильном — поругал.
❓А ты хвалишь своих сотрудников?
Причём сразу — не жди 1-2-1, ревью или какой-то другой формальной встречи.
Похвала — это про обучение, а не про мотивацию. Она даёт понять, что для тебя важно как для руководителя, и показывает сотруднику, что он движется в нужном направлении.
Хуже всего — подвешенные сотрудники, которые вообще не получают никакой обратной связи. Это как самурай без цели — путь вроде бы есть, но куда он ведёт — непонятно. Но раз ты читаешь эту заметку — твои сотрудники точно не самураи. Им важно понимать, куда они идут. А без понимания — выгорание, конфликты и в итоге — уход.
А если хвалить не за что?
Ну тогда у меня к тебе, как к руководителю, вопросики. Особенно если этих людей ты сам нашёл и нанял. Они делают свою работу, но не дают повода для похвалы и ты при этом ничего не предпринимаешь, чтобы их развить или заменить?
Начни хотя бы с пересмотра своих ожиданий от них. Поверь, фича, которая вовремя уехала в прод без инцидентов — это уже вполне себе повод для похвалы.
Поэтому,
👉 если тебе важно, чтобы сотрудники проявляли инициативу — и кто-то её проявил, похвали
👉 если тебе важно, чтобы в команде помогали друг другу — и кто-то помог, похвали
👉 если сотрудник нашёл элегантное решение проблемы — скажи, что это именно тот уровень, который ты хочешь видеть
Но⚡️Важно не просто отправить эмоджи сердечка в мессенджере или похлопать рукою по плечу — важно объяснить, за что именно ты хвалишь и почему это важно: тебе лично, команде или компании в целом.
Обычные фразы вроде «Круто, молодец!» или «Супер, так держать!» — не говорят, что именно было сделано хорошо, и не дают сотруднику ориентира, чтобы он мог повторить этот успех снова.
Так, а как хвалить? Да как тебе удобно:
👉 можешь — публично, а можешь — приватно, на 1-2-1
👉 можешь — написать в мессенджере, а можешь — проговорить голосом
Тут я большой разницы не вижу — главное, чтобы суть была донесена.
Единственное — будь осторожен с публичной похвалой.
Тут важно учитывать два момента:
👉 есть сотрудники, которые не любят избыточного публичного внимания, и для них публичная похвала — это стресс. В таких ситуациях человек в следующий раз может сознательно избегать проявления инициативы, лишь бы снова не попасть под свет софитов твоей похвалы
👉 выделяя вклад одного сотрудника, убедись, что этим ты не обесцениваешь вклад другого. Кто-то из команды может посчитать, что поработал не хуже, а может и лучше, чем тот, кого ты хвалишь — и в итоге затаит обиду, потому что его не заметили и он не получил ни внимания, ни похвалы.
Так что, если видишь риск хотя бы по одному из этих пунктов — лучше перенеси похвалу в приват.
💡И последнее — чем младше должность сотрудника, тем чаще его нужно хвалить, потому что он ещё мало что понимает и ему особенно нужна поддержка и чёткий ориентир с понятной причинно-следственной связью: сделал шаг в правильном направлении — похвалил, сделал в неправильном — поругал.
❓А ты хвалишь своих сотрудников?
2😎8
Красивая теория печальной реальности Story Points
Оценка задач — это всегда больная тема в командах. Тут нет серебряной пули: каждая команда со временем эволюционно приходит к чему-то своему. И начинают обычно с чего-то светлого и хорошего — с оценки не времени, а сложности задач, как это и задумано в story points.
Как это обычно происходит?
Команда начинает делать задачи без оценок. Через пару спринтов появляются первые «эталонные» задачи — те, которые понятны по составу, объёму и рискам. Таких задач набирается штук 5–7. Они сортируются по сложности по возрастанию: первой присваивается сложность 1 story point, второй — 2, и так далее, например, до 7.
Чтобы не возник соблазн сравнивать задачи арифметически (мол, «эта в два раза сложнее, чем та»), берут последовательность Фибоначчи: 1, 2, 3, 5, 8, 13, 21…
То есть первая задача получит 1 SP, вторая — 2, третья — 3, потом 5, 8 и т.д.
Дальше перед каждым спринтом команда оценивает новые задачи по этой шкале — с помощью Planning Poker, Bucket System или просто когда тимлид включает Expert Judgment и сам проставляет оценки.
В чём проблема?
Во-первых ☝️ высокая стоимость входа. Нужно минимум 3–5 спринтов, чтобы наработать список эталонов и начать по ним нормально оцениваться.
Во-вторых ✌️ оценка неуниверсальна. В одной команде «5 SP» — это одно, в другой — совсем другое. А если две команды совместно реализуют мета-фичу, продактам приходится ломать голову, как вообще выстроить общий релизный роадмап.
Получается примерно как в истории с Mars Climate Orbiter, когда NASA поручила компании Lockheed Martin разработку софта и ожидала, что конфигуратор будет работать в метрических единицах (ньютон-секунды), а Lockheed сделала всё в имперских (фунты-секунды). NASA настроила аппарат, запустила — и тот вошёл в атмосферу Марса слишком низко. В итоге 125 миллионов долларов налогоплательщиков сгорели в марсианском небе.
Но самая главная проблема — story points требуют регулярного обслуживания. Со временем эталонные задачи устаревают:
👉 технологии и подходы изменились — эталонные задачи стало делать проще
👉 состав команды меняется — никто уже не помнит, почему у той задачи было «8 SP»
👉 проект или доменная область команды меняются, и старые эталонные задачи уже оказываются неактуальными для новых реалий, а команда продолжает сравнивать текущие «красные» задачи с «тёплыми» задачами из прошлого
И вот тут включается лень — и долина смерти команд, которые забили на ревизию и обслуживание своей системы оценки story points, продолжает пополняться.
В худшем случае команда не делает ничего, и оценка с планированием скатываются в бардак и хаос: задачи оцениваются по нерелевантной шкале, команда ни во что не попадает, движется по инерции — и вроде бы всех всё устраивает.
В лучшем случае команда пытается что-то с этим сделать: провести ревизию, как-то упростить или адаптировать систему, и, например, приходит к самому частому сценарию — когда говорят, мол, story point — это типа идеальный день разработчика. Если задача тянет на три таких идеальных дня, то и оценка ей «3 SP». Узнали себя?
Как жить в такой ситуации? Да никак. Каждая команда находит свой «уникальный» и невоспроизводимый путь, адаптируя оценку под свои реалии.
❗️ Самое главное — не врать себе, что твоя команда продолжает оценивать именно сложность задач в story points. Потому что чаще всего — вы просто оцениваете время. Но делаете вид, что нет.
Оценка задач — это всегда больная тема в командах. Тут нет серебряной пули: каждая команда со временем эволюционно приходит к чему-то своему. И начинают обычно с чего-то светлого и хорошего — с оценки не времени, а сложности задач, как это и задумано в story points.
Как это обычно происходит?
Команда начинает делать задачи без оценок. Через пару спринтов появляются первые «эталонные» задачи — те, которые понятны по составу, объёму и рискам. Таких задач набирается штук 5–7. Они сортируются по сложности по возрастанию: первой присваивается сложность 1 story point, второй — 2, и так далее, например, до 7.
Чтобы не возник соблазн сравнивать задачи арифметически (мол, «эта в два раза сложнее, чем та»), берут последовательность Фибоначчи: 1, 2, 3, 5, 8, 13, 21…
То есть первая задача получит 1 SP, вторая — 2, третья — 3, потом 5, 8 и т.д.
Дальше перед каждым спринтом команда оценивает новые задачи по этой шкале — с помощью Planning Poker, Bucket System или просто когда тимлид включает Expert Judgment и сам проставляет оценки.
В чём проблема?
Во-первых ☝️ высокая стоимость входа. Нужно минимум 3–5 спринтов, чтобы наработать список эталонов и начать по ним нормально оцениваться.
Во-вторых ✌️ оценка неуниверсальна. В одной команде «5 SP» — это одно, в другой — совсем другое. А если две команды совместно реализуют мета-фичу, продактам приходится ломать голову, как вообще выстроить общий релизный роадмап.
Получается примерно как в истории с Mars Climate Orbiter, когда NASA поручила компании Lockheed Martin разработку софта и ожидала, что конфигуратор будет работать в метрических единицах (ньютон-секунды), а Lockheed сделала всё в имперских (фунты-секунды). NASA настроила аппарат, запустила — и тот вошёл в атмосферу Марса слишком низко. В итоге 125 миллионов долларов налогоплательщиков сгорели в марсианском небе.
Но самая главная проблема — story points требуют регулярного обслуживания. Со временем эталонные задачи устаревают:
👉 технологии и подходы изменились — эталонные задачи стало делать проще
👉 состав команды меняется — никто уже не помнит, почему у той задачи было «8 SP»
👉 проект или доменная область команды меняются, и старые эталонные задачи уже оказываются неактуальными для новых реалий, а команда продолжает сравнивать текущие «красные» задачи с «тёплыми» задачами из прошлого
И вот тут включается лень — и долина смерти команд, которые забили на ревизию и обслуживание своей системы оценки story points, продолжает пополняться.
В худшем случае команда не делает ничего, и оценка с планированием скатываются в бардак и хаос: задачи оцениваются по нерелевантной шкале, команда ни во что не попадает, движется по инерции — и вроде бы всех всё устраивает.
В лучшем случае команда пытается что-то с этим сделать: провести ревизию, как-то упростить или адаптировать систему, и, например, приходит к самому частому сценарию — когда говорят, мол, story point — это типа идеальный день разработчика. Если задача тянет на три таких идеальных дня, то и оценка ей «3 SP». Узнали себя?
Как жить в такой ситуации? Да никак. Каждая команда находит свой «уникальный» и невоспроизводимый путь, адаптируя оценку под свои реалии.
❗️ Самое главное — не врать себе, что твоя команда продолжает оценивать именно сложность задач в story points. Потому что чаще всего — вы просто оцениваете время. Но делаете вид, что нет.
2😎5🥴1🤨1
Это, наконец-то свершилось — завтра в твою команду выходит новый сотрудник!
Ты долго его искал, провёл кучу собеседований, продавал оффер, и вот — завтра день выхода. Ты уже представляешь, как он возьмёт на себя часть задач по текущему проекту, разгрузит тебя и других ребят в команде.
Но то, насколько быстро он вольётся в команду, станет боевой единицей, включится в рабочий процесс и начнёт приносить пользу — зависит от тебя и того онбординга, который ты для него подготовил.
☝️ Первое, что нужно сделать до выхода сотрудника — подготовить список задач, которые он должен закрыть за испытательный срок. Определи, какие из них критичные — то есть обязательные, а какие nice to have — будет здорово, если он успеет сделать и их. Для себя пойми, что именно ты считаешь успешным выполнением этих задач. Продумай, как ты будешь проверять результат, по каким критериям и как в целом будешь оценивать его работу по итогам испытательного срока. Всё это ты будешь обсуждать с новичком — это и станут его целями на период испытательного срока. И если тебе всё понятно, важно сделать, чтобы и новичку было прозрачно: чётко объясни, что от него ожидается и по каким критериям ты будешь оценивать успешность его адаптации.
Во-вторых ✌️ выбери кого-то из своей команды в качестве бадди для новичка. Если ты ставишь задачи и проверяешь их выполнение, то нужен ещё один человек, который будет помогать новичку эти задачи выполнять. Бадди должен выстроить с новичком партнёрские отношения, быть с ним на равных, создать неформальный контакт и стать «своим человеком» — тем, кто поддерживает, объясняет, направляет. Это сделает процесс вливания в команду более мягким и понятным. Роль бадди помогает расти текущим сотрудникам и разгружает тебя как тимлида.
И в-третьих 🤟 и это самое главное — регулярно собирай фидбек на новичка от всех сотрудников, с кем он взаимодействует по рабочим задачам, и обязательно передавай этот фидбек новичку. Важно провести минимум две встречи за время испытательного срока, на которых ты дашь ему обратную связь.
❗️ Почему это важно? Пришедший к тебе новичок уже имеет определённый опыт, сформированный в предыдущих компаниях — вместе с ним он приносит свои поведенческие паттерны и подходы к работе. В тех компаниях была своя культура и свои процессы, которые могут сильно отличаться от ваших. Это не значит, что человек «не подходит» — он просто действует так, как его научили раньше. Твоя задача — помочь ему адаптироваться и перестроиться под вашу культуру и ожидания. И чем раньше ты это сделаешь, тем быстрее он поймёт, что от него требуется, как у вас принято работать, и начнёт приносить пользу.
💡 Поэтому важно собирать фидбек от всех, с кем он взаимодействует, и передавать ему агрегированную обратную связь: где его поведение и подход соответствуют ожиданиям команды, а где — нет. Объясняй, какие его действия и реакции вписываются в вашу культуру, а какие расходятся с тем, как принято у вас.
Очень хотел в этой заметке рассказать, через какие этапы онбординга проходят новички в моих командах, но это уже тема для отдельной заметки — stay tuned 🙃
Ты долго его искал, провёл кучу собеседований, продавал оффер, и вот — завтра день выхода. Ты уже представляешь, как он возьмёт на себя часть задач по текущему проекту, разгрузит тебя и других ребят в команде.
Но то, насколько быстро он вольётся в команду, станет боевой единицей, включится в рабочий процесс и начнёт приносить пользу — зависит от тебя и того онбординга, который ты для него подготовил.
☝️ Первое, что нужно сделать до выхода сотрудника — подготовить список задач, которые он должен закрыть за испытательный срок. Определи, какие из них критичные — то есть обязательные, а какие nice to have — будет здорово, если он успеет сделать и их. Для себя пойми, что именно ты считаешь успешным выполнением этих задач. Продумай, как ты будешь проверять результат, по каким критериям и как в целом будешь оценивать его работу по итогам испытательного срока. Всё это ты будешь обсуждать с новичком — это и станут его целями на период испытательного срока. И если тебе всё понятно, важно сделать, чтобы и новичку было прозрачно: чётко объясни, что от него ожидается и по каким критериям ты будешь оценивать успешность его адаптации.
Во-вторых ✌️ выбери кого-то из своей команды в качестве бадди для новичка. Если ты ставишь задачи и проверяешь их выполнение, то нужен ещё один человек, который будет помогать новичку эти задачи выполнять. Бадди должен выстроить с новичком партнёрские отношения, быть с ним на равных, создать неформальный контакт и стать «своим человеком» — тем, кто поддерживает, объясняет, направляет. Это сделает процесс вливания в команду более мягким и понятным. Роль бадди помогает расти текущим сотрудникам и разгружает тебя как тимлида.
И в-третьих 🤟 и это самое главное — регулярно собирай фидбек на новичка от всех сотрудников, с кем он взаимодействует по рабочим задачам, и обязательно передавай этот фидбек новичку. Важно провести минимум две встречи за время испытательного срока, на которых ты дашь ему обратную связь.
❗️ Почему это важно? Пришедший к тебе новичок уже имеет определённый опыт, сформированный в предыдущих компаниях — вместе с ним он приносит свои поведенческие паттерны и подходы к работе. В тех компаниях была своя культура и свои процессы, которые могут сильно отличаться от ваших. Это не значит, что человек «не подходит» — он просто действует так, как его научили раньше. Твоя задача — помочь ему адаптироваться и перестроиться под вашу культуру и ожидания. И чем раньше ты это сделаешь, тем быстрее он поймёт, что от него требуется, как у вас принято работать, и начнёт приносить пользу.
💡 Поэтому важно собирать фидбек от всех, с кем он взаимодействует, и передавать ему агрегированную обратную связь: где его поведение и подход соответствуют ожиданиям команды, а где — нет. Объясняй, какие его действия и реакции вписываются в вашу культуру, а какие расходятся с тем, как принято у вас.
Очень хотел в этой заметке рассказать, через какие этапы онбординга проходят новички в моих командах, но это уже тема для отдельной заметки — stay tuned 🙃
2😎8
Уверен, ты — как и любой руководитель, который ищет нового человека в команду — хочешь, чтобы новый сотрудник оказался ответственным, проактивным, инициативным, не упрямым, зрелым, честным и умел работать в команде.
Но как понять, таков ли он, за собеседование длиной в час? Спросить!
Серьёзно, просто спросить. Только не в лоб, конечно.
Во-первых, даже если перед тобой самый нечестный человек на свете, он всё равно скажет, что он — самый честный. И не потому, что соврёт, а потому что в его внутренней системе координат всё, что он делает, — честно. Он в это действительно верит.
Ты когда-нибудь себе признавался в нечестности или безответственности? Нет? Вот и он тоже — нет 🙃
Во-вторых, нет абсолютной честности или безответственности — есть градации и оттенки. То, что для кандидата «честно», для тебя может показаться излишней прямотой, граничащей с грубостью. Поэтому спрашивать об этом и трактовать ответы нужно особым образом.
Как спрашивать?
Не надо придумывать гипотетические ситуации и просить кандидата представить, как бы он себя повёл. Пользы в этом мало. Например, если ты хочешь проверить результативность, то антипаттерн — это вопрос вроде:
👎 «Представь, ты делаешь важный проект, не укладываешься в сроки — что ты будешь делать?»
Спроси иначе:
👍 «Была ли у тебя ситуация, когда ты не укладывался в сроки? Что ты тогда сделал?»
Или ты хочешь проверить умение работать с конфликтами, и спрашиваешь:
👎 «Представь, ты не согласен с решением своего руководителя — как ты дашь ему фидбэк?»
Лучше спросить так:
👍 «Как ты строил работу со своим руководителем на прошлом месте? Были ли случаи, когда ты был не согласен с его решением? Расскажи о самой запомнившейся ситуации»
И тут уже сложнее придумать «правильный» ответ. Кандидат не сможет просто повторить заученное из методички. А если и попытается юлить — копни глубже. Спроси ещё пару раз по-другому. Скорее всего, он всё расскажет.
А если у него в принципе нет таких кейсов — это тоже сигнал 🧐 Например, странно слышать, что фронтенд-разработчик с 5+ годами стажа ни разу не конфликтовал с бэкендом из-за API.
А дальше слушай внимательно. Задавайте уточняющие вопросы. Копай глубже, пока у тебя в голове не сложится полное понимание, как кандидат ведёт себя в конкретных ситуациях.
Важно ☝️ не направляй его к «нужному» тебе ответу. Лучше держи паузу — дай человеку вспомнить, как всё было на самом деле. И не торопи. Этот метод — не про стресс. Тут наоборот — важно создать доверительную атмосферу, чтобы кандидат раскрылся. Это должно быть больше похоже на диалог, чем на допрос.
Такой способ общения с кандидатом называется поведенческим интервью.
Чтобы метод сработал, нужно заранее определить ключевые компетенции, которые ты хочешь проверить. Не пытайся охватить всё — 3–4 компетенции за интервью вполне достаточно. Иначе оно превратится в опросник по чек-листу, и это точно не будет похоже на живой разговор.
А ещё важно выбрать подходящую методику интервью. Их много разных, например: STAR, SOAR или DARE. У всех есть нюансы — в зависимости от того, какую сторону кандидата ты хочешь раскрыть. Я лично использую STAR — она универсальна и хорошо работает. В следующих заметках обязательно расскажу про неё и какие компетенции я через неё проверяю на своих собеседованиях.
❗️И не попади в ловушку. Поведенческое интервью строится на предположении, что прошлое поведение человека предсказывает его будущее поведение. Это в целом верно. Но люди — не статичны. Мы учимся, развиваемся и меняемся. Тот кейс, о котором кандидат рассказывает, может быть для него не провалом, а точкой роста. Он мог вынести из него опыт, стал мудрее, и в следующий раз поведёт себя иначе.
Но как понять, таков ли он, за собеседование длиной в час? Спросить!
Серьёзно, просто спросить. Только не в лоб, конечно.
Во-первых, даже если перед тобой самый нечестный человек на свете, он всё равно скажет, что он — самый честный. И не потому, что соврёт, а потому что в его внутренней системе координат всё, что он делает, — честно. Он в это действительно верит.
Ты когда-нибудь себе признавался в нечестности или безответственности? Нет? Вот и он тоже — нет 🙃
Во-вторых, нет абсолютной честности или безответственности — есть градации и оттенки. То, что для кандидата «честно», для тебя может показаться излишней прямотой, граничащей с грубостью. Поэтому спрашивать об этом и трактовать ответы нужно особым образом.
Как спрашивать?
Не надо придумывать гипотетические ситуации и просить кандидата представить, как бы он себя повёл. Пользы в этом мало. Например, если ты хочешь проверить результативность, то антипаттерн — это вопрос вроде:
👎 «Представь, ты делаешь важный проект, не укладываешься в сроки — что ты будешь делать?»
Спроси иначе:
👍 «Была ли у тебя ситуация, когда ты не укладывался в сроки? Что ты тогда сделал?»
Или ты хочешь проверить умение работать с конфликтами, и спрашиваешь:
👎 «Представь, ты не согласен с решением своего руководителя — как ты дашь ему фидбэк?»
Лучше спросить так:
👍 «Как ты строил работу со своим руководителем на прошлом месте? Были ли случаи, когда ты был не согласен с его решением? Расскажи о самой запомнившейся ситуации»
И тут уже сложнее придумать «правильный» ответ. Кандидат не сможет просто повторить заученное из методички. А если и попытается юлить — копни глубже. Спроси ещё пару раз по-другому. Скорее всего, он всё расскажет.
А если у него в принципе нет таких кейсов — это тоже сигнал 🧐 Например, странно слышать, что фронтенд-разработчик с 5+ годами стажа ни разу не конфликтовал с бэкендом из-за API.
А дальше слушай внимательно. Задавайте уточняющие вопросы. Копай глубже, пока у тебя в голове не сложится полное понимание, как кандидат ведёт себя в конкретных ситуациях.
Важно ☝️ не направляй его к «нужному» тебе ответу. Лучше держи паузу — дай человеку вспомнить, как всё было на самом деле. И не торопи. Этот метод — не про стресс. Тут наоборот — важно создать доверительную атмосферу, чтобы кандидат раскрылся. Это должно быть больше похоже на диалог, чем на допрос.
Такой способ общения с кандидатом называется поведенческим интервью.
Чтобы метод сработал, нужно заранее определить ключевые компетенции, которые ты хочешь проверить. Не пытайся охватить всё — 3–4 компетенции за интервью вполне достаточно. Иначе оно превратится в опросник по чек-листу, и это точно не будет похоже на живой разговор.
А ещё важно выбрать подходящую методику интервью. Их много разных, например: STAR, SOAR или DARE. У всех есть нюансы — в зависимости от того, какую сторону кандидата ты хочешь раскрыть. Я лично использую STAR — она универсальна и хорошо работает. В следующих заметках обязательно расскажу про неё и какие компетенции я через неё проверяю на своих собеседованиях.
❗️И не попади в ловушку. Поведенческое интервью строится на предположении, что прошлое поведение человека предсказывает его будущее поведение. Это в целом верно. Но люди — не статичны. Мы учимся, развиваемся и меняемся. Тот кейс, о котором кандидат рассказывает, может быть для него не провалом, а точкой роста. Он мог вынести из него опыт, стал мудрее, и в следующий раз поведёт себя иначе.
2😎16🤔1