ПРО ПЕРЕГОВОРЫ #4

Возрождаю забытый тредик. В продолжение предыдущих постов про переговоры:
ПРО ПЕРЕГОВОРЫ #1
ПРО ПЕРЕГОВОРЫ #2
ПРО ПЕРЕГОВОРЫ #3

Итак, у нас есть цели и интересы сторон. Мы определили переговорные позиции. Даже разобрались, где слабости и смогли усилиться. Что дальше?

А дальше последний шаг в стратегическом этапе подготовки. Это сама стратегия 🙂

Что есть стратегия в переговорах? Если упростить, это некий базовый сценарий, без детализации, который будет неизменным. Почему неизменным? Потому что войдя в переговоры и начав их, вы уже сделаете несколько шагов. Таких, что сказать “ой не, давай назад, начнем сначала” уже не получится. Поэтому стратегии надо уделить достойное внимание.

Простой бытовой пример. Есть у вас сосед-чудак, который громко включил музыку. Вы идете к нему провести переговоры. Стратегий здесь может быть несколько:
1. Бить морду
2. Угрожать (силой, связями, законом)
3. Давить на соседские человеческие чувства (“ну мы же соседи, ну что мы не договоримся что ли”)
4. Давить на жалость (“дети спят”, “я со смены”, “собака пугается и воет”)
5. Договариваться (“давай щас тишина, а я после 6 свалю и врубай сколько хочешь, чтоб стекла тряслись”)
Ну и т д. Много вариантов стратегии.

И обратите внимание. Выбрав одну, изменить стратегию будет уже сложно или почти невозможно. Да, можно попробовать угрожать, а потом бить морду, если не получилось. Здесь прям исключение из правил, хорошо сработает. Можно давить на соседские чувства, если не получилось – давить на жалость, если не получилось – договариваться. Но с каждым таким “переобуванием” ваша переговорная позиция будет все менее и менее устойчивой, и победить будет сложно. Ну а вариант сначала бить морду, а потом давить на жалость совсем не прокатит. Поэтому над стратегией надо думать заранее.

Как выбрать правильную стратегию? Это я не знаю. Да и никто не знает. Это чисто креативное решение, как вести себя в каждой конкретной ситуации. Поэтому для конкретного кейса я могу нагенерить идей, а вот абстрактно – нет. Какого-то правила или модели я не знаю.

Но здесь важно вот что. Стратегию вы выбираете заранее и только 1 раз. А значит она должна учитывать все гипотезы и допущения, которые у вас появились на предыдущих этапах подготовки к переговорам. Ошибаться здесь нельзя, от этого зависит ход переговоров.

Но есть и хорошая новость! Иногда стратегию можно провалидировать. Придумать себе проверочный вопрос или действие, за которым последует безоговорочный выбор стратегии и дальнейшие переговоры по ней.

С тем же соседом. Позвонить в дверь и посмотреть на него. Если он шкаф – ну как уж тут бить морду. Придется давить на жалость. А перед тем как давить на жалость, можно спросить: “а вот у вас есть дети?”. Если скажет “да”, то вот вам и стратегия – давить на жалость через детей. Если скажет “нет”, то просто договариваться и все. Или еще задать пару проверочных вопросов. Только не увлекайтесь.

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

Продолжение следует.

ДАЙДЖЕСТ ЗА ПОСЛЕДНИЕ 2 НЕДЕЛИ

Статья про стаффинг и распределение людей по проектам - наша история 21 года, эксперименты и подходы, которые сработали

Пост с примерами использования People Status - несколько реальных кейсов, где инструмент нам помогал

Ответ на вопрос про особенности управления большими проектами - мое скромное мнение, поскольку реально большими проектами я не управлял, не приходилось

Пост про модель Берна - границы, круги, влияние и вот это вот все

Статья про офферы - как их делать правильно, так, чтобы их принимали

Анонс нового курса Delivery Manager - курс на OTUSe, в разработке которого я принмал самое непосредственное участие

Пост про модель Герчикова - типы мотивации, особенности применения, OR или XOR

Пост про переговоры #4 - продолжение треда про то, как готовиться к переговорам

Также напоминаю про форму, через которую можно задать вопрос или прислать свой кейс, а я сделаю подробный разбор. Хотите - анонимно, хотите - нет

Напоследок перед выходными!

Буду выступать с МК на Skolkovo Tech Week с темой “Тимлид – ключевое звено в изменении корпоративной культуры”. Ищите меня в потоке MANAGEMENT.

Как спикер, получил промокод PRAHT на скидку 20%, для активации переходите по ссылке https://techweek.moscow/ticket?utm_source=sm_spkr

Про мероприятие:
Что важно для современного предпринимателя?
Быть в курсе последних трендов на рынке, а также уметь собрать сильную команду.
Об этом и многом другом вы можете узнать на крупнейшей технологической конференции России - TECH WEEK 2023 @russiantechweek
Что там интересного:
• Тематические выступления по 12 потокам, выступления экспертов на актуальные темы и мастер классы;
• Нетворкинг - соберёте самые ценные контакты, найдёте партнеров и близких людей по духу, а еще можно тусануть на AfterParty;
• Практика - разберёте кейсы, сделаете задания, изучите предметно рабочие инструменты;
• Выставка актуальных решений для бизнеса в сфере технологий, инноваций и технологического сервиса.

Видео вчерашнего вебинара "Я тимлид. Что дальше?".
Там рассказывал про роль Delivery Manager-a и про курс, который запускаем.
https://youtu.be/088kMp_L8Ok

МОДЕЛЬ МАМОНТА

Продолжая тредик про инструменты аудита команды, хочу немного поговорить про общую цель. И один из инструментов для этого за авторством Стратоплана - модель Мамонта.

Идея инструмента простая. Команда будет лучше работать, эффективнее взаимодействовать и быстрее проходить все сложные кризисные этапы, если у них будет единая общая цель, в которую верят и которую разделяют все ее члены.

Возможно ли это? Ведь не зря есть разные модели мотивации, например. Очевидно, что все хотят чего-то своего и разного. Вот тут то нам и приходит на помощь Мамонт.

Есть некоторая команда, группа первобытных людей. И у них есть общая цель команды - завалить Мамонта. Мамонт - это еда, чтобы поесть. Это шкура, чтобы было тепло. Это кости, из которых можно делать оружие. Ну а кроме того, завалить мамонта - это же престиж, уважение в племени. Вот и получается, что цель вроде бы одна и общая, но каждый найдет в ней что-то для себя: голодный - еду, тщеславный - уважение, и т д.

Таким образом первая идея модели Мамонта - цель должна формулироваться вдохновляюще и не особенно конкретно, и должна легко декомпозироваться на составляющие, которые будут интересны каждому члену команды.

Например, целью может быть “вовремя сдать релиз”. Что это значит? Да кто бы знал) В том и прелесть, конкретные ключевые результаты превратят цель в проект, и мотивации конец. Поэтому нужен вектор и какой-то конкретный критерий, без лишней детализации. Например, когда в роадмапе поменяется статус на “Сделано”. А там, сколько багов должно остаться, какой уровень качества и т п вопросы - операционка, это не про вдохновение.

И опять же, в общей цели “вовремя сдать релиз” каждый найдет что-то свое. Кто-то премию, кто-то повышение, кто-то ощущение причастности к большому общему достижению, кто-то возможность больше не работать по выходным.

Ну а вторая идея модели - слона нужно есть по кусочкам. Нельзя просто взять и завалить мамонта. Сперва нужно собрать народ, раздать всем оружие. Потом найти мамонта, окружить его. Далее напасть и победить. Несколько шагов, которые прозрачно демонстрируют, что вы на верном пути, и мамонт вот-вот будет побежден.

Также и с релизом. Нужна декомпозиция, на майлстоуны, поставки, этапы процесса. Как угодно, но чтобы было понятно, что команда движется к цели, а не стоит на месте.

В такой форме общая командная цель будет работать правильно, и команда будет к ней двигаться сообща. И завалит в итоге своего “мамонта”.

КАК РАЗВАЛИТЬ КОМАНДУ

Вот мы всегда с вами обсуждаем, как сделать правильно, как сделать хорошо. А сегодня хочу накидать наоборот, вредных советов. Ну а как их применять – уже решать вам.

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

- Врать / недоговаривать – ни слова правды, только удобная и правильная информация
- Молчать, ничего не рассказывать – утаивать любые сведения, ставящие под угрозу спокойствие в коллективе
- Рассказывать, как все плохо – побольше и почаще, желательно с эмоциями и примерами
- Обещать и не выполнять – открыли коробочку с обещаниями, достали нужные, выдали, а как спросили за результат – снова открыли коробочку, достали новое обещание, выдали
- Включить гиперконтроль и микроменеджмент – кризис, не время для инициативностей и свободы, все это от лукавого
- Все изменения пропускать через людей – не зря же ваш менеджмент их придумывает, все должно сразу же докатываться до конечных исполнителей
- Снимать с себя любую ответственность – “а я чо, это все начальство куролесит” и все в таком роде
- Забить на сотрудников – да просто не тратить на них время, зачем

Конечно, в каждой шутке есть доля шутки. И на самом деле это не советы никакие, а типичные ошибки, которые начинают делать руководители в работе с командами. Особенно, когда ситуация начинает двигаться в сторону кризиса.

И прочитав их, я уверен, каждый подумал: “Да это же очевидно, блин!”. Очевидно, все так. Но люди снова и снова наступают на одни и те же грабли, хотя часто знают заранее, где они лежат.

Наверняка, список неполный. Накидайте своих идей вредных советов, чтобы мы обогатили вместе этот материал.

Погнали!

ПРО УВОЛЬНЕНИЯ #1

Давайте сегодня поговорим о самой неприятной задаче менеджера – об увольнениях.

Увольнять сложно. И я не встречал людей, которые бы получали от этого процесса удовольствие или заряд энергии. Чаще всего, наоборот, требуется потом время, чтобы прийти в себя и вернуться к работе.

Почему так? Виной всему наш мозг и психика. Руководитель – он же для чего? Он про бизнес, достигать целей компании, добиваться результатов. И с этой точки зрения, любое увольнение – просто задача. Специфическая, но задача. Ни больше, ни меньше.

И все бы ничего, но мы люди. Все руководители! И ни одному человеку (если он здоров) не хочется причинять боль и страдания другому человеку. А увольнение для сотрудника – это то самое и есть, как минимум хороший такой выход из зоны комфорта. Поэтому вторая наша половина хочет избежать такой задачи всеми силами.

Вот и получается внутренняя шизофрения – внутри борются менеджер и человек. Кто победит?

Чаще всего, человек побеждает ровно столько, сколько может это делать. Все время пытаешься оправдать сотрудника, дать ему второй-третий-двадцатый шанс. Еще мое любимое – копаешься в себе и ищешь причину там. Вроде как “это не сотрудник делает фигню, а это я ему недостаточно качественно задачу разжевал”. Ну и т п.

А потом человек сдается. Либо когда уже “ну все, хватит это терпеть”, либо когда просто все попытки исчерпаны и менеджер внутри победил. И в этот самый момент наступает точка принятия решения – “все, увольняю”.

Но принять решение мало, надо еще и реализовать. Хотя, сказать по чести, сложнее решиться, нежели поговорить с сотрудником. Ну во всяком случае, про себя могу так сказать.

Чтобы победить этот внутренний конфликт менеджера и человека в своей голове, в определенный момент я придумал для себя некую мантру, которую с радостью всем рассказываю. Вдруг кому-то тоже подойдет.

“Принимать решение об увольнении нужно как менеджер, а реализовывать его – как человек”.

Иными словами, решение должно базироваться исключительно на интересах бизнеса. И все эмоциональные аспекты здесь нужно отключать. А уже потом, когда решение принято, нужно включить в себе человека, и сделать все так, чтобы ваш сотрудник не страдал и не печалился.

Во-первых, нормально и по-человечески с ним поговорить и все объяснить. Без казенщины и бюрократщины. Во-вторых, предложить помочь: рекомендации, контакты и т п. В-третьих, быть честным, не пытаться сэкономить навариться на этом. И в-четвертых, искренне поблагодарить его за работу и нормально попрощаться. Мир гораздо теснее, чем нам порой кажется.

Вот такой совет. Забирайте, надеюсь, пригодится!

А дальше расскажу, что может вам помочь с решением, и как потом подготовиться и провести разговор с сотрудником.

DISC

Завершаем тредик про аудит команды. Последний инструмент из еще не рассмотренных – DISC.

Причем здесь вообще психотипы и зачем нам это знать? Ну во-первых, чтобы понимать, как строить коммуникацию с человеком, какие типы аргументов для него будут весомыми, а какие – нет. А во-вторых, чтобы правильно формулировать задачи и выбирать нужный тип контроля.

DISC — акроним (как и все миллионы названий моделей в менеджменте, ага). Модель классифицирует людей на 4 типа:

- D — Dominance — Доминирующий тип — Достигаторы, воодушевленные дофамином, готовы браться практически за любую задачу, стремятся к результату. Для людей типа D (красные) характерны прямолинейность, креативность, готовность к риску и неприятностям

- I — Influence — Влияющий тип — Открытые, теплые, ставят комфортные отношения с людьми превыше всего. Для людей типа I (желтые) характерны общительность, дружелюбность, умение влиять на других

- S — Steadiness — Стабильный тип — Любят работать в отлаженных процессах, надежные, методичные, исполнительные. Для людей типа S (зеленые) характерны надежность, добродушие, умение выслушать каждого

- С — Compliance — Адаптивный тип — Аналитики, любят системность и четкость. Для людей типа C (синие) характерны аккуратность, осторожность, логичность, перфекционизм

Среди инженеров чаще всего преобладает «синий» психотип. Но других тоже немало. И каждый психотип, как я уже сказал, по‑разному реагирует на задачи.

D (красные) — это достигаторы, им важно делать работу ради работы, им просто комфортно в процессе. Поэтому они могут не дослушать задачу, сразу побежать ее выполнять. Они редко задают дополнительные вопросы, как в начале, так и по ходу дела. Поэтому главная опасность с такими сотрудниками — он со всей своей стремительностью сделает совершенно не то, что вы ждете. С такими сотрудниками лучше потратить дополнительное время на постановку задачи, убедиться, что он понял все верно. И лучше периодически пару раз проконтролировать, что все идет по плану.

I (желтые) — для таких сотрудников характерно 2 вещи. Первое — уход в абстракции, что иногда требует от вас объяснить задачу гораздо шире, чем это нужно, но ему важно сложить весь пазл целиком. Второе — уклон в творчество, т е им интересно придумать решение, но зачастую неинтересно его реализовывать. Поэтому с такими сотрудниками лучше применять поэтапный контроль, сначала разобрать идею, потом отдельные шаги в реализации, чтобы он не сваливался в прокрастинацию.

S (зеленые) — для таких сотрудников важен комфорт, причем не только собственный, но и всех вокруг. Они могут задавать странные вопросы при получении задачи, которые, на первый взгляд, не сильно относятся к делу, но им важно убедиться, что они никому не навредят. Правда, их доброжелательность и открытость иногда играет с ними злую шутку. Если по ходу выполнения задачи они будут разговаривать с людьми, то легко могут поменять исходную задачу во имя всеобщего комфорта. Поэтому здесь подойдет либо поэтапный контроль, если вы четко можете выделить точки, где сотрудника может кто‑то «переубедить», либо просто периодический, чтобы исключить такой эффект.

C (синие) — системные перфекционисты. На этапе постановки задачи ждите от них много‑много вопросов, чтобы выяснить абсолютно все, любые риски и «планы Б» по задаче. А на этапе выполнения нужно бороться с тем самым перфекционизмом. Здесь можно использовать выборочный или периодический контроль, преимущественно ближе к сроку выполнения задачи.

Учитывая психотип сотрудника, можно подобрать более эффективный тип контроля, и добиться от него выполнения задачи в том виде, как вы ее поставили. Ну или, как минимум, вероятность этого сильно возрастет.

В среду, 24 мая, 19.00 мск будет вебинар "Как увольнять и не лишиться поддержки команды?" от OTUS.

Расскажу, как правильно вести себя тимлиду/руководителю во время сокращений, как не наломать дров и не демотивировать вообще всю команду.

Регистрируйтесь и приходите поучаствовать!
https://meetup.otus.ru/team-reduction

Собрал воедино весь тредик про инструменты аудита команды. Получилась развесистая статья. Зато теперь удобно, не надо скакать по разным постам 🙂
https://habr.com/ru/articles/736908/

ИДЕАЛЬНЫЙ МЕНЕДЖЕР (АДИЗЕС)

Концепция Адизеса, как мне кажется, является одной из самых популярных в менеджменте. Причин тому несколько. Во-первых, она действительно крутая. Простая, понятная, структурированная. Во-вторых, она очень хорошо перекликается с другими инструментами (ну например, тот же 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: Душа команды

Вот такой рецепт. Проверено – работает!

ПРО УВОЛЬНЕНИЯ #2

Продолжаем тредик. Предыдущий пост был про разделение решения и его реализации. О том, как правильно относиться к увольнениям. Теперь давайте поговорим о том, как это самое решение принять.

Первое, что может помочь – инструмент “ошибка/проступок”. Если четко понять разницу между ними, становится гораздо проще.

И ошибка, и проступок – это некоторые неверные действия сотрудника в той ситуации, когда последствия были заранее неизвестны. Ну потому что если последствия известны, то это откровенный саботаж, и тут думать уже нечего, гнать в шею и все. Иными словами, у человека было какое-то позитивное намерение и он хотел сделать, как лучше, но не получилось.

А главное отличие между ними – было ли определено заранее, что нужно делать правильно. Если не было – человек не знал, как себя вести, скреативил в меру своих возможностей, результат не удался. Если было определено – человек поступился правилами (хотя и с некоторым позитивным намерением, повторюсь), и результат оказался логичным.

Приведу пример. Был у нас один инженер на проекте поддержки. И как-то раз он налил себе чай, и тут вдруг позвонил заказчик. На звонок он, как и положено, ответил, долго инструктировал заказчика, отвечал на его вопросы. И параллельно смачно серпал чаем прямо в трубку. После такого разговора заказчик нажаловался начальству и пришлось разбираться. Естественно, сотрудник просто не подумал, что это может вызвать дискомфорт, оттого и сидел прихлебывал, не заморачиваясь. Мы просмотрели все основные инструкции для инженеров поддержки, и убедились, что подобные кейсы нигде не описываются. Значит, заранее определено не было, перед нами ошибка.

Но этим все не закончилось. Мы учли проблему, прописали в инструкции, что нельзя серпать и чавкать в трубку. Оформили в презентацию, разослали всем сотрудникам поддержки. Сделали свою работу над ошибками. А спустя пару недель этот же сотрудник повторил тот же трюк, но уже с другим заказчиком. А заказчик не был оригинальным, и также пожаловался. Т е сотрудник уже знал правила, и просто их проигнорировал. Не сознательно, просто не заморачивался и все. Этот кейс был трактован нами, как проступок.

Так вот, за ошибки не увольняют. Ошибки, как правило, подсвечивают системные проблемы: изъяны процессов, недоработку руководителей и т п. Ну и в конце концов, все люди, все могут делать ошибки. А вот проступок не подсвечивает ничего, кроме того, что сотрудник игнорирует правила. Игнорирует ваши с ним договоренности, контрактинг. И вот за проступки увольнять стоит. Сразу же или дать шанс – решать вам. Но обратить на это внимание и обработать такую ситуацию точно следует. Самым жестким образом.

И еще один момент. Необработанная ошибка – это проступок руководителя. Любая ошибка должна быть исправлена. Причем исправлена в будущее, чтобы предотвратить повторение. И это задача руководителя.

И вопрос на подумать – что делать с теми, у кого эти ошибки повторяются постоянно, раз за разом. Ситуация же неоднозначная. Может руки неправильно растут, а может в процессах такой бардак, что чуть шаг влево или шаг вправо – и непонятно, что делать. В таких кейсах рекомендую посмотреть пристально на систему. И если с ней все ок и дело в сотруднике – тоже повод задуматься.

Продолжение следует.

Видео вчерашнего эфира "Как увольнять и не лишиться поддержки команды?"

https://www.youtube.com/watch?v=s4_ynRUy4a8

Постарался "на пальцах" объяснить, как вести себя руководителю, если он должен провести волну сокращений, чтобы при этом сохранить и саму команду, и приемлемый уровень ее продуктивности.

Внутри немного рекламы OTUSа, но и контент, вроде бы, ничего 🙂

МОДЕЛЬ БЕННА И ШИТСА

Готов поспорить, про эту модель вы раньше не слышали. Во всяком случае, я сам на нее наткнулся совсем недавно. В отличие от популярных Такманов и Белбинов, про эту модель почти никто не говорит и не пишет. А зря.

Это снова модель про командные роли. Выделяется 3 основных уровня ролей:
1. Целевые роли – роли, связанные с выполнением непосредственно работы
2. Социальные роли – роли, способствующие позитивному функционированию коллектива
3. Дисфункциональные роли – роли, замедляющие продвижение к цели и ослабляющие сплоченность коллектива

Целевых ролей порядка 12. Они декомпозируют и дублируют роли действия и, частично, интеллектуальные роли Белбина. Так что ничего особенно интересного.

Социальных ролей 6. С ними та же история, только они декомпозируют социальные роли Белбина. Так что тоже пропустим.

А вот дисфункциональные роли – это что-то новенькое. Бенн и Шитс выделили 9 таких ролей:
- Агрессор
- Блокирующий
- Ищущий признания
- Исповедник
- Нарушитель/Бунтарь
- Playboy/Playgirl
- Доминирующий
- Ищущий помощи
- Преследующий свои интересы
Думаю, пояснять не нужно, из названия понятно, кто из них про что.

Так вот, основная идея модели включает 2 шага:
1. Проверить наличие Целевых и Социальных ролей, добавить недостающие и создать баланс
2. Отыскать все присутствующие в команде Дисфункциональные роли и устранить

Как устранить? В позитивном сценарии – перевоспитать плохиша. В негативном – убрать из команды.

А далее наблюдать и держать руку на пульсе, реагировать, как только подобные роли снова начнут зарождаться и прорастать.

В чем профит модели? В систематизации этих дисфункциональных ролей. Ведь если знаешь что искать, то искать гораздо проще. И по каждому типажу есть набор понятных причин появления, и проверенных методов исправления ситуации.

Вот такой инструмент в копилочку. Как по мне – полезный.

ДАЙДЖЕСТ ЗА ПОСЛЕДНИЕ 2 НЕДЕЛИ

Анонс моего МК на Skolkovo Tech Week - 28 июня в секции MANAGEMENT, буду рассказывать, как тимлид может стать ключевым звеном в изменении корпоративной культуры

Видео с вебинара "Я тимлид. Что дальше?" - рассказывал про роль Delivery Managera и про курс, который запускаем в OTUS

Пост про модель Мамонта - простая модель для целеполагания команды

Пост про то, как развалить команду - отпичные ошибки руководиелей в формате вредных советов

Пост про увольнения #1 - о том, как относиться к увольнениям, как научиться принимать эти решения

Небольшой кейс - проведенное корпоративное обучение по наставничеству

Пост про DISC - простая модель типизирования психотипов

Ссылка на статью про инструменты аудита команды - собрал в одном месте весь тредик из чата

Пост про идеального менеджера по Адизесу - как и чем можно дополнять себя, чтобы его добиться

Пост про увольнения #2 - разбор отличия ошибки и проступка, за что нужно увольнять

Видео с вебинара "Как увольнять и не лишиться поддержки команды" - о том, как вести себя руководителю, если ему приходится заниматься сокращениями, чтобы команда не развалилась

Пост про модель Бенна и Шитса - не самая популярная модель, выделяющая основные дисфункциональные роли в команде

Продолжение следует!

ВОПРОСНИК #14

Вопрос от @darya_samoylenko по мотивам вот этой статьи.

Вопрос:
Здравствуйте! Очень понравилась статья про People Management, подскажите, пожалуйста, в каких программах вы измеряли Тим-мораль и какой ERP-системой вы пользовались для измерения People Status?

Ответ:
Перво-наперво, спасибо за ваш вопрос, Дарья, и за фидбек. Рад быть полезным!

По поводу тимморали – мы использовали испокон веку гуглоформы, и их хватало. По сути, с этой ролью справится любая онлайн форма, в которой можно настроить поля с вопросами и потом выгрузить результаты в эксельку. В эксельку надо обязательно, чтобы можно было потом поиграться с цифрами: пофильтровать, поагрегировать, нарисовать красивые графики. Конкретно в гуглодоках есть еще обалденный функционал комментариев, с указанием ответственного. Позволяет тут же в одном месте делать все необходимые эскалации и обрабатывать все операционные вопросы.

Если говорить о том, что писать в форму (какие именно вопросы), то тут простор для креатива бесконечный. Мы старались использовать простые и не завуалированные вопросы, без лишней магии: как работается? чувствуешь ли, что развиваешься? комфортно ли тебе в коллективе? интересно ли заниматься задачами проекта? и т д. Можно попробовать более сложные версии, но я не знаю, есть ли смысл.

Теперь про People Status. Начинали мы также с гуглоформ. И это было неудобно, поскольку возникает проблема секьюрности. Мы пытались закрыть информацию об оценке человека от самого человека, и не показывать эту информацию никому, кроме руководителей человека и HR-ов. В простом варианте это означало примерно мильен разных форм и гуглодоков к ним, чтобы на каждую команду и на каждый уровень иерархии. А в сложном – когда кто-то переходил в другую команду или повышался, нужно было создавать новый файл. Почему? Потому что гугол хранит историю изменения документа, абсолютно всю.

По итогу функционал уехал в нашу собственную ERP-систему. Скриншоты в статье как раз из нее. Она самописная и чисто для внутреннего использования, поэтому поделиться, к сожалению, никак не смогу. Там уже проблем с секьюрностью не было, и все это связалось в единую информационную систему компании.

Некоторое время назад, когда мы выходили на рынок РФ, мы делали маркетинговый анализ. Искали похожие сервисы, как наша внутренняя ERP. Хотели сделать из нее продукт, смотрели перспективы. Так вот. Готового инструмента со встроенным похожим функционалом мы не нашли. На следующей неделе наши HR даже сделают доклад на HR-API по этому поводу 🙂

Но почти в каждом популярном инструменте есть функционал контроля и измерения eNPS. Что, по сути, похоже. Можно как-то поколдовать вокруг этого. Хотя это опять будут костыли и велосипеды. Но что поделать.

Для первого пилотного внедрения, как по мне, можно обойтись гуглодоками. Мы с ними жили долго, для команды до 100 человек с не очень сложной иерархией, в целом, приемлемо. А дальше, если зайдет, можно что-то простенькое написать.

Надеюсь, получилось ответить на вопрос.

P.S. Пишите свои вопросы и кейсы вот в эту форму https://forms.gle/aBX5PgU1CLU4FDPP8

В эту среду, 31 мая, в 20.00 МСК провожу открытый урок курса Тимлид в OTUS.

Будем разговаривать про риски - зачем это тимлиду, как этим всем управлять, без бюрократии и казенщины.

Зарегистрироваться можно по ссылке https://otus.ru/lessons/teamlead2-0/#event-2925