Зимний ProIT Fest: уже скоро! 

И я там буду 10 февраля в секции ТОП (C Level), поучаствую в 2 панельках:

- "CTO на максималках" - поделюсь своим видением роли СТО в аутсорсинговой компании, расскажу про несколько челленджей

- "Overqualified,проблемы роста C Level" - порассуждаю с коллегами, насколько эта проблема свойственна СТО, и какие есть варианты развития дальше из такой позиции

О мероприятии:

10 - 11 февраля, пространство FREEDOM в Санкт-Петербурге.

Секции Vision (Product, Design, Front, Marketing), C Level (CEO, CMO, COO, CTO, etc), BDSM (BizDev, Sales, Marketing), Разработка на Python (Dev, QA, DevOps, DS), System Design (Архитектура Бэка), HypeLoad (ИИ, Blockchain, Scrum и прочие тренды).

Зимний ProIT Fest - это:
🫰 11 секций в параллельных потоках
❄️ Более 70 спикеров
🥂 Ещё больше нетворка, интерактива и открытых диалогов вместо скучных докладов

Промокод на 20% для друзей: SEEYOU

ОПТИМИЗАЦИЯ БИЗНЕС-ПРОЦЕССОВ

Так уж вышло, что в январе у меня все дела про бизнес-процессы. Видеоурок для Eduson, СТО201 Стратоплана, корпоративный курс. В общем, было время и возможности поразмышлять на эту тему.

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

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

Откуда математика? Ну как же, а денежки посчитать? Любой БП он же не в вакууме живет, он для чего-то нужен. Наносит какую-то пользу, ее можно осметить. Себестоимость БП можно посчитать, по затраченным ресурсам, времени сотрудников и их ЗП. И в вопросе оптимизации, можно выгоду вычислить: сколько тратим, сколько дальше будет стоить поддержка, какой профит принесет изменение. В общем, денежки здесь самый главный игрок.

Ну а что же с самой оптимизацией? Неужели совсем ничего не подвезли в помощь несчастным менеджерам? Ну почему же, кое что есть. Есть 2 типа инструментов для оптимизации процессов:

1. Готовые шаблоны – просто берешь подходящий процесс из библиотеки и внедряешь себе. Это и любимый всеми Scrum, и Lean со своими Kanban-ами и другими готовыми практиками, и тот же ITIL. Ну и, конечно же, стандарт ISO, про который все слышали, но мало кто видел в глаза

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

Какие инструменты-идеи могут оказаться полезными (сейчас прямо кратко, если будет интересно – пишите, сделаю подробный разбор):

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

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

- 7 потоков потерь – еще один из инструментов Lean, специальный чеклист, где и в каких местах в производственных процессах бывают потери. Дальше берешь чеклист, берешь свой процесс, и ищешь одно в другом. Все, что нашел – под оптимизацию. Из плюсов – универсальность. Из минусов – абстрактность и субъективность

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

Среди идей для вдохновения есть и еще более абстрактные методы, вот прям на уровень стратегии уходящие:
- 6 сигм
- Total Quality Management
- Lean (бережливое производство) целиком, как подход
Но про них я здесь не буду писать, это целая философия, очень много букв и воды.

Наверняка, есть и еще что-то. Делитесь, если знаете и используете!

Ну а на сегодня пока все. Маякните, если было полезно.

Друзья, еще хочу поделиться с вами VK-версией этого блога.

Там тоже самое, но есть пара удобных фишек. Например, все видео в одном месте. И не только)

Присоединяйтесь https://vk.com/sedoydirector

КАК РАЗВИВАТЬ РУКОВОДИТЕЛЕЙ

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

В чем особенности? Почему нельзя делать те же матрицы, придумывать им также карьерные треки, устраивать ИПРы? Да можно, так-то. Где-то даже это имеет смысл.

Ключевых момента здесь 2:
1. Руководителей мало
2. Люди уровня синьор+ уже очень сильно отличаются друг от друга

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

Какие есть альтернативы? Я пропагандирую подход кадрового резерва. Давайте разберем чуть подробнее.

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

С точки зрения процесса:
1. Определение портретов по ключевым позициям
2. Ассессмент кандидатов в резерв, сравнение с наиболее подходящими для них позициями по портрету
3. Определение зон роста, составление ИПРа под конкретную позицию
4. Работа по развитию сотрудника, пока его компетенции не пригодятся для какой-то замены

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

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

Напоследок небольшой пример из жизни. У нас было порядка 20% инжинеров тимлидами: аутсорсинг, небольшие команды, много проектов. И потому для тимлидов мы сделали матрицы, карьерный трек, и следовали стандартному процессу развития, все работало. А вот Delivery Manager-ов было всего 5. И с ними шли по пути кадрового резерва, получалось эффективнее.

Друзья, хочу напомнить вам про dump! Питер, 17 февраля. И мне промик дали, делюсь

КАК ПЕРЕЖИТЬ СОКРАЩЕНИЯ

Читаешь последнее время новости (вот те, которые про бизнес, общемировые) и диву даешься: то одна корпорация сокращает кучу народу, то другая. Я именно про IT сейчас. Как-то штормит отрасль то. Причин и последствий разных много, я сейчас не про них. Хочется порассуждать про сам процесс сокращения.

Если вы, будучи руководителем, имели опыт сокращения команды (не просто разово выгнать лоуперформера или токсика, а вот так вот, чтоб несколько человек, да без явных на то причин, просто потому что бизнес по-другому не выживет), то согласитесь со мной, что задача эта крайне неприятная. Самая неприятная. Квинтэссенция всех самых неудобных и избегаемых задач менеджера.

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

Чем опасны сокращения? Есть 3 основных эффекта:

1. Падает эффективность команды – да-да, ролевой баланс развалился, Такман нам говорит о том, что пора запускать шторминг, а значит перфоманс на дне

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

3. Разваливаются неформальные связи – еще вчера вы ходили вместе в курилку или на обед, а сегодня уже и не с кем, повод задуматься, а хочу ли я дальше тут работать…

Что делать руководителю? Как не потерять контроль?

Очевидно, нужно работать над этими 3 эффектами:

1. Выводить команду из шторминга – снова вспоминаем Такмана: явно распределяем роли, разрешаем все конфликты, выводим обратно в норминг/перформинг

2. Снижать тревогу – все проблемы здесь от недосказанности, из-за информационного вакуума, а значит надо его убирать (вспоминаем матрицу доверие/прозрачность и повышаем доверие через прозрачность): объясняем все решения и поступки, рассказываем новости и планы, проводим совместные встречи, таунхоллы, тет-а-теты и т п

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

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

Ну и готовьтесь заранее кого-то удерживать. Практика показывает, что если мы хотим сократить 5%, в итоге теряем порядка 10%, потому что кто-то все-таки не справляется с таким ударом судьбы и уходит из компании. Это надо иметь в виду, закладывать в план сокращений, иметь готовые планы удержаний, хотя бы по самым ключевым сотрудникам. Мало ли чего.

А у вас были такие истории в практике? Как справлялись? Делитесь!

СТОП - СТО?

Что дальше, когда все абилки набраны, боссы полегли, и ты самый крутой СТО на местности? О том, что происходит за чертой достижения успеха в карьере готов рассказать Илья Прахт, CTO, тренер в OTUS, Стратоплане, ИТМО, Инфостарт, РДТЕХ, Moscow Business School, консультант и ментор с опытом 10 лет управления из 13 лет в IT. Илья прошел тот самый путь от новичка (младшего разработчика) до топ-менеджера компании, и теперь делится своим опытом в блоге “Седой директор”.

10 февраля на ProIT Fest в секции ТОП Илья будет участвовать в двух панельных интервью. Первая тема «CTO на максималках», где он расскажет о СТО в аутсорсинге как о ключевой роли в компании и составляющих в виде менеджмента, работы со стратегией и финансами, работы с данными. Илья поделится личными кейсами и челленджами из практики, чтобы можно было сравнить реальность с ожиданиями учащихся на курсах СТО и руководителей отделов.

Вторая тема «Overqualified. Проблемы роста C Level», где Илья разберет типовые варианты того, куда можно дальше двигаться из позиции СТО, вертикально и горизонтально, насколько часто возникают проблемы этого самого overqualified при поиске работы для C-level и какие есть альтернативы (затравочка - консалтинг).

Подключайтесь к обсуждению самых острых тем вместе с экспертами ProIT Fest. Билеты ещё в наличии!

#proitspeaker

КАК ЧАСТО ПРОВОДИТЬ 1/1

Недавно на тренинге разбирали коммуникацию с сотрудниками, обратную связь, встречи 1/1 и т п. И получил интересный вопрос: а как часто нужно встречаться с сотрудниками 1/1?

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

Получатель выгоды #1 – руководитель. Встречи 1/1 помогают контролировать работу, синхронизироваться по операционным задачам, понимать мотивацию сотрудника. И как часто встречаться будет зависеть от привычного вам уровня контроля и объема задач, которые находятся в вашем фокусе внимания.

Получатель выгоды #2 – сотрудник. Встречи 1/1 помогают получать квант внимания своего руководителя, дают возможность обсудить с ним накопившиеся вопросы и проблемы, а также получить ценную обратную связь. И здесь периодичность встреч будет зависеть уже от сотрудника – как часто ему нужно внимание от руководителя. Встречаетесь слишком редко – он грустит. Встречаетесь слишком часто – он снова грустит, жалуется, что работать некогда.

В моем опыте были встречи и раз в неделю, и раз в месяц, и раз в квартал. С некоторыми сотрудниками прямо договаривались: “нет нам смысла встречаться каждую неделю, давай сделаем раз в месяц”. С некоторыми была лотерея, приходилось угадывать. Важно помнить про выгодополучателя #2 – сотрудника. И всегда иметь в виду, что встреча 1/1 – она для сотрудника. Порой, она ему нужнее, чем вам. Вы то итак придете к нему, если понадобится. А вот он – не факт.

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

Это нормально, иметь разную периодичность встреч с разными сотрудниками. И это нормально, менять с течением времени эту периодичность. Все в ваших руках.

ПОЧЕМУ БУТЕРБРОДНАЯ ОС НЕ РАБОТАЕТ

Продолжаем тему коммуникаций с сотрудниками. На этот раз – пару слов про обратную связь.

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

В чем проблема, и почему бутерброды не работают? А перечитайте еще раз пример – какие эмоции у вас вызвал бы такой диалог? Полагаю, что это будет следующее: “Я красавчик. Да, там есть какие-то небольшие изъяны, но в целом все довольны”.

Угадал? Бутербродная ОС очень сильно срезает углы. И как бы вы ни пытались превратить такую обратную связь в критику, все равно получается что “в целом все ок”. Неоднократно в практике напарывался на ситуации, когда человеку вот такую обратную связь доносят раз за разом, дело идет к увольнению, а он искренне и не понимает этого. Не прикидывается шлангом, а прям не понимает.

Какие есть альтернативы? Да их много: BOFF, SOR, STAR, STARAR, … Очень много моделей, все они примерно про одно и то же: убирать эмоции, давать сухие факты, показывать причинно-следственную связь. Задача была поставлена так → Ты сделал так → Эффект вот такой. “Документ должен был быть готов к пятнице → Ты сделал очень круто и качественно, но только во вторник → Весь план проекта поехал и теперь придется его нагонять всей командой”. Сплошной конструктив, и только одна единственная эмоция: либо похвалить, либо поругать.

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

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

ПСИХОТИПЫ И КОНТРОЛЬ

В чем польза психотипов? Да, странный вопрос) Природа так придумала, что они разные, не нам решать.

Сформулирую иначе: в чем польза понимания психотипов для руководителя? Зачем нужны все эти DISC, PAEI, PCM и иже с ними?

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

Для начала, вспомним про DISC. Модель классифицирует людей на 4 типа:

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

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

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

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

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

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

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

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

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

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

ДЕЛЕГИРОВАНИЕ ЧЕРЕЗ ПРОЦЕСС

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

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

Еще раз – почему это хорошо:
- У сотрудников есть четкие инструкции
- Есть понятные критерии оценки результата (это ж бизнес-процесс)
- Сделали 1 раз и дальше пользуемся, не тратим время на каждую задачу

Но встает логичный вопрос – а как не потерять свой фокус внимания? Как сохранить тот самый контроль, и ту самую возможность принимать ключевые решения?

Тут есть 3 варианта, давайте рассмотрим их в порядке снижения вовлечения руководителя:

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

2. Метрики и KPI – вводим систему метрик, глядя на которые можно в любой момент времени понять, хорошо ли все идет. Например, глядя на velocity команды и прогнозируемую дата завершения работ можно либо успокоиться, либо разволноваться, если вырисовывается совсем не позитивная картинка будущего. Важно в таком варианте не забыть про некий “стоп-кран”, какой-то механизм, позволяющий тормознуть процесс. Это может быть письмо, может быть “вызов на ковер”, может быть специальная кнопка в ERP-системе, все что угодно

3. Правила и инструкции – это неотъемлемая часть любого бизнес-процесса, но с точки зрения контроля нас интересует глубина и подробность этих артефактов. Например, для процесса развития сотрудников можно создать матрицу компетенций и сетку грейдов с ЗП, и тогда решения о повышении/не повышении можно делегировать. А если добавить сюда методичку + шаблоны основных целей, то можно делегировать и построение ИПР сотрудника. Но здесь, как и в варианте с метриками, нужен какой-то “стоп-кран”. Потому что по сути, вы занимаетесь законотворчеством, а дальнейшее исполнение выходит из поля вашего наблюдения

Никто нам не запрещает комбинировать эти опции. Хоть все 3 сразу. Зависит от вашего желания вовлекаться, доверия, и уровня паранойи. Вы руководитель, и выбор контроля – ваша непосредственная обязанность, и ваше легитимное право.

КОУЧИНГ НЕ ТОЛЬКО ДЛЯ СОТРУДНИКОВ

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

Интересный вопрос увидел недавно: “а можно ли применять коучинг в работе со своим руководителем?” Т е наоборот, не вас коучит начальник, а вы его. Что думаете по этому поводу?

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

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

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

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

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

3. Донести обратную связь – не всегда начальники готовы к обычной ОС, и тут снова может помочь коучинг и возможность “поменяться местами”, чтобы показать, как его модель поведения влияет на вас. Простые вопросы вида “а представь себя на моем месте, как бы ты реагировал на то, что происходит?” могут сильно открыть глаза на чужую реальность

Итого, как минимум 4 варианта есть. Наверняка, можно вспомнить и еще. Так что коучинг помогает, и в работе с подчиненными, и в работе с начальниками. Главное и основное, как и со всеми инструментами, правильно его применять, ровно там, где он уместен. Не забивать гвозди микроскопом.

НЕГАТИВНЫЙ АНОНИМНЫЙ ФИДБЕК

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

Если тоже хотите получить бесплатную консультацию, заполните вот эту форму.

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

Как теперь дать фидбек тимлиду, если сотрудник попросил не использовать факты, которые мне сообщил? Как обозначить, что это важно менять и срочно, и как следить за выполнением?

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

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

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

Ну и далее по результатам предварительной подготовки у нас могут быть несколько основных сценариев.

Сценарий #1 – подтверждается конфликт Пети и Васи, остальных сотрудников команды все устраивает. Тогда нужно решать этот конфликт, можно взять на себя роль медиатора. Но анонимизировать фидбек, увы, не выйдет. И тогда нужно вернуть это сотруднику: “Я готов помочь разобраться в вашем вопросе, но мне нужно для этого посадить вас за общий стол, чтобы вы поговорили. Если ты не хочешь, то помочь я не смогу, конфликт останется вашим персональным”. Вроде, по-взрослому, пусть сотрудник сам решает, анонимность или решение проблемы.

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

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

Ну и в завершении – как потом следить? Через фидбеки от тех же сотрудников, через повторные анонимные сборы оценок тимморали, через 1/1 с самим тимлидом. Еще можно договориться о своем вовлечении в какие-то общие церемонии и процессы (дейлики, рестро и т п). Хороший источник информации, только надо это согласовать с тимлидом, чтобы он не воспринимал это как потерю доверия и микроменеджмент.

ТИМЛИД, КОТОРОГО НЕ ЛЮБЯТ

Написал небольшую статью - размышление (во многом философское), как тимлиду, да и не только тимлиду, любому руководителю, нравится всем и сразу.

https://habr.com/ru/companies/otus/articles/791816/

ТАЙНОЕ ИСКУССТВО ОПТИМИЗАЦИИ ПРОЦЕССОВ

Когда-то давно проводил эфир на эту тему. Наконец дошли руки написать статью. Плюс обогатил ее некоторыми полезными мыслями, которые появились в последнее время.

Приглашаю почитать https://habr.com/ru/companies/otus/articles/792634/

CTO НА МАКСИМАЛКАХ

Побывал я в прошедшие выходные на зимнем ProIT Fest, поучаствовал аж в 2 панельках. Было интересно, мероприятие получилось душевным, полезным. На уровне. Огромное спасибо организаторам, и персонально @ann4ony

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

Я представлял портрет СТО из аутсорсинга, рассказывал про наши истории реорганизации, повсеместного внедрения Scrum, построения структуры Delivery Manager-ов и тимлидов, релокации 22 года. Вспомнил, прослезился.

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

Еще один СТО был из стартапов, рассказывал, как они очень быстро должны были вырасти в несколько раз, как решали вопросы с наймом, поиском людей. И последующим управлением.

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

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

По мотивам одного из вопросов пытались собрать портрет идеального СТО. Я сказал, что это “капитошка”, и так не бывает – у каждой компании свои правила, свои ожидания. Очень уж многогранная роль. Но мы все сошлись в том, что СТО – про стратегию, про вижн будущего, и умение этот самый вижн реализовывать: через технологии, через команду и управление ею, через построение устойчивых систем в своем подразделении.

И это, по сути, выделяет человека, готового к роли СТО, от еще неготового. Умение не только руководить техническим департаментом сегодня, но и выбирать новые горизонты и направления, чтобы управлять им завтра. Вот такие мысли и инсайты.

Друзья!

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

ВАЖНО! Конференция оффлайн, в Питере, 17 февраля.

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

Погнали!

OVERQUALIFIED

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

Overqualified, если по-простому, это когда вы чересчур круты, компании так не надо. Это важно.

Итак, панелька. Здесь наши мнения категорически разделились, и это была реальная дискуссия, как положено быть панельке. Одни говорили, что слышать про Overqualified в C-level категорически странно, ибо на этом уровне ты сам решаешь, что делать, а что – нет, где ты qualified, а где – не qualified. Другие (и в том числе я) высказывались, что любая позиция в компании – это все-таки некоторая рамка: по компетенциям, по уровню ЗП, могут быть еще какие-то ограничения, локация например, и нет ничего удивительного, что кто-то в эту рамку не вписывается, даже будучи C-level руководителем.

Я здесь топил и продолжаю топить за одну очень простую мысль. Если конкретная компания не готова вас нанимать, это вообще не потому, что вы какой-то не такой. Просто матчинга не случилось. Компания ищет себе другого человека. И если на уровне линейных сотрудников все обычно проще (ищем мидла, синьор для нас будет overqualified, потому что не окупится), то с руководителями все немного сложнее.

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

Ну и деньги, конечно. Стартапу, который только-только набрал 20 разработчиков, и может даже планирует расти, не по карману будет матерый СТО, который управлял 1000 сотрудников. Он знает себе цену. И если он, все-таки, придет попробоваться в найм, ему, скорее всего, ответят: “Вы overqualified”. Просто не нужен такой, попроще нужен, и подешевле.

Как со всем этим жить?

Во-первых, понимать и осознавать. Чем выше ваш уровень, тем меньше потенциальных вакансий. А среди потенциальных еще меньше реальных. Найм инженера – порой One Day Offer, найм тимлида – сложный процесс отбора, найм СТО – вообще магия, которая должна случиться между кандидатом и СЕО. Так что надо закладывать больше времени на поиск работы, определять свои собственные критерии поиска.

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

И в-третьих, развивать нетворкинг и личный бренд. Компании редко идут сразу же с вакансией на hh, когда надо найти нового С-level-а. Это может выглядеть странно со стороны, вызвать какую-то молву, как внутри, так и снаружи. Оттого (и это вам любой рекрутер подтвердит) начинают сперва по своим контактам смотреть, есть ли там какие-то варианты. И круто, если вы оказались в списке этих контактов. Вдруг это та самая позиция с магией.

Вот такие вот мысли. Может, кому-то пригодится. У меня все.