ПРО УВОЛЬНЕНИЯ #1
Давайте сегодня поговорим о самой неприятной задаче менеджера – об увольнениях.
Увольнять сложно. И я не встречал людей, которые бы получали от этого процесса удовольствие или заряд энергии. Чаще всего, наоборот, требуется потом время, чтобы прийти в себя и вернуться к работе.
Почему так? Виной всему наш мозг и психика. Руководитель – он же для чего? Он про бизнес, достигать целей компании, добиваться результатов. И с этой точки зрения, любое увольнение – просто задача. Специфическая, но задача. Ни больше, ни меньше.
И все бы ничего, но мы люди. Все руководители! И ни одному человеку (если он здоров) не хочется причинять боль и страдания другому человеку. А увольнение для сотрудника – это то самое и есть, как минимум хороший такой выход из зоны комфорта. Поэтому вторая наша половина хочет избежать такой задачи всеми силами.
Вот и получается внутренняя шизофрения – внутри борются менеджер и человек. Кто победит?
Чаще всего, человек побеждает ровно столько, сколько может это делать. Все время пытаешься оправдать сотрудника, дать ему второй-третий-двадцатый шанс. Еще мое любимое – копаешься в себе и ищешь причину там. Вроде как “это не сотрудник делает фигню, а это я ему недостаточно качественно задачу разжевал”. Ну и т п.
А потом человек сдается. Либо когда уже “ну все, хватит это терпеть”, либо когда просто все попытки исчерпаны и менеджер внутри победил. И в этот самый момент наступает точка принятия решения – “все, увольняю”.
Но принять решение мало, надо еще и реализовать. Хотя, сказать по чести, сложнее решиться, нежели поговорить с сотрудником. Ну во всяком случае, про себя могу так сказать.
Чтобы победить этот внутренний конфликт менеджера и человека в своей голове, в определенный момент я придумал для себя некую мантру, которую с радостью всем рассказываю. Вдруг кому-то тоже подойдет.
“Принимать решение об увольнении нужно как менеджер, а реализовывать его – как человек”.
Иными словами, решение должно базироваться исключительно на интересах бизнеса. И все эмоциональные аспекты здесь нужно отключать. А уже потом, когда решение принято, нужно включить в себе человека, и сделать все так, чтобы ваш сотрудник не страдал и не печалился.
Во-первых, нормально и по-человечески с ним поговорить и все объяснить. Без казенщины и бюрократщины. Во-вторых, предложить помочь: рекомендации, контакты и т п. В-третьих, быть честным, не пытаться сэкономить навариться на этом. И в-четвертых, искренне поблагодарить его за работу и нормально попрощаться. Мир гораздо теснее, чем нам порой кажется.
Вот такой совет. Забирайте, надеюсь, пригодится!
А дальше расскажу, что может вам помочь с решением, и как потом подготовиться и провести разговор с сотрудником.
Давайте сегодня поговорим о самой неприятной задаче менеджера – об увольнениях.
Увольнять сложно. И я не встречал людей, которые бы получали от этого процесса удовольствие или заряд энергии. Чаще всего, наоборот, требуется потом время, чтобы прийти в себя и вернуться к работе.
Почему так? Виной всему наш мозг и психика. Руководитель – он же для чего? Он про бизнес, достигать целей компании, добиваться результатов. И с этой точки зрения, любое увольнение – просто задача. Специфическая, но задача. Ни больше, ни меньше.
И все бы ничего, но мы люди. Все руководители! И ни одному человеку (если он здоров) не хочется причинять боль и страдания другому человеку. А увольнение для сотрудника – это то самое и есть, как минимум хороший такой выход из зоны комфорта. Поэтому вторая наша половина хочет избежать такой задачи всеми силами.
Вот и получается внутренняя шизофрения – внутри борются менеджер и человек. Кто победит?
Чаще всего, человек побеждает ровно столько, сколько может это делать. Все время пытаешься оправдать сотрудника, дать ему второй-третий-двадцатый шанс. Еще мое любимое – копаешься в себе и ищешь причину там. Вроде как “это не сотрудник делает фигню, а это я ему недостаточно качественно задачу разжевал”. Ну и т п.
А потом человек сдается. Либо когда уже “ну все, хватит это терпеть”, либо когда просто все попытки исчерпаны и менеджер внутри победил. И в этот самый момент наступает точка принятия решения – “все, увольняю”.
Но принять решение мало, надо еще и реализовать. Хотя, сказать по чести, сложнее решиться, нежели поговорить с сотрудником. Ну во всяком случае, про себя могу так сказать.
Чтобы победить этот внутренний конфликт менеджера и человека в своей голове, в определенный момент я придумал для себя некую мантру, которую с радостью всем рассказываю. Вдруг кому-то тоже подойдет.
“Принимать решение об увольнении нужно как менеджер, а реализовывать его – как человек”.
Иными словами, решение должно базироваться исключительно на интересах бизнеса. И все эмоциональные аспекты здесь нужно отключать. А уже потом, когда решение принято, нужно включить в себе человека, и сделать все так, чтобы ваш сотрудник не страдал и не печалился.
Во-первых, нормально и по-человечески с ним поговорить и все объяснить. Без казенщины и бюрократщины. Во-вторых, предложить помочь: рекомендации, контакты и т п. В-третьих, быть честным, не пытаться сэкономить навариться на этом. И в-четвертых, искренне поблагодарить его за работу и нормально попрощаться. Мир гораздо теснее, чем нам порой кажется.
Вот такой совет. Забирайте, надеюсь, пригодится!
А дальше расскажу, что может вам помочь с решением, и как потом подготовиться и провести разговор с сотрудником.
👍18
Немного похвастаюсь :)
На этой неделе провел небольшой корпоративный тренинг про НАСТАВНИЧЕСТВО. Компания активно растет, много найма, и потому для них тема актуальна. Наставничество становится важнейшим инструментом онбординга сотрудников, а значит и неким базисом для дальнейшего развития самой компании.
Курс состоял из 3 занятий:
1. Роль наставника - обсудили функции и задачи наставника, его компетенции, варианты, как эти самые компетенции развивать, ребята сформировали свою собственную карту компетенций
2. Инструменты наставника - разобрали основные инструменты в работе наставника: обратная связь, целеполагание, коучинг, 1/1, а также потренировались в их применении
3. Сложные кейсы и ситуации - чисто практический воркшоп, отрабатывали различные нестандартные ситуации, которые могут возникать в работе наставника: подопечный плохо работает, не сходимся характерами и т п
Получилось живо и интересно. Если верить отзывам, то ребята считают также)
Курс обкатали, замечания все учтем. И, надеюсь, повторим!
На этой неделе провел небольшой корпоративный тренинг про НАСТАВНИЧЕСТВО. Компания активно растет, много найма, и потому для них тема актуальна. Наставничество становится важнейшим инструментом онбординга сотрудников, а значит и неким базисом для дальнейшего развития самой компании.
Курс состоял из 3 занятий:
1. Роль наставника - обсудили функции и задачи наставника, его компетенции, варианты, как эти самые компетенции развивать, ребята сформировали свою собственную карту компетенций
2. Инструменты наставника - разобрали основные инструменты в работе наставника: обратная связь, целеполагание, коучинг, 1/1, а также потренировались в их применении
3. Сложные кейсы и ситуации - чисто практический воркшоп, отрабатывали различные нестандартные ситуации, которые могут возникать в работе наставника: подопечный плохо работает, не сходимся характерами и т п
Получилось живо и интересно. Если верить отзывам, то ребята считают также)
Курс обкатали, замечания все учтем. И, надеюсь, повторим!
👍10
DISC
Завершаем тредик про аудит команды. Последний инструмент из еще не рассмотренных – DISC.
Причем здесь вообще психотипы и зачем нам это знать? Ну во-первых, чтобы понимать, как строить коммуникацию с человеком, какие типы аргументов для него будут весомыми, а какие – нет. А во-вторых, чтобы правильно формулировать задачи и выбирать нужный тип контроля.
DISC — акроним (как и все миллионы названий моделей в менеджменте, ага). Модель классифицирует людей на 4 типа:
- D — Dominance — Доминирующий тип — Достигаторы, воодушевленные дофамином, готовы браться практически за любую задачу, стремятся к результату. Для людей типа D (красные) характерны прямолинейность, креативность, готовность к риску и неприятностям
- I — Influence — Влияющий тип — Открытые, теплые, ставят комфортные отношения с людьми превыше всего. Для людей типа I (желтые) характерны общительность, дружелюбность, умение влиять на других
- S — Steadiness — Стабильный тип — Любят работать в отлаженных процессах, надежные, методичные, исполнительные. Для людей типа S (зеленые) характерны надежность, добродушие, умение выслушать каждого
- С — Compliance — Адаптивный тип — Аналитики, любят системность и четкость. Для людей типа C (синие) характерны аккуратность, осторожность, логичность, перфекционизм
Среди инженеров чаще всего преобладает «синий» психотип. Но других тоже немало. И каждый психотип, как я уже сказал, по‑разному реагирует на задачи.
D (красные) — это достигаторы, им важно делать работу ради работы, им просто комфортно в процессе. Поэтому они могут не дослушать задачу, сразу побежать ее выполнять. Они редко задают дополнительные вопросы, как в начале, так и по ходу дела. Поэтому главная опасность с такими сотрудниками — он со всей своей стремительностью сделает совершенно не то, что вы ждете. С такими сотрудниками лучше потратить дополнительное время на постановку задачи, убедиться, что он понял все верно. И лучше периодически пару раз проконтролировать, что все идет по плану.
I (желтые) — для таких сотрудников характерно 2 вещи. Первое — уход в абстракции, что иногда требует от вас объяснить задачу гораздо шире, чем это нужно, но ему важно сложить весь пазл целиком. Второе — уклон в творчество, т е им интересно придумать решение, но зачастую неинтересно его реализовывать. Поэтому с такими сотрудниками лучше применять поэтапный контроль, сначала разобрать идею, потом отдельные шаги в реализации, чтобы он не сваливался в прокрастинацию.
S (зеленые) — для таких сотрудников важен комфорт, причем не только собственный, но и всех вокруг. Они могут задавать странные вопросы при получении задачи, которые, на первый взгляд, не сильно относятся к делу, но им важно убедиться, что они никому не навредят. Правда, их доброжелательность и открытость иногда играет с ними злую шутку. Если по ходу выполнения задачи они будут разговаривать с людьми, то легко могут поменять исходную задачу во имя всеобщего комфорта. Поэтому здесь подойдет либо поэтапный контроль, если вы четко можете выделить точки, где сотрудника может кто‑то «переубедить», либо просто периодический, чтобы исключить такой эффект.
C (синие) — системные перфекционисты. На этапе постановки задачи ждите от них много‑много вопросов, чтобы выяснить абсолютно все, любые риски и «планы Б» по задаче. А на этапе выполнения нужно бороться с тем самым перфекционизмом. Здесь можно использовать выборочный или периодический контроль, преимущественно ближе к сроку выполнения задачи.
Учитывая психотип сотрудника, можно подобрать более эффективный тип контроля, и добиться от него выполнения задачи в том виде, как вы ее поставили. Ну или, как минимум, вероятность этого сильно возрастет.
Завершаем тредик про аудит команды. Последний инструмент из еще не рассмотренных – DISC.
Причем здесь вообще психотипы и зачем нам это знать? Ну во-первых, чтобы понимать, как строить коммуникацию с человеком, какие типы аргументов для него будут весомыми, а какие – нет. А во-вторых, чтобы правильно формулировать задачи и выбирать нужный тип контроля.
DISC — акроним (как и все миллионы названий моделей в менеджменте, ага). Модель классифицирует людей на 4 типа:
- D — Dominance — Доминирующий тип — Достигаторы, воодушевленные дофамином, готовы браться практически за любую задачу, стремятся к результату. Для людей типа D (красные) характерны прямолинейность, креативность, готовность к риску и неприятностям
- I — Influence — Влияющий тип — Открытые, теплые, ставят комфортные отношения с людьми превыше всего. Для людей типа I (желтые) характерны общительность, дружелюбность, умение влиять на других
- S — Steadiness — Стабильный тип — Любят работать в отлаженных процессах, надежные, методичные, исполнительные. Для людей типа S (зеленые) характерны надежность, добродушие, умение выслушать каждого
- С — Compliance — Адаптивный тип — Аналитики, любят системность и четкость. Для людей типа C (синие) характерны аккуратность, осторожность, логичность, перфекционизм
Среди инженеров чаще всего преобладает «синий» психотип. Но других тоже немало. И каждый психотип, как я уже сказал, по‑разному реагирует на задачи.
D (красные) — это достигаторы, им важно делать работу ради работы, им просто комфортно в процессе. Поэтому они могут не дослушать задачу, сразу побежать ее выполнять. Они редко задают дополнительные вопросы, как в начале, так и по ходу дела. Поэтому главная опасность с такими сотрудниками — он со всей своей стремительностью сделает совершенно не то, что вы ждете. С такими сотрудниками лучше потратить дополнительное время на постановку задачи, убедиться, что он понял все верно. И лучше периодически пару раз проконтролировать, что все идет по плану.
I (желтые) — для таких сотрудников характерно 2 вещи. Первое — уход в абстракции, что иногда требует от вас объяснить задачу гораздо шире, чем это нужно, но ему важно сложить весь пазл целиком. Второе — уклон в творчество, т е им интересно придумать решение, но зачастую неинтересно его реализовывать. Поэтому с такими сотрудниками лучше применять поэтапный контроль, сначала разобрать идею, потом отдельные шаги в реализации, чтобы он не сваливался в прокрастинацию.
S (зеленые) — для таких сотрудников важен комфорт, причем не только собственный, но и всех вокруг. Они могут задавать странные вопросы при получении задачи, которые, на первый взгляд, не сильно относятся к делу, но им важно убедиться, что они никому не навредят. Правда, их доброжелательность и открытость иногда играет с ними злую шутку. Если по ходу выполнения задачи они будут разговаривать с людьми, то легко могут поменять исходную задачу во имя всеобщего комфорта. Поэтому здесь подойдет либо поэтапный контроль, если вы четко можете выделить точки, где сотрудника может кто‑то «переубедить», либо просто периодический, чтобы исключить такой эффект.
C (синие) — системные перфекционисты. На этапе постановки задачи ждите от них много‑много вопросов, чтобы выяснить абсолютно все, любые риски и «планы Б» по задаче. А на этапе выполнения нужно бороться с тем самым перфекционизмом. Здесь можно использовать выборочный или периодический контроль, преимущественно ближе к сроку выполнения задачи.
Учитывая психотип сотрудника, можно подобрать более эффективный тип контроля, и добиться от него выполнения задачи в том виде, как вы ее поставили. Ну или, как минимум, вероятность этого сильно возрастет.
❤6👍1
В среду, 24 мая, 19.00 мск будет вебинар "Как увольнять и не лишиться поддержки команды?" от OTUS.
Расскажу, как правильно вести себя тимлиду/руководителю во время сокращений, как не наломать дров и не демотивировать вообще всю команду.
Регистрируйтесь и приходите поучаствовать!
https://meetup.otus.ru/team-reduction
Расскажу, как правильно вести себя тимлиду/руководителю во время сокращений, как не наломать дров и не демотивировать вообще всю команду.
Регистрируйтесь и приходите поучаствовать!
https://meetup.otus.ru/team-reduction
meetup.otus.ru
Как увольнять и не лишиться поддержки команды?
Бесплатный вебинар-дискуссия для тех, кто работает с IT-специалистами
Собрал воедино весь тредик про инструменты аудита команды. Получилась развесистая статья. Зато теперь удобно, не надо скакать по разным постам 🙂
https://habr.com/ru/articles/736908/
https://habr.com/ru/articles/736908/
Хабр
Инструменты аудита команды
Когда тимлид / руководитель приходят в новую команду, перво-наперво им нужно разобраться, кто в ней есть, как они взаимодействуют, какого поведения ожидать от этой команды. Нужна какая-то линейка,...
👍9🔥2❤1👏1
ИДЕАЛЬНЫЙ МЕНЕДЖЕР (АДИЗЕС)
Концепция Адизеса, как мне кажется, является одной из самых популярных в менеджменте. Причин тому несколько. Во-первых, она действительно крутая. Простая, понятная, структурированная. Во-вторых, она очень хорошо перекликается с другими инструментами (ну например, тот же DISC). Ну и в-третьих, сам Адизес, который сделал это делом своей жизни и хорошо пропиарил везде, где только можно. Масса книг, материалов, конференций.
Если повторить ее суть вкратце – менеджер должен выполнять и совмещать в себе 4 основные роли:
- Производитель (P) – сделать результат здесь и сейчас
- Администратор (A) – все настроить и добиться эффективности быстро
- Предприниматель (E) – придумать, как добиться успеха вдолгую
- Интегратор (I) – заставить всех работать вместе, добиться эффективности в стратегическом плане
Каждая составляющая может быть развита хорошо (отмечается заглавной буквой), может быть развита плохо (отмечается строчной буквой), может отсутствовать вовсе (отмечается прочерком).
Ну и отсюда появляются идеальные портреты разных руководителей:
- Тимлид – pAeI
- Техлид – PaEi
- CTO – pAEi
И т п. А идеальный менеджер, стало быть будет PAEI. И по мнение самого же Адизеса, его не существует.
Да и вы в моменте можете не соответствовать ожидаемой модели. Очень много начинающих тимлидов с портретом PaeI, а начинающих CTO – с PAei. Ничего не поделаешь, по щелчку пальцев сразу не поменяешься.
Что делать? Дополнять. Выделять дельту и заполнять ее. И для этого можно выделить несколько вариантов:
1. Развивать – прокачивать слабые роли:
- p → P: хард-скиллы
- a → A: процессы, системность
- e → E: стратегия, кругозор
- i → I: эмпатия, софт-скиллы
2. Дополнять – за счет привлечения к управлению сотрудников своей команды или кого-то извне:
- p → P: Senior-ы, Techlead
- a → A: Project Manager, Scrum-master
- e → E: Product Manager, Product Owner
- i → I: HR
3. Усилить команду – перебалансировать роли, чтобы стало больше таких, которые проседают у вас (вспоминаем модель Белбина):
- p → P: Исполнитель, Мотиватор, Педант
- a → A: Координатор
- e → E: Исследователь, Генератор идей
- i → I: Душа команды
Вот такой рецепт. Проверено – работает!
Концепция Адизеса, как мне кажется, является одной из самых популярных в менеджменте. Причин тому несколько. Во-первых, она действительно крутая. Простая, понятная, структурированная. Во-вторых, она очень хорошо перекликается с другими инструментами (ну например, тот же DISC). Ну и в-третьих, сам Адизес, который сделал это делом своей жизни и хорошо пропиарил везде, где только можно. Масса книг, материалов, конференций.
Если повторить ее суть вкратце – менеджер должен выполнять и совмещать в себе 4 основные роли:
- Производитель (P) – сделать результат здесь и сейчас
- Администратор (A) – все настроить и добиться эффективности быстро
- Предприниматель (E) – придумать, как добиться успеха вдолгую
- Интегратор (I) – заставить всех работать вместе, добиться эффективности в стратегическом плане
Каждая составляющая может быть развита хорошо (отмечается заглавной буквой), может быть развита плохо (отмечается строчной буквой), может отсутствовать вовсе (отмечается прочерком).
Ну и отсюда появляются идеальные портреты разных руководителей:
- Тимлид – pAeI
- Техлид – PaEi
- CTO – pAEi
И т п. А идеальный менеджер, стало быть будет PAEI. И по мнение самого же Адизеса, его не существует.
Да и вы в моменте можете не соответствовать ожидаемой модели. Очень много начинающих тимлидов с портретом PaeI, а начинающих CTO – с PAei. Ничего не поделаешь, по щелчку пальцев сразу не поменяешься.
Что делать? Дополнять. Выделять дельту и заполнять ее. И для этого можно выделить несколько вариантов:
1. Развивать – прокачивать слабые роли:
- p → P: хард-скиллы
- a → A: процессы, системность
- e → E: стратегия, кругозор
- i → I: эмпатия, софт-скиллы
2. Дополнять – за счет привлечения к управлению сотрудников своей команды или кого-то извне:
- p → P: Senior-ы, Techlead
- a → A: Project Manager, Scrum-master
- e → E: Product Manager, Product Owner
- i → I: HR
3. Усилить команду – перебалансировать роли, чтобы стало больше таких, которые проседают у вас (вспоминаем модель Белбина):
- p → P: Исполнитель, Мотиватор, Педант
- a → A: Координатор
- e → E: Исследователь, Генератор идей
- i → I: Душа команды
Вот такой рецепт. Проверено – работает!
👍8
ПРО УВОЛЬНЕНИЯ #2
Продолжаем тредик. Предыдущий пост был про разделение решения и его реализации. О том, как правильно относиться к увольнениям. Теперь давайте поговорим о том, как это самое решение принять.
Первое, что может помочь – инструмент “ошибка/проступок”. Если четко понять разницу между ними, становится гораздо проще.
И ошибка, и проступок – это некоторые неверные действия сотрудника в той ситуации, когда последствия были заранее неизвестны. Ну потому что если последствия известны, то это откровенный саботаж, и тут думать уже нечего, гнать в шею и все. Иными словами, у человека было какое-то позитивное намерение и он хотел сделать, как лучше, но не получилось.
А главное отличие между ними – было ли определено заранее, что нужно делать правильно. Если не было – человек не знал, как себя вести, скреативил в меру своих возможностей, результат не удался. Если было определено – человек поступился правилами (хотя и с некоторым позитивным намерением, повторюсь), и результат оказался логичным.
Приведу пример. Был у нас один инженер на проекте поддержки. И как-то раз он налил себе чай, и тут вдруг позвонил заказчик. На звонок он, как и положено, ответил, долго инструктировал заказчика, отвечал на его вопросы. И параллельно смачно серпал чаем прямо в трубку. После такого разговора заказчик нажаловался начальству и пришлось разбираться. Естественно, сотрудник просто не подумал, что это может вызвать дискомфорт, оттого и сидел прихлебывал, не заморачиваясь. Мы просмотрели все основные инструкции для инженеров поддержки, и убедились, что подобные кейсы нигде не описываются. Значит, заранее определено не было, перед нами ошибка.
Но этим все не закончилось. Мы учли проблему, прописали в инструкции, что нельзя серпать и чавкать в трубку. Оформили в презентацию, разослали всем сотрудникам поддержки. Сделали свою работу над ошибками. А спустя пару недель этот же сотрудник повторил тот же трюк, но уже с другим заказчиком. А заказчик не был оригинальным, и также пожаловался. Т е сотрудник уже знал правила, и просто их проигнорировал. Не сознательно, просто не заморачивался и все. Этот кейс был трактован нами, как проступок.
Так вот, за ошибки не увольняют. Ошибки, как правило, подсвечивают системные проблемы: изъяны процессов, недоработку руководителей и т п. Ну и в конце концов, все люди, все могут делать ошибки. А вот проступок не подсвечивает ничего, кроме того, что сотрудник игнорирует правила. Игнорирует ваши с ним договоренности, контрактинг. И вот за проступки увольнять стоит. Сразу же или дать шанс – решать вам. Но обратить на это внимание и обработать такую ситуацию точно следует. Самым жестким образом.
И еще один момент. Необработанная ошибка – это проступок руководителя. Любая ошибка должна быть исправлена. Причем исправлена в будущее, чтобы предотвратить повторение. И это задача руководителя.
И вопрос на подумать – что делать с теми, у кого эти ошибки повторяются постоянно, раз за разом. Ситуация же неоднозначная. Может руки неправильно растут, а может в процессах такой бардак, что чуть шаг влево или шаг вправо – и непонятно, что делать. В таких кейсах рекомендую посмотреть пристально на систему. И если с ней все ок и дело в сотруднике – тоже повод задуматься.
Продолжение следует.
Продолжаем тредик. Предыдущий пост был про разделение решения и его реализации. О том, как правильно относиться к увольнениям. Теперь давайте поговорим о том, как это самое решение принять.
Первое, что может помочь – инструмент “ошибка/проступок”. Если четко понять разницу между ними, становится гораздо проще.
И ошибка, и проступок – это некоторые неверные действия сотрудника в той ситуации, когда последствия были заранее неизвестны. Ну потому что если последствия известны, то это откровенный саботаж, и тут думать уже нечего, гнать в шею и все. Иными словами, у человека было какое-то позитивное намерение и он хотел сделать, как лучше, но не получилось.
А главное отличие между ними – было ли определено заранее, что нужно делать правильно. Если не было – человек не знал, как себя вести, скреативил в меру своих возможностей, результат не удался. Если было определено – человек поступился правилами (хотя и с некоторым позитивным намерением, повторюсь), и результат оказался логичным.
Приведу пример. Был у нас один инженер на проекте поддержки. И как-то раз он налил себе чай, и тут вдруг позвонил заказчик. На звонок он, как и положено, ответил, долго инструктировал заказчика, отвечал на его вопросы. И параллельно смачно серпал чаем прямо в трубку. После такого разговора заказчик нажаловался начальству и пришлось разбираться. Естественно, сотрудник просто не подумал, что это может вызвать дискомфорт, оттого и сидел прихлебывал, не заморачиваясь. Мы просмотрели все основные инструкции для инженеров поддержки, и убедились, что подобные кейсы нигде не описываются. Значит, заранее определено не было, перед нами ошибка.
Но этим все не закончилось. Мы учли проблему, прописали в инструкции, что нельзя серпать и чавкать в трубку. Оформили в презентацию, разослали всем сотрудникам поддержки. Сделали свою работу над ошибками. А спустя пару недель этот же сотрудник повторил тот же трюк, но уже с другим заказчиком. А заказчик не был оригинальным, и также пожаловался. Т е сотрудник уже знал правила, и просто их проигнорировал. Не сознательно, просто не заморачивался и все. Этот кейс был трактован нами, как проступок.
Так вот, за ошибки не увольняют. Ошибки, как правило, подсвечивают системные проблемы: изъяны процессов, недоработку руководителей и т п. Ну и в конце концов, все люди, все могут делать ошибки. А вот проступок не подсвечивает ничего, кроме того, что сотрудник игнорирует правила. Игнорирует ваши с ним договоренности, контрактинг. И вот за проступки увольнять стоит. Сразу же или дать шанс – решать вам. Но обратить на это внимание и обработать такую ситуацию точно следует. Самым жестким образом.
И еще один момент. Необработанная ошибка – это проступок руководителя. Любая ошибка должна быть исправлена. Причем исправлена в будущее, чтобы предотвратить повторение. И это задача руководителя.
И вопрос на подумать – что делать с теми, у кого эти ошибки повторяются постоянно, раз за разом. Ситуация же неоднозначная. Может руки неправильно растут, а может в процессах такой бардак, что чуть шаг влево или шаг вправо – и непонятно, что делать. В таких кейсах рекомендую посмотреть пристально на систему. И если с ней все ок и дело в сотруднике – тоже повод задуматься.
Продолжение следует.
👍7
Видео вчерашнего эфира "Как увольнять и не лишиться поддержки команды?"
https://www.youtube.com/watch?v=s4_ynRUy4a8
Постарался "на пальцах" объяснить, как вести себя руководителю, если он должен провести волну сокращений, чтобы при этом сохранить и саму команду, и приемлемый уровень ее продуктивности.
Внутри немного рекламы OTUSа, но и контент, вроде бы, ничего 🙂
https://www.youtube.com/watch?v=s4_ynRUy4a8
Постарался "на пальцах" объяснить, как вести себя руководителю, если он должен провести волну сокращений, чтобы при этом сохранить и саму команду, и приемлемый уровень ее продуктивности.
Внутри немного рекламы OTUSа, но и контент, вроде бы, ничего 🙂
YouTube
Как увольнять и не лишиться поддержки команды?
Запланируйте обучение своих сотрудников на 2023 год уже сейчас! Оставьте заявку до 31 мая а и получите бесплатную консультацию от эксперта по развитию команды – https://otus.pw/ioqy/
IT уже не торт. Это больше не дико растущая отрасль, готовая нанимать всех…
IT уже не торт. Это больше не дико растущая отрасль, готовая нанимать всех…
👍5
МОДЕЛЬ БЕННА И ШИТСА
Готов поспорить, про эту модель вы раньше не слышали. Во всяком случае, я сам на нее наткнулся совсем недавно. В отличие от популярных Такманов и Белбинов, про эту модель почти никто не говорит и не пишет. А зря.
Это снова модель про командные роли. Выделяется 3 основных уровня ролей:
1. Целевые роли – роли, связанные с выполнением непосредственно работы
2. Социальные роли – роли, способствующие позитивному функционированию коллектива
3. Дисфункциональные роли – роли, замедляющие продвижение к цели и ослабляющие сплоченность коллектива
Целевых ролей порядка 12. Они декомпозируют и дублируют роли действия и, частично, интеллектуальные роли Белбина. Так что ничего особенно интересного.
Социальных ролей 6. С ними та же история, только они декомпозируют социальные роли Белбина. Так что тоже пропустим.
А вот дисфункциональные роли – это что-то новенькое. Бенн и Шитс выделили 9 таких ролей:
- Агрессор
- Блокирующий
- Ищущий признания
- Исповедник
- Нарушитель/Бунтарь
- Playboy/Playgirl
- Доминирующий
- Ищущий помощи
- Преследующий свои интересы
Думаю, пояснять не нужно, из названия понятно, кто из них про что.
Так вот, основная идея модели включает 2 шага:
1. Проверить наличие Целевых и Социальных ролей, добавить недостающие и создать баланс
2. Отыскать все присутствующие в команде Дисфункциональные роли и устранить
Как устранить? В позитивном сценарии – перевоспитать плохиша. В негативном – убрать из команды.
А далее наблюдать и держать руку на пульсе, реагировать, как только подобные роли снова начнут зарождаться и прорастать.
В чем профит модели? В систематизации этих дисфункциональных ролей. Ведь если знаешь что искать, то искать гораздо проще. И по каждому типажу есть набор понятных причин появления, и проверенных методов исправления ситуации.
Вот такой инструмент в копилочку. Как по мне – полезный.
Готов поспорить, про эту модель вы раньше не слышали. Во всяком случае, я сам на нее наткнулся совсем недавно. В отличие от популярных Такманов и Белбинов, про эту модель почти никто не говорит и не пишет. А зря.
Это снова модель про командные роли. Выделяется 3 основных уровня ролей:
1. Целевые роли – роли, связанные с выполнением непосредственно работы
2. Социальные роли – роли, способствующие позитивному функционированию коллектива
3. Дисфункциональные роли – роли, замедляющие продвижение к цели и ослабляющие сплоченность коллектива
Целевых ролей порядка 12. Они декомпозируют и дублируют роли действия и, частично, интеллектуальные роли Белбина. Так что ничего особенно интересного.
Социальных ролей 6. С ними та же история, только они декомпозируют социальные роли Белбина. Так что тоже пропустим.
А вот дисфункциональные роли – это что-то новенькое. Бенн и Шитс выделили 9 таких ролей:
- Агрессор
- Блокирующий
- Ищущий признания
- Исповедник
- Нарушитель/Бунтарь
- Playboy/Playgirl
- Доминирующий
- Ищущий помощи
- Преследующий свои интересы
Думаю, пояснять не нужно, из названия понятно, кто из них про что.
Так вот, основная идея модели включает 2 шага:
1. Проверить наличие Целевых и Социальных ролей, добавить недостающие и создать баланс
2. Отыскать все присутствующие в команде Дисфункциональные роли и устранить
Как устранить? В позитивном сценарии – перевоспитать плохиша. В негативном – убрать из команды.
А далее наблюдать и держать руку на пульсе, реагировать, как только подобные роли снова начнут зарождаться и прорастать.
В чем профит модели? В систематизации этих дисфункциональных ролей. Ведь если знаешь что искать, то искать гораздо проще. И по каждому типажу есть набор понятных причин появления, и проверенных методов исправления ситуации.
Вот такой инструмент в копилочку. Как по мне – полезный.
👍7🔥1
ДАЙДЖЕСТ ЗА ПОСЛЕДНИЕ 2 НЕДЕЛИ
Анонс моего МК на Skolkovo Tech Week - 28 июня в секции MANAGEMENT, буду рассказывать, как тимлид может стать ключевым звеном в изменении корпоративной культуры
Видео с вебинара "Я тимлид. Что дальше?" - рассказывал про роль Delivery Managera и про курс, который запускаем в OTUS
Пост про модель Мамонта - простая модель для целеполагания команды
Пост про то, как развалить команду - отпичные ошибки руководиелей в формате вредных советов
Пост про увольнения #1 - о том, как относиться к увольнениям, как научиться принимать эти решения
Небольшой кейс - проведенное корпоративное обучение по наставничеству
Пост про DISC - простая модель типизирования психотипов
Ссылка на статью про инструменты аудита команды - собрал в одном месте весь тредик из чата
Пост про идеального менеджера по Адизесу - как и чем можно дополнять себя, чтобы его добиться
Пост про увольнения #2 - разбор отличия ошибки и проступка, за что нужно увольнять
Видео с вебинара "Как увольнять и не лишиться поддержки команды" - о том, как вести себя руководителю, если ему приходится заниматься сокращениями, чтобы команда не развалилась
Пост про модель Бенна и Шитса - не самая популярная модель, выделяющая основные дисфункциональные роли в команде
Продолжение следует!
Анонс моего МК на Skolkovo Tech Week - 28 июня в секции MANAGEMENT, буду рассказывать, как тимлид может стать ключевым звеном в изменении корпоративной культуры
Видео с вебинара "Я тимлид. Что дальше?" - рассказывал про роль Delivery Managera и про курс, который запускаем в OTUS
Пост про модель Мамонта - простая модель для целеполагания команды
Пост про то, как развалить команду - отпичные ошибки руководиелей в формате вредных советов
Пост про увольнения #1 - о том, как относиться к увольнениям, как научиться принимать эти решения
Небольшой кейс - проведенное корпоративное обучение по наставничеству
Пост про DISC - простая модель типизирования психотипов
Ссылка на статью про инструменты аудита команды - собрал в одном месте весь тредик из чата
Пост про идеального менеджера по Адизесу - как и чем можно дополнять себя, чтобы его добиться
Пост про увольнения #2 - разбор отличия ошибки и проступка, за что нужно увольнять
Видео с вебинара "Как увольнять и не лишиться поддержки команды" - о том, как вести себя руководителю, если ему приходится заниматься сокращениями, чтобы команда не развалилась
Пост про модель Бенна и Шитса - не самая популярная модель, выделяющая основные дисфункциональные роли в команде
Продолжение следует!
👍4👏1
ВОПРОСНИК #14
Вопрос от @darya_samoylenko по мотивам вот этой статьи.
Вопрос:
Здравствуйте! Очень понравилась статья про People Management, подскажите, пожалуйста, в каких программах вы измеряли Тим-мораль и какой ERP-системой вы пользовались для измерения People Status?
Ответ:
Перво-наперво, спасибо за ваш вопрос, Дарья, и за фидбек. Рад быть полезным!
По поводу тимморали – мы использовали испокон веку гуглоформы, и их хватало. По сути, с этой ролью справится любая онлайн форма, в которой можно настроить поля с вопросами и потом выгрузить результаты в эксельку. В эксельку надо обязательно, чтобы можно было потом поиграться с цифрами: пофильтровать, поагрегировать, нарисовать красивые графики. Конкретно в гуглодоках есть еще обалденный функционал комментариев, с указанием ответственного. Позволяет тут же в одном месте делать все необходимые эскалации и обрабатывать все операционные вопросы.
Если говорить о том, что писать в форму (какие именно вопросы), то тут простор для креатива бесконечный. Мы старались использовать простые и не завуалированные вопросы, без лишней магии: как работается? чувствуешь ли, что развиваешься? комфортно ли тебе в коллективе? интересно ли заниматься задачами проекта? и т д. Можно попробовать более сложные версии, но я не знаю, есть ли смысл.
Теперь про People Status. Начинали мы также с гуглоформ. И это было неудобно, поскольку возникает проблема секьюрности. Мы пытались закрыть информацию об оценке человека от самого человека, и не показывать эту информацию никому, кроме руководителей человека и HR-ов. В простом варианте это означало примерно мильен разных форм и гуглодоков к ним, чтобы на каждую команду и на каждый уровень иерархии. А в сложном – когда кто-то переходил в другую команду или повышался, нужно было создавать новый файл. Почему? Потому что гугол хранит историю изменения документа, абсолютно всю.
По итогу функционал уехал в нашу собственную ERP-систему. Скриншоты в статье как раз из нее. Она самописная и чисто для внутреннего использования, поэтому поделиться, к сожалению, никак не смогу. Там уже проблем с секьюрностью не было, и все это связалось в единую информационную систему компании.
Некоторое время назад, когда мы выходили на рынок РФ, мы делали маркетинговый анализ. Искали похожие сервисы, как наша внутренняя ERP. Хотели сделать из нее продукт, смотрели перспективы. Так вот. Готового инструмента со встроенным похожим функционалом мы не нашли. На следующей неделе наши HR даже сделают доклад на HR-API по этому поводу 🙂
Но почти в каждом популярном инструменте есть функционал контроля и измерения eNPS. Что, по сути, похоже. Можно как-то поколдовать вокруг этого. Хотя это опять будут костыли и велосипеды. Но что поделать.
Для первого пилотного внедрения, как по мне, можно обойтись гуглодоками. Мы с ними жили долго, для команды до 100 человек с не очень сложной иерархией, в целом, приемлемо. А дальше, если зайдет, можно что-то простенькое написать.
Надеюсь, получилось ответить на вопрос.
P.S. Пишите свои вопросы и кейсы вот в эту форму https://forms.gle/aBX5PgU1CLU4FDPP8
Вопрос от @darya_samoylenko по мотивам вот этой статьи.
Вопрос:
Здравствуйте! Очень понравилась статья про People Management, подскажите, пожалуйста, в каких программах вы измеряли Тим-мораль и какой ERP-системой вы пользовались для измерения People Status?
Ответ:
Перво-наперво, спасибо за ваш вопрос, Дарья, и за фидбек. Рад быть полезным!
По поводу тимморали – мы использовали испокон веку гуглоформы, и их хватало. По сути, с этой ролью справится любая онлайн форма, в которой можно настроить поля с вопросами и потом выгрузить результаты в эксельку. В эксельку надо обязательно, чтобы можно было потом поиграться с цифрами: пофильтровать, поагрегировать, нарисовать красивые графики. Конкретно в гуглодоках есть еще обалденный функционал комментариев, с указанием ответственного. Позволяет тут же в одном месте делать все необходимые эскалации и обрабатывать все операционные вопросы.
Если говорить о том, что писать в форму (какие именно вопросы), то тут простор для креатива бесконечный. Мы старались использовать простые и не завуалированные вопросы, без лишней магии: как работается? чувствуешь ли, что развиваешься? комфортно ли тебе в коллективе? интересно ли заниматься задачами проекта? и т д. Можно попробовать более сложные версии, но я не знаю, есть ли смысл.
Теперь про People Status. Начинали мы также с гуглоформ. И это было неудобно, поскольку возникает проблема секьюрности. Мы пытались закрыть информацию об оценке человека от самого человека, и не показывать эту информацию никому, кроме руководителей человека и HR-ов. В простом варианте это означало примерно мильен разных форм и гуглодоков к ним, чтобы на каждую команду и на каждый уровень иерархии. А в сложном – когда кто-то переходил в другую команду или повышался, нужно было создавать новый файл. Почему? Потому что гугол хранит историю изменения документа, абсолютно всю.
По итогу функционал уехал в нашу собственную ERP-систему. Скриншоты в статье как раз из нее. Она самописная и чисто для внутреннего использования, поэтому поделиться, к сожалению, никак не смогу. Там уже проблем с секьюрностью не было, и все это связалось в единую информационную систему компании.
Некоторое время назад, когда мы выходили на рынок РФ, мы делали маркетинговый анализ. Искали похожие сервисы, как наша внутренняя ERP. Хотели сделать из нее продукт, смотрели перспективы. Так вот. Готового инструмента со встроенным похожим функционалом мы не нашли. На следующей неделе наши HR даже сделают доклад на HR-API по этому поводу 🙂
Но почти в каждом популярном инструменте есть функционал контроля и измерения eNPS. Что, по сути, похоже. Можно как-то поколдовать вокруг этого. Хотя это опять будут костыли и велосипеды. Но что поделать.
Для первого пилотного внедрения, как по мне, можно обойтись гуглодоками. Мы с ними жили долго, для команды до 100 человек с не очень сложной иерархией, в целом, приемлемо. А дальше, если зайдет, можно что-то простенькое написать.
Надеюсь, получилось ответить на вопрос.
P.S. Пишите свои вопросы и кейсы вот в эту форму https://forms.gle/aBX5PgU1CLU4FDPP8
👍5
В эту среду, 31 мая, в 20.00 МСК провожу открытый урок курса Тимлид в OTUS.
Будем разговаривать про риски - зачем это тимлиду, как этим всем управлять, без бюрократии и казенщины.
Зарегистрироваться можно по ссылке https://otus.ru/lessons/teamlead2-0/#event-2925
Будем разговаривать про риски - зачем это тимлиду, как этим всем управлять, без бюрократии и казенщины.
Зарегистрироваться можно по ссылке https://otus.ru/lessons/teamlead2-0/#event-2925
otus.ru
Team Lead: эффективное управление командами разработки
Курс по управлению командами разработки в OTUS с возможностью трудоустройства!
👍2
Написал совместно с OTUS статью о том, как управлять тимлидами: в чем тут особенности и какие инструменты могут пригодиться.
https://habr.com/ru/companies/otus/articles/738824/
В первую очередь, статья для Delivery Manager-ов и CTO (да-да, это все в предверии старта нового курса для DM, все верно). Но может пригодиться и самим тимлидам.
А еще по этой же теме проведу открытый урок 7 июня в 20.00 мск. Зарегистрироваться можно тамже в статье. Или ссылочку положу в комменте.
https://habr.com/ru/companies/otus/articles/738824/
В первую очередь, статья для Delivery Manager-ов и CTO (да-да, это все в предверии старта нового курса для DM, все верно). Но может пригодиться и самим тимлидам.
А еще по этой же теме проведу открытый урок 7 июня в 20.00 мск. Зарегистрироваться можно тамже в статье. Или ссылочку положу в комменте.
Хабр
Как управлять тимлидами
Управление тимлидами сильно отличается от управления инженерами. Это логично, ведь перед вами теперь руководители, а не обычные сотрудники. Тимлиды не любят излишний менеджмент и контроль. И зачастую,...
❤5
ПРО МЕТРИКИ ПРОЕКТА
Недавно открыл для себя инструмент HEART. Это некоторый набор фокусов, по которым нужно следить за продуктом, чтобы все его аспекты были под контролем.
H → Happiness — польза для клиента: метрики лояльности
E → Engagement — вовлеченность ЦА: метрики взаимодействия
A → Adoption — принятие: показатели роста новой аудитории
R → Retention — удержание клиентов: показатели удержания и оттока
T → Task Success — успех внедрения и продвижения продукта: финансовые показатели
Задумался, а есть ли что-то подобное для проектов? Иными словами, как понять, является ли ваш набор проектных метрик полным и достаточным, чтобы ничего не упустить из виду? Гуглил и искал – ничего (может плохо гуглил, конечно).
Но грустить я не стал, и решил состряпать такой инструмент сам 🙂 Не ну а чего.
Итак, представляю вашему вниманию инструмент PROJECT. Также как и HEART, он раскрывает основные фокусы внимания и наблюдения за проектом, чтобы ничего-ничего не прошло мимо вас.
P → People – команда проекта и ее состояние: метрики тимморали, текучка, eNPS и т п
R → Reliability – надежность, качество: количество инцидентов, bug leakage rate и т п
O → Operations – операционные показатели: метрики, на основании которых можно сделать вывод, что команда работает нормально, например velocity или lead time
J → Job – состояние скоупа: сколько сделано, сколько осталось, прогноз
E → Economy – финансовые показатели: бюджет проекта, маржинальность, потерянные деньги и т п
C → Customer – удовлетворенность клиента: NPS, средний чек, LTV, лояльность
T → Timetable – расписание: состояние роадмапа и деливери
Не знаю, приживется эта классификация или нет. Но как по мне, выглядит неплохо. Можно пользоваться. Выделяешь по 1-2 метрики на каждую букву, и вуаля, проект, как на ладони. Полезно будет и тимлидам, и ПМам, и delivery manager-ам, и CTO.
Как по-вашему? Стоит развивать и продвигать?
Или может надо добавить сюда что-то? Поделитесь мыслями.
Недавно открыл для себя инструмент HEART. Это некоторый набор фокусов, по которым нужно следить за продуктом, чтобы все его аспекты были под контролем.
H → Happiness — польза для клиента: метрики лояльности
E → Engagement — вовлеченность ЦА: метрики взаимодействия
A → Adoption — принятие: показатели роста новой аудитории
R → Retention — удержание клиентов: показатели удержания и оттока
T → Task Success — успех внедрения и продвижения продукта: финансовые показатели
Задумался, а есть ли что-то подобное для проектов? Иными словами, как понять, является ли ваш набор проектных метрик полным и достаточным, чтобы ничего не упустить из виду? Гуглил и искал – ничего (может плохо гуглил, конечно).
Но грустить я не стал, и решил состряпать такой инструмент сам 🙂 Не ну а чего.
Итак, представляю вашему вниманию инструмент PROJECT. Также как и HEART, он раскрывает основные фокусы внимания и наблюдения за проектом, чтобы ничего-ничего не прошло мимо вас.
P → People – команда проекта и ее состояние: метрики тимморали, текучка, eNPS и т п
R → Reliability – надежность, качество: количество инцидентов, bug leakage rate и т п
O → Operations – операционные показатели: метрики, на основании которых можно сделать вывод, что команда работает нормально, например velocity или lead time
J → Job – состояние скоупа: сколько сделано, сколько осталось, прогноз
E → Economy – финансовые показатели: бюджет проекта, маржинальность, потерянные деньги и т п
C → Customer – удовлетворенность клиента: NPS, средний чек, LTV, лояльность
T → Timetable – расписание: состояние роадмапа и деливери
Не знаю, приживется эта классификация или нет. Но как по мне, выглядит неплохо. Можно пользоваться. Выделяешь по 1-2 метрики на каждую букву, и вуаля, проект, как на ладони. Полезно будет и тимлидам, и ПМам, и delivery manager-ам, и CTO.
Как по-вашему? Стоит развивать и продвигать?
Или может надо добавить сюда что-то? Поделитесь мыслями.
Видео вчерашнего открытого урока про риски - просто и на пальцах.
https://www.youtube.com/watch?v=X6XJ9gNYqPs
https://www.youtube.com/watch?v=X6XJ9gNYqPs
YouTube
Риск-менеджмент для тимлидов разработки // Демо-занятие курса «Team Lead»
На риски редко обращают внимание. Особенно тимлиды. А зря. Ведь это мощный инструмент, способный предупреждать и даже решать многие проектные проблемы.
На бесплатном уроке обсудим:
- В чем смысл рисков и зачем ими управлять
- Зачем риск-менеджмент тимлиду…
На бесплатном уроке обсудим:
- В чем смысл рисков и зачем ими управлять
- Зачем риск-менеджмент тимлиду…
ПРО УВОЛЬНЕНИЯ #3
И снова тредик про увольнения. Не подумайте, что мне нравится увольнять людей и это моя любимая задача (хотя, кто знает…). Просто тема довольно востребованная, а материалов не так уж и много. Вот хочу этот пробел восполнить.
В прошлых сериях мы говорили о том, как относиться к увольнениям, и как принимать решение, увольнять или нет. Разобрали подход “ошибка/проступок”. Сегодня рассмотрим еще один.
В свое время комбат Батырев ввел в повседневный обиход менеджеров термин, ставший уже нарицательным – “учить/лечить/мочить”. И вроде бы понятно, сначала учить, потом лечить. Но вот абстрактно как-то все равно, конкретики бы сюда.
Начнем с того, что выделяют 4 основные причины, отчего человек что-то не делает (или делает плохо):
1. Не понимает – не осознает важности задачи
2. Не умеет – просто не научил никто
3. Не может – нет ресурсов
4. Не хочет – вот тут уже без оправданий, чисто не хочет и все
Так вот, начинать свой анализ следует именно с выяснения причин. Сотрудник плохо делает свою работу – почему?
Если выясняется, что дело в пунктах 1-3 – нужно “учить”. Либо разжевать, почему задача важна и как она влияет на команду или целую компанию. Либо научить эту задачу делать, если вопрос в компетенциях. Либо выдать ресурсы (а в идеале научить ими правильно распоряжаться, сделать экскурс в мир приоритетов).
А вот если вы убедились в том, что причина 4, и сотрудник просто не хочет делать работу хорошо – сам себе буратино, надо “лечить”.
Как “лечить”? Я предлагаю 2-х шаговый алгоритм. Мы использовали его в компании и обкатали на практике. Могу сказать, что работает неплохо.
Шаг 1 – Предупреждение:
1. Донести обратную связь
2. Объяснить, что взаимоотношения под угрозой, и дальше так работать нельзя
3. Обозначить цели и сроки по исправлению – чем конкретнее здесь, тем лучше, прям все по SMART-у
4. Определить свое участие и помощь – на этом этапе не отключаемся, а помогаем сотруднику справиться с проблемой
Если сроки наступили, а цели выполнены, и работой сотрудника на этом этапе вы довольны, то вуаля! Все получилось! Если нет – переходим к шагу 2.
Шаг 2 – Последний шанс:
1. Донести обратную связь
2. Объяснить, что следующий шаг – уже увольнение
3. Обозначить цели и сроки по исправлению – здесь надо еще конкретнее, все максимально по SMART-у
И обратите внимание, в “последнем шансе” мы уже не предлагаем свою помощь. Теперь каждый сам за себя. Справишься – молодец, работаем. Нет – значит нет, мы уже пытались тебе помочь на прошлом шаге.
Ну и здесь, конечно, 50/50. Кто-то проникается и исправляется. Кто-то дотапливает себя до конца. Но для случая 2 у вас есть целая куча аргументов к разговору об увольнении. Аргументов и фактов, спорить с которыми будет сложно.
Если сотрудник не сдюжил, то остается только “мочить” – увольняем. А про это будет в следующей серии.
И снова тредик про увольнения. Не подумайте, что мне нравится увольнять людей и это моя любимая задача (хотя, кто знает…). Просто тема довольно востребованная, а материалов не так уж и много. Вот хочу этот пробел восполнить.
В прошлых сериях мы говорили о том, как относиться к увольнениям, и как принимать решение, увольнять или нет. Разобрали подход “ошибка/проступок”. Сегодня рассмотрим еще один.
В свое время комбат Батырев ввел в повседневный обиход менеджеров термин, ставший уже нарицательным – “учить/лечить/мочить”. И вроде бы понятно, сначала учить, потом лечить. Но вот абстрактно как-то все равно, конкретики бы сюда.
Начнем с того, что выделяют 4 основные причины, отчего человек что-то не делает (или делает плохо):
1. Не понимает – не осознает важности задачи
2. Не умеет – просто не научил никто
3. Не может – нет ресурсов
4. Не хочет – вот тут уже без оправданий, чисто не хочет и все
Так вот, начинать свой анализ следует именно с выяснения причин. Сотрудник плохо делает свою работу – почему?
Если выясняется, что дело в пунктах 1-3 – нужно “учить”. Либо разжевать, почему задача важна и как она влияет на команду или целую компанию. Либо научить эту задачу делать, если вопрос в компетенциях. Либо выдать ресурсы (а в идеале научить ими правильно распоряжаться, сделать экскурс в мир приоритетов).
А вот если вы убедились в том, что причина 4, и сотрудник просто не хочет делать работу хорошо – сам себе буратино, надо “лечить”.
Как “лечить”? Я предлагаю 2-х шаговый алгоритм. Мы использовали его в компании и обкатали на практике. Могу сказать, что работает неплохо.
Шаг 1 – Предупреждение:
1. Донести обратную связь
2. Объяснить, что взаимоотношения под угрозой, и дальше так работать нельзя
3. Обозначить цели и сроки по исправлению – чем конкретнее здесь, тем лучше, прям все по SMART-у
4. Определить свое участие и помощь – на этом этапе не отключаемся, а помогаем сотруднику справиться с проблемой
Если сроки наступили, а цели выполнены, и работой сотрудника на этом этапе вы довольны, то вуаля! Все получилось! Если нет – переходим к шагу 2.
Шаг 2 – Последний шанс:
1. Донести обратную связь
2. Объяснить, что следующий шаг – уже увольнение
3. Обозначить цели и сроки по исправлению – здесь надо еще конкретнее, все максимально по SMART-у
И обратите внимание, в “последнем шансе” мы уже не предлагаем свою помощь. Теперь каждый сам за себя. Справишься – молодец, работаем. Нет – значит нет, мы уже пытались тебе помочь на прошлом шаге.
Ну и здесь, конечно, 50/50. Кто-то проникается и исправляется. Кто-то дотапливает себя до конца. Но для случая 2 у вас есть целая куча аргументов к разговору об увольнении. Аргументов и фактов, спорить с которыми будет сложно.
Если сотрудник не сдюжил, то остается только “мочить” – увольняем. А про это будет в следующей серии.
👍6
Друзья!
В понедельник, 5 июня, в 19.00 мск приглашаю вас на вебинар "Как руководителю повысить прозрачность работы проектных команд?" от OTUS.
Там поговорим об оптимизме тимлидов, построении системы прозрачности, моих любимых метриках здоровья проекта.
Зарегистрироваться можно тут https://meetup.otus.ru/project-optimisation
В понедельник, 5 июня, в 19.00 мск приглашаю вас на вебинар "Как руководителю повысить прозрачность работы проектных команд?" от OTUS.
Там поговорим об оптимизме тимлидов, построении системы прозрачности, моих любимых метриках здоровья проекта.
Зарегистрироваться можно тут https://meetup.otus.ru/project-optimisation
meetup.otus.ru
Как повысить прозрачность работы проектных команд и закрыть проекты в срок?
Бесплатный эфир по координации проектного офиса на основании опыта и ошибок исполнительного директора IT компании
🤝2
ПРОБЛЕМА РОСТА МЕНЕДЖЕРОВ
Часто говоря про проблемы роста менеджеров. Оно наблюдается при каждом переходе на новый уровень. Сначала управлял только самим собой, стал управлять командой – проблема роста. Управлял командой, стал управлять несколькими командами – проблема роста. Управлял командами, стал управлять целой функцией – проблема роста. И т д. До самых самых высот.
Для наглядности, возьмем модель Адизеса. Ну помните, да? Там 4 роли руководителя: производитель, администратор, стратег (предприниматель) и интегратор. И для каждого уровня менеджмента (хотя сказать по чести, для каждой отдельной компании тоже) есть своя комбинация, которая необходима здесь и сейчас.
В среднем по больнице получается так:
- Инженер → Paei
- Тимлид → PaeI (иногда указывают pAeI, что встречается, но как по мне, не совсем верно)
- Delivery Manager → pAEi
- CTO → paEi
Повторюсь, комбинации могут отличаться от компании к компании. Так что, если у вас иначе – это ок, все нормально. Я усредняю.
Обратите внимание на переход тимлид → delivery manager. Он здесь самый наглядный. Чтобы совершить такой рывок, нужно значительно прокачать свои A и E. Но это полбеды. Присказка, так сказать. Все это решается обучением, практикой новых задач, наблюдением за другими руководителями.
А вот сказка начинается дальше. Чтобы рывок получился, нужно еще и “приглушить” в себе P и I. Перестать делать руками, перестать тесно работать и взаимодействовать с сотрудниками. А это уже куда сложнее. Тут и обучение не сильно помогает. И практика слабовато развивает. Потому что это уже история про изменение mind-set-а, а не про наработку новых знаний и навыков.
Что делать? Заставлять себя. Осознать четко свою роль, ее новые границы и зоны ответственности. И осознанно делегировать все, что выходит за рамки. Иногда это особенно сложно, потому что вашими руками задача будет сделана за 5 минут, а сотруднику ее только объяснять 15. А потом еще проверять, да и не знай сделает, не знай нет. Но таков путь, как говорится.
Со временем эти пропорции поменяются, взаимопонимание с сотрудниками повысится, делегирование станет мега полезным и продуктивным. А поначалу приходится терпеть и заставлять себя. Но другого варианта нет.
Учитесь делегировать смолоду! Эти инвестиции окупаются, хоть и не сразу.
Часто говоря про проблемы роста менеджеров. Оно наблюдается при каждом переходе на новый уровень. Сначала управлял только самим собой, стал управлять командой – проблема роста. Управлял командой, стал управлять несколькими командами – проблема роста. Управлял командами, стал управлять целой функцией – проблема роста. И т д. До самых самых высот.
Для наглядности, возьмем модель Адизеса. Ну помните, да? Там 4 роли руководителя: производитель, администратор, стратег (предприниматель) и интегратор. И для каждого уровня менеджмента (хотя сказать по чести, для каждой отдельной компании тоже) есть своя комбинация, которая необходима здесь и сейчас.
В среднем по больнице получается так:
- Инженер → Paei
- Тимлид → PaeI (иногда указывают pAeI, что встречается, но как по мне, не совсем верно)
- Delivery Manager → pAEi
- CTO → paEi
Повторюсь, комбинации могут отличаться от компании к компании. Так что, если у вас иначе – это ок, все нормально. Я усредняю.
Обратите внимание на переход тимлид → delivery manager. Он здесь самый наглядный. Чтобы совершить такой рывок, нужно значительно прокачать свои A и E. Но это полбеды. Присказка, так сказать. Все это решается обучением, практикой новых задач, наблюдением за другими руководителями.
А вот сказка начинается дальше. Чтобы рывок получился, нужно еще и “приглушить” в себе P и I. Перестать делать руками, перестать тесно работать и взаимодействовать с сотрудниками. А это уже куда сложнее. Тут и обучение не сильно помогает. И практика слабовато развивает. Потому что это уже история про изменение mind-set-а, а не про наработку новых знаний и навыков.
Что делать? Заставлять себя. Осознать четко свою роль, ее новые границы и зоны ответственности. И осознанно делегировать все, что выходит за рамки. Иногда это особенно сложно, потому что вашими руками задача будет сделана за 5 минут, а сотруднику ее только объяснять 15. А потом еще проверять, да и не знай сделает, не знай нет. Но таков путь, как говорится.
Со временем эти пропорции поменяются, взаимопонимание с сотрудниками повысится, делегирование станет мега полезным и продуктивным. А поначалу приходится терпеть и заставлять себя. Но другого варианта нет.
Учитесь делегировать смолоду! Эти инвестиции окупаются, хоть и не сразу.
👍7👎1