Седой директор

Сделали на канале "ВТБ для бизнеса" небольшую шпаргалку про DISC, особенности разных психотипов, подходы к контролю и управлению.
Полезное

Друзья!

Возвращаюсь после длительного перерыва. И эта неделя обещает быть богатой на контент 🙂

Начнем с анонса. В эту среду, 24 апреля, в 15.00 мск проведем эфир вместе с Сашей Орловым, где поговорим о роли Руководителя Отдела (менеджера менеджеров), его компетенциях, полезных инструментах. И покажем курс Стратоплана, который таких РО готовит.

Мероприятие бесплатное. Регистрируйтесь и приходите!

ПРО ОТВЕТСТВЕННОСТЬ #2

Продолжение.

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

Мы потом его спросили, почему он так сосредоточен на проекте, а по сторонам не смотрит. И все подтвердилось. Он бы и рад, но первоочередной спрос с него – за результаты команды. А остальное – уже как повезет. Получается, чтобы где-то прибыло, надо, чтобы где-то убыло.

Отсюда решение по пункту Не может – давать ресурсы, расставлять правильные приоритеты, давать возможность для этой ответственности. Было и про это в ваших комментариях.

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

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

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

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

ПРО ОТВЕТСТВЕННОСТЬ

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

А теперь, как и обещал, поделюсь своей историей и своими мыслями.

Говоря об ответственности, о безответственных сотрудниках, о необходимости передачи ответственности, все время вспоминаются классические 4 причины. И не зря. Реально, инструмент сюда подходит, как нельзя прекрасно.

Человек делает что-то не так или не делает что-то (в нашем случае не берет на себя нужную нам ответственность) по 4 потенциальным причинам:
1. Не понимает
2. Не умеет
3. Не может
4. Не хочет

Давайте теперь разберемся с каждым пунктом подробнее.

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

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

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

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

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

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

Пост получился длинный, поэтому разбил на два. Продолжение следует.

БИГ-БОССЫ И ИХ РАДАРЫ

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

Вопрос:
Подходит к концу испытательный срок. Отношения с руководителем получилось выстроить, все ок. Каких-то взаимодействий с начальником +1 уровня не было, и пока не предвидится.

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

Ответ:
Поскольку инициативы от самого руководителя уровня +1 не поступает, ждать ее и не следует. Надо брать все в свои руки 🙂

Можно решать задачу в лоб – попросить тет-а-тет с +1 руководителем, обсудить с ним свои желания, договориться о совместной работе и о каких-то задачах. Будет ли это хорошо? Скорее всего, нет. Потому как ваш непосредственный руководитель может отреагировать не совсем благосклонно, оценить это, как прыжок через голову. Итого можно благими намерениями испортить себе важные рабочие отношения. Может быть, даже самые важные. На текущем этапе.

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

Важно! Непосредственный руководитель может отреагировать иначе. Почувствовать угрозу. Закрыться. И тогда ничего у вас не выйдет. Совсем. Но тогда стоит и осознать, что роста в компании у вас не будет, во всяком случае, при этом начальнике. И тогда надо ли оно вам вообще тут надолго задерживаться? Почитайте по этому поводу Литвака, очень круто расписывает эту тему.

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

P.S.
Если вам тоже нужна консультация или менторинг, пишите мне в личку @ilya_prakht и мы договоримся!

А если хотите получить бесплатную консультацию, то задавайте свой вопрос в форму

ПРО ТОКСИЧНОСТЬ

Друзья, а что вы думаете про токсичность? Плохо это? Или хорошо?

Как по мне, токсичность в команде, это как лампочка “Check Engine” в машине. Да, неприятно, когда она горит. Бесит прямо даже. Но пусть лучше загорается вовремя, пока я еще могу ехать. И если долго ее игнорировать, то двигателю хана. И с командой точно также.

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

Поэтому крайне важно докопаться до сути. Лечить симптомы – не очень эффективно. Да и как их лечить то? Отругать? Премии лишить? Уволить? Как-то нет хороших методов в арсенале.

В общем, первый шаг прост и банален – разговаривать, задавать вопросы, разбираться. Второй уже может различаться.

Допустим, узнали мы, что дело не в работе. Совсем. Кризис у человека, личностный, возрастной, не важно. Может случилось чего в жизни, образ справедливости порушился. Вот он и пытается как-то себя найти в пучине негативных эмоций, и выражается это все в чрезмерную критику, всего и вся. Как быть? В таких кейсах я старался разговаривать, как взрослый со взрослым. Показать, как его поведение влияет на работу и команду, спросить, готов ли он что-то с этим сделать. Чаще всего, договориться получалось. Либо человек говорит по-взрослому, что ничего менять не может, и тогда обсуждаем оффбординг.

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

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

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

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

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

А как вы работаете с токсичными кейсами?

ВОПРОС В ЗАЛ

Друзья, привет!

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

А вопрос следующий:
Как воспитывать в сотрудниках ответственность?

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

Тут нужна трансформация прямо в культурном коде уже. И вот как это делать?

Делитесь своими решениями! У кого были такие задачи, как удавалось побеждать?

МЕНЕДЖЕР ПРОЕКТА БЕЗ ТЕХНИЧЕСКОГО ОПЫТА

Карьерный вопрос от Михаила @dulitman

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

Ответ:
Менеджер проектов в IT – штука крайне интересная. И, почему-то, эта роль часто отличается от классического руководителя проекта. Определенно, есть некоторая специфика по части используемых подходов (всякие Agile-ы, Scrum-ы и т п). И гораздо больший фокус на координаторских задачах, нежели менеджерских. Итого, ПМ в IT – координатор, владеющий специфическим инструментарием. Не везде, но часто.

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

Насколько я понимаю позицию инженера ПТО, это очень близко к ПМу. А значит, разрыв менеджерских компетенций можно закрыть довольно быстро. И пробовать управлять IT-проектами. У меня много примеров перед глазами, удачных и не очень. У людей получалось.

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

А теперь главное НО. Уровень погружения в ПМа в технику - это не rocket science. Вот совсем нет. Базовый уровень технической грамотности, некоторые нюансы конкретного проекта. Код тут писать не надо. Даже читать не надо. Надо понимать, что инженеры говорят. Все это прокачивается. Нужно время и много-много желания для этого. Но все достижимо. И таких примеров у меня, повторюсь, перед глазами было много.

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

Мир IT большой, компаний и проектов много. Выбирайте на старте что-то попроще (вплоть до сайтов на движках, например), выделяйте силы и время на саморазвитие, и двигайтесь плавно к более сложным проектам и более сложным позициям ПМ. И все получится!

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

СКОЛЬКО МЯСА В КОЛБАСЕ, СКОЛЬКО РАБОЧЕГО ВРЕМЕНИ В РАБОЧЕМ ДНЕ?

Немного запоздалый ответ на очень интересный вопрос. Автор пожелал остаться анонимным.

Вопрос:
Живем командами по Scrum. Оцениваем задачи в "чистых" часах, следовательно капасити = количество рабочих дней * количество чистых часов в дне. (чистые часы - часы, которые конкретно работаешь не отвлекаясь: берем рабочий день, минусуем среднее время на перекуры, консультации и прочие не планируемые вещи).

Возникла ситуация что разные команды по разному оценивают количество "чистых" часов на день. Читал что норма - 5 часов в день, но некоторые команды смогли выйти на 6-7 часов, а в каких-то командах при переходе с 5 часов на 6 возникает негатив. Контекст еще такой, что в этих командах присутствуют токсики и это может быть просто попытка манипуляции.

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

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

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

Если команды работают сообща, например в реализации любого Scaled Agile Framework, то общее понимание размера сторипоинта нужно. Но там и скоуп общий, как раз. Если команды работают изолированно – большого смысла в этом нет, все равно будут расплываться.

Я бы считал объем “чистых часов” по факту. Сколько времени за спринт команда списала на проектные задачи? Сколько на коммуникации и ритуалы? Сколько на какие-то вообще внепроектные активности, аля встреча с HR, собеседование новичка, собрание с директором и т п? Вот исходя из статистики полезной утилизации за определенный период можно выделить эту норму. Не наугад, а на основании фактических данных.

Для Scrum нормой считается порядка 80% полезной утилизации. Т е это порядка 6,5 часов в день. Вот вам и бенчмарк. Если у команды выходит 5 часов в день, значит она занимается фигней минимум 1,5 часа каждый день 🙂 Повод задуматься и проанализировать их утилизацию подробнее.

Но можно добиться и лучших показателей. Идеалом для консалтинговой компании будет порядка 85-90% утилизации. Мы у себя достигали 92%. Смотрите, на что тратится время сотрудников, насколько это необходимо для проектов, можно ли что-то оптимизировать. И получите свой ориентир “чистого часа”.

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

У кого какие идеи по теме – добавляйте!

НЕТЕХНИЧЕСКИЙ ТИМЛИД

Может ли не разработчик (продакт/проджект) быть эффективным руководителем разработчиков? Какие подводные камни могут быть?

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

У тимлида разработки, как правило, есть 3 основные зоны ответственности:

1. Команда – ресурсное управление, мотивация

2. Скоуп – сделать работу, которая ожидается от команды

3. Качество – технологическое качество продукта (архитектура, код) и QA. Иногда QA уходит куда-то в сторону

Функцию управления командой у тимлидов часто отбирают, уже научились с этим работать. Забирают себе ПМы, руководители следующего уровня (аля Engineering Manager) и т п.

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

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

Итого примерно 50/50 получается. Часть задач и зон ответственности нетехнический тимлид закроет легко, а часть – с пробелами. Но эти пробелы можно нивелировать. И тут может быть 2 варианта:

1. Силами всей (или части) команды – как в Scrum нам говорят, команда сама за все отвечает, кросс-ревью, общие грумминги, архитектурные коммитеты и т д

2. Введением роли техлида/архитектора – отдаем ему вопросы про качество и частично про скоуп, и все складывается. Главное, только, чтоб верный человек был, чтоб доверять ему можно было. А то будет тоже самое “Ой, там старое легаси, архитектура плохая, пришлось рефакторить …”, только на максималках

Итого, резюмируя – ответ ДА, МОЖЕТ. Подводные камни есть, но они закрываются. А по статистике, продакты и проджекты как-то лучше справляются с менеджерской работой, чем технари. Нет у них такого к ней отвращения, и нет желания (и возможности) занырнуть в код и забыть обо всем вокруг. Даже на время.

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

P.S. А форма для новых вопросов все та же, никуда не девается. Пишите свои вопросы, будем разбираться!

ДЕМОКРАТИЯ В КОМАНДЕ – ТЕРПЕТЬ НЕЛЬЗЯ ВМЕШИВАТЬСЯ

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

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

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

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

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

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

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

А вы что думаете?

Всем привет!

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

С 18-го марта (а это уже следующая неделя) буду тренером в Открытом практическом Университете Стратоплана.

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

Регистрация вот тут — https://stratoplan-school.com/university/

Ну а если вы не СТО, то есть и другие варианты! Там же будет практика по переговорам, для тимлидов, по управлению проектами и даже для СЕО.

И еще одним открытым уроком охотно поделюсь!

На этот раз курс "Руководитель отдела" Стратоплана. Слава там подробно рассказал про курс и формат обучения, а я поразмышлял о влиянии руководителя отдела/директора на бизнес, правильный фокус, помощь CEO и топ-менеджменту.

https://youtu.be/qlszBDeputM

ТИМЛИД УХОДИТ, КОМАНДА ОСТАЕТСЯ

Анонимный вопрос про моральную дилемму выгоревшего тимлида.

Вопрос:
Я тимлид команды разработки, в которую вложил очень много, строил её практически с нуля. За пару лет команда выросла с 5 до 20+ человек, и это только разработчики. Я привёл в команду много коллег с прошлых мест работы.

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

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

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

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

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

Ответ:
Я не психолог, но парой мыслей на этот счет поделюсь. И буду крайне благодарен профессиональным психологам (если есть среди нас такие) за комментарии по теме.

Во-первых, ваша команда – взрослые люди. Вы их не заставляли идти к вам работать, не обманывали их. Более того, если вы смогли построить такую команду, значит искренне верили, что все делаете правильно. Стало быть, упрекать вас здесь совершенно не в чем. Это был сознательный выбор взрослых людей. Так и не лишайте их такого выбора сейчас. Остаться в компании, пойти за вами или уйти на рынок – это будет их решение, и только их. Не считаю в данном случае аналогию с капитаном корабля верной.

Во-вторых, вы сами – взрослый человек. 2 ключевых слова! Взрослый – а значит вольны принимать решения, которые диктуются вашими обстоятельствами. Раньше было хорошо и/или вы готовы были терпеть и работать. Теперь не готовы. Вы имеете полное право на любое решение. И второе слово – человек. У вас есть жизнь вокруг, помимо работы, она тоже течет и изменяется, и ваши пути с компанией могут разойтись, это нормально. Взрослые люди из вашей команды вас прекрасно поймут.

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

Вот такие мысли. Что думаете? Добавляйте в комментах!

P.S. Задавайте и вы свои вопросы в форму, получите бесплатную консультацию!

На прошлой неделе проводил открытый урок в OTUS про "Компетенции и личные навыки операционного директора в IT".

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

Сразу не поделился видео - исправляюсь!

https://youtu.be/0DZ3VM6LkD4

ПРОКРАСТИНАЦИЯ ОТ ПЕРФЕКЦИОНИЗМА

И еще один интересный вопрос от @kai_penta

Вопрос:
Как можно помочь сотруднику со светлой головой и хорошими навыками побороть прокрастинацию от перфекционизма или страха «не всё понятно, сделаю фигню», из-за чего задачи откладываются на долгий срок пока не придёт просветление?

Ответ:
У такой проблемы может быть 2 решения: “дать рыбу” или “дать удочку”. Условно, пофиксить в моменте или научить человека не перфекционировать.

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

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

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

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

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

3. Размытая ответственность – часто бывает, что сотрудник не чувствует личной ответственности за содеянное, ну продолбал и продолбал. Надо тогда заставить его почувствовать. Продолбал задачу и заказчик орет – иди-ка сам с ним пообщайся, обсуди проблему. Не сделал вовремя задачу и релиз подвис (как положено по канонам в пятницу вечером), иди теперь в выходные доделывай и дежурь над релизом до понедельника. Ну и т д. Мы так с тимлидами делали как-то, очень сильно помогло поверить в культуру коммитмента

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

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

НАЙМ СТО И ИСПЫТАТЕЛЬНЫЙ СРОК

И еще один крутой вопрос, теперь от @sapatolog

Вопрос:
Найм СТО дорогой и долгий, а цена ошибки еще больше.
- Как максимально сократить вероятность ошибки на этапе отбора?
- Как оценивать СТО на испытательном сроке? Как-будто, результаты C-level так быстро не проявляются, но капец как не хочется через год сказать себе "я ошибся.."

Ответ:
С точки зрения найма, СТО мало отличается от любого C-level-а. Пожалуй, только вариантов специализации может быть много, что сильнее сужает воронку. А так, любого ТОПа нанимать трудно, дорого, и высока вероятность облажаться.

Как сократить вероятность ошибки? Мне в голову приходит несколько вариантов:

1. Сформировать небольшой, но емкий консалтинговый проект и пригласить кандидата его сделать. C-level-ы часто идут на такие форматы, а кто-то только в таких и работает, на самом деле 🙂 Это дает возможность посмотреть человека в деле, при этом не тратя огромных денег, ни на онбординг, ни на оффбординг и парашют, если вдруг чего. И еще это не подставляет команду и репутацию компании, потому как если не получится сработаться с СТО, то это ж не настоящий СТО, так, консультант просто, ничего страшного

2. Делать долгий и нудный процесс отбора. Многие играют в эту игру. Десятки собесов, с каждым руководителем компании, чтобы вот точно все приняли и можно было абсолютно все риски определить. В отличие от инженеров, которые разбаловались 1-2 интервью, для ТОПов длинный процессинг найма – это ок. Хотя и тут, конечно, во всем важна мера. Дело случая, дойдет ли ваш кандидат до конца или выберет какой-то другой оффер по пути

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

Как оценить результаты на испытательном сроке? В идеале – нужны маленькие победы. Не ставить глобальную цель сократить в 10 раз TimeToMarket или за год вырастить подразделение в 4 раза. А что-то близкое, но на квартал. Например, провести анализ проблем TimeToMarket, добиться его улучшения на 10-15%. Или сформировать операционную модель для команды, составить план по росту на год, реализовать какой-то первый шаг.

Таким образом, мы сокращаем риски ошибки найма СТО, но, конечно же, не исключаем полностью. Во многих вопросах человек все равно сможет раскрыться только за 6-12 месяцев. Но вариантов не сойтись становится, определенно, меньше.

Как можно увидеть, идеальный вариант – короткий консалтинг, с проектом на 3-6 месяцев. По результатам которого можно либо взять на фултайм в штат, либо продолжить консалтинг (тоже вполне рабочая схема очень часто), либо разойтись безопасно и безболезненно.

Но это все моя колокольня. Делитесь теперь вашей!

ВНИМАНИЕ ТИМЛИДА

Следующий вопрос от @alina_tr_FM

Вопрос:
Расскажите, пожалуйста, как тимлиду распределять внимание внутри команды: например, один коллега просто работает, а второй работает + постоянно хочет обсуждать свое состояние/настроение/отношения внутри команды.
К чему может привести такой перекос? Нужно ли его искусственно выравнивать?

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

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

А вот теперь про перекосы. Очевидно, от вашего внимания к сотруднику должна быть какая-то польза. Ваша польза! Например, он делает суперважную задачу, которую вы ему делегировали. Или он приносить 80% кода всей команды каждый спринт. Тогда оно того стоит. И вы сможете это легко объяснить, и самому себе, и команде. Вряд ли кто-то расстроится.

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

Я думаю, логика тут понятна. Есть польза – даем много внимания. Нет пользы – даем, как и всем остальным.

А всем остальным – это как? Вряд ли у вас получится зафиксировать единый для всех формат и в нем жить. Условно, 1/1 раз в неделю на полчаса и дейлики каждый день. Как уже рассуждали выше – люди разные. Но зафиксировать какие-то рамки, вилку своего внимания – вы можете. Условно, нормой считается 1-3 встречи по 30 минут в неделю с сотрудником. Если больше – думаем, анализируем, сокращаем.

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

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

КАК СОЗДАВАТЬ DREAM TEAM

Начинаем разбирать вопросы с розыгрыша. И первый – вопрос от победителя @qVlad : “как создавать dream team?”

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

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

И вот приходят нам на помощь сразу несколько инструментов. Давайте разбираться.

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

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

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

Ну и вот вроде бы сценарий сформировался:
1. Обозначить цель, на старте отбирать в команду людей, разделяющих эту цель
2. Навести порядок с перфомансом, устранить конфликты и прочие помехи
3. Навести порядок с ролями, отбалансировать состав команды

Чего не хватает такой команде до состояния dream team? Предположу, что крутого лидера. И это важнейший критерий.

4. Поставить команде настоящего лидера, который будет тащить ее вперед, своим примером показывая, как надо (или самому стать таким лидером).

Мне кажется, такой рецепт. А вы как считаете?

DUMP – ПОСЛЕВКУСИЕ

А вот и прошел первый dump в СПБ. Было довольно лампово и камерно. Примерно 400 участников, 4 трека.

Я весь день вел трек “Менеджмент”. Считаю его прям родным) Я был там в ПК, отсмотрел порядка 40 заявок, созвонился с доброй половиной заявителей, провел большинство тестовых прогонов. Даже полезных фидбеков раздавал. Даже учитывали его докладчики, что приятно.

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

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

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

2. Тема – не обязательно уникально, но обязательно актуально. Есть темы, которые зайдут всегда: конфликты, токсичность, метрики, деньги и т п. Есть темы, которые актуальны вот прям здесь и сейчас, в моменте. А есть темы заезженные, которые сразу идут под нож: удаленка, бирюзовые организации и т д. Не ошибитесь с выбором и покажите свой “изюм”

3. Презентация – нужны хорошая структура, красивая картинка для визуалов, динамика. Мне лично нравится строить структуру так: проблема – какое-то методическое объяснение – решение/инструменты – подтверждающие примеры – выводы. В целом, заходит неплохо. Ну и не забывать про динамику, на экране что-то должно происходить не реже 1 раза в минуту (новый слайд, буллит, подсвечивание/окрашивание/выделение и т п)

4. Выступление – подготовиться и потом держать внимание. Не забывайте про бытовые мелочи: таймер, кликер, вода, микрофон. Наблюдайте за зрителями, “дергайте” их, если количество опущенных в телефоны голов превысило 10%. Делайте интерактивы по ходу, в идеале – не реже чем раз в 5 минут

5. Тайминг – репетируйте и выдерживайте, оставляйте время на вопросы. Порой вопросы получаются ценнее для зрителя, чем сам доклад. Не лишайте его такой радости

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

Я часто помогаю спикерам готовиться к выступлениям, потому могу про эту тему писать много. Если интересно – маякните, продолжу.