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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Друзья!

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

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

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

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

УПРАВЛЕНИЕ РИСКАМИ В КОМПАНИИ

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

Как управлять рисками на проектах, в целом, понятно. PMBOK нам все про это рассказал: идентифицируем, оцениваем, приоритезируем, митигируем. Дальше контролируем. А как работать с рисками на уровне всей компании?

Во-первых, есть специальные стандарты. Их очень много. Есть общие и универсальные. Есть локальные. Есть специфические для отрасли, например, целая куча стандартов есть в банкинге. Наиболее интересные и популярные:

- ISO 31000
- FERMA
- COSO
- …

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

Во-вторых, есть совершенно классная модель “3 линий защиты”. Как понятно из названия, мы делаем 3 уровня работы с рисками:

1. Уровень функций – реализуется в каждом подразделении, выполняется мониторинг, контроль и реагирование на риски. Например, тимлид следит за исполнением требований ИБ своими сотрудниками.

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

3. Уровень внутреннего аудита – какой-то орган, чаще всего комитет, реже – прям выделенное подразделение, которое оценивает общее качество риск-менеджмента в компании, постоянно адаптирует процессы под стратегию компании. Например, изменение политик ИБ, если появились изменения ФСТЭК.

Чем интересен подход? Как по мне, он хорошо определяет не только управление рисками, но и общую методологию построения процессов в любой компании и любом отделе. Чтобы все работало, нужно 3 вещи:

1. Люди или команды, которые выполняют работу согласно процессу

2. Специальные роли, определяющие, как именно работать в рамках процесса, и контролирующие это

3. Дополнительный механизм пересмотра работы процесса и его согласованности с текущей реальностью

Вспоминаю, как мы внедряли Scrum. Тимлиды на местах и команды реализовывали фреймворк. Delivery Manager-ы определяли, как адаптировать Scrum к проекту, как его внедрять и как мониторить потом. Ну а топ-менеджмент давал добро или недобро на всякие изменения, когда того требовали новые цели компании или конкретный проект не мог раскатать тот процесс, который был нужен нам. Эдакие “3 линии внедрения Scrum”. Интересно 🙂

Вот такие мысли. И такие инструменты. Надеюсь, будет полезно.

Видео вчерашнего Openday Стратоплана "Руководитель отдела: Смена декораций в управлении людьми"

https://youtu.be/aONzCVfgxGo

Я тут поучаствовал в одной коллаборации. Полезной, как по мне. Ребята собрали в общую папку ProБизнес несколько авторских каналов (именно авторских, это важно), где люди пишут про менеджмент (как я), про стратегию, про ведение бизнеса. Есть что почитать.

Посмотрите, вдруг и вам что-то будет полезно.

Что внутри?
✅ авторские экспертные каналы
✅ личный опыт, инсайты и кейсы
✅ свежие идеи и лайфхаки
✅ море пользы и вдохновения

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

И еще один анонс!

Уже завтра, 26 апреля, в 20.00 мск проведу открытый урок курса Delivery Manager в OTUS "Слон на нитке – реально ли управлять тимлидами и как это делать?".

Поговорим об инструментах управления тимлидами и роли DM во всем этом.

Присоединяйтесь

КАК ПОДРУЖИТЬ DISCOVERY И DELIVERY

Конфликт интересов Discovery и Delivery – тема классическая и распространенная. Круче и чаще только конфликт “Продажи vs Производство”. Почему так?

Оба эти этапа, и Discovery, и Delivery, находятся последовательно в одной цепочке производства ценности. И, стало быть, очень сильно зависят друг от друга.

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

Есть еще распространенная фишка, поставить каждому из них свой KPI на Lead Time. И тогда Discovery, лишь бы сделать что-нибудь, отдает побыстрее сырой материал в разработку, а Delivery, понимая все риски для своего Lead Time, долго и нудно не принимает требования и постоянно возвращает обратно в Discovery. Вот так и живем.

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

Как быть? Как по мне, нужно сделать 2 вещи:

1. Формализовать процесс передачи продукта из Discovery в Delivery. Какие-то чеклисты, четкие Definition of Done и т д. Чтобы однозначно было понятно, как должна выглядеть документация и проработка требований, чтобы разработка могла начать ими заниматься

2. Добавить командам какой-то общей мотивации. Внедрить общий KPI. Например, пусть вместе гонятся за единым T2M (Time To Market). Тогда не до ругачек на стыке, иначе премия у всех погорит. При этом, их собственные KPI на Lead Time тоже можно оставить, но мотивацию на них сделать ниже, чем на общий результат. Например, делить премию 30/70 за свои/общие KPI

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

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

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

Что скажете? Согласны с такой идеей? Какие еще есть варианты?

JOB SECURITY

На одном интервью меня спросили: “какой ваш главный факап, как руководителя?” Задумался. Если не отделять себя от компании в моменте, то есть что вспомнить. Не успели разогнать продажи к дедлайну. Не получилось продать правильную стратегию CEO. Не удержал важнейшего сотрудника. И т д и т п. У каждого менеджера есть толстый блокнот с факапами, такое “кладбище решений”. И чем толще блокнот, тем лучше будет менеджер, как по мне.

Но это все, что называется, “вжившись в роль”. А есть ли что-то, если отделить себя от конкретной компании? Как наемный менеджер, сам по себе. И тут я понял, что такое есть, и ответ для меня однозначный: не следил за Job Security.

Что такое этот ваш Job Security? Если упростить, то ваша уверенность, что лишившись конкретной текущей работы, вы все еще окажетесь нужны рынку. И у этого понятия есть несколько составляющих:

1. Количество похожих вакансий – для программистов это десятки тысяч, для тимлидов тысячи, для EM и DM это уже сотни, для СТО десятки

2. Среднерыночный уровень ЗП – вы классный на своем месте и вам часто готовы платить много, просто потому что вы классный на своем месте, а если место поменяется, то вы уже не так уж и нужны, поэтому начинают предлагать что-то средненькое на рынке

3. Соответствие вас, как профессионала, среднему портрету кандидата в вакансиях – и тут рынок все выравнивает, хоть и есть много уникальных позиций

Так вот, оглядываясь назад, понимаешь, что полезная штука этот Job Security. И надо за ним следить. Я вот не следил, последние лет 5 до прошлого года. Не смотрел вакансии, не ходил по собеседованиям, мало общался с ЛПРами. Сам много нанимал, уровень ЗП знал, потому что мы регулярно такую аналитику заказывали. Но на этом и все.

Собрал тут несколько полезных советов, по мотивам своей рефлексии. Забирайте, кому пригодится, и добавляйте свои идеи в комментарии:

1. Регулярно следить за вакансиями на вашу позицию. Чтобы понимать требования к кандидатам, уровень ЗП, тренды в найме и т п

2. Ходить на собеседования. Даже если не собираетесь увольняться. Даже если вы менеджер. Вот тут много холиваров на этот счет, но моя простреленная нога говорит мне, что ходить надо

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

4. Развивать свой бренд. Не надо здесь упарываться, но 1-2 раза в год можно что-нибудь интересное рассказать. Отлично работает и для понимания, что нужно рынку, и для развития нетворкинга. Да и могут на собес куда-то пригласить

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

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

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

Это мой список. Субъективный, не всем подходящий. Но реально прожитый.

А вы пишите, что еще сюда можно добавить!

P.S. А еще мы тут со Стратопланом запилили целую конфу про фейлы и факапы. 11 мая, в субботу. Я в этот раз не уместился, поэтому излил душу сюда вам 🙂 Но рекомендую!

“МОЛОТОК” В КОМАНДООБРАЗОВАНИИ

Часто провожу обучения и пишу посты по темам командообразования и аудита команд. Очень уж они мне нравятся. Потому что здесь, как нигде лучше, раскрывается многообразие всяких разных менеджерских инструментов. И можно действовать не по наитию или своему креативу, а, практически, “по методичке”. Да, инструменты в менеджменте вещь условная и абстрактная, нужно все это “приземлять”. Это бесспорно. Но в теме командообразования этих инструментов так много, что точно что-нибудь свое, да подберешь.

Буквально недавно мне попался инструмент, который по праву можно считать эдаким “молотком” в теме командообразования. Потому что он столь же прост, и столь же эффективен. И имя его – пирамида GRPI (картинку закину следом за постом).

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

1. Цели – какие цели у команды, насколько они хорошо сформулированы, насколько откликаются у всех участников

2. Роли – здесь и компетенции команды, и командные роли, чего где не хватает и каков баланс

3. Процессы – основные процессы и правила, необходимые для нормальной работы команды, все ли на месте и все ли оптимальны

4. Межличностные отношения – насколько команда “сыграна”, какие есть малые группы внутри, кто с кем конфликтует

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

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

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

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

И это классный фреймворк, который можно расширять другими инструментами:

1. Цели – от Мамонта до OKR-ов
2. Роли – от матрицы и карты компетенций до ролей Белбина или Бенна/Шитса
3. Процессы – от базовых 1/1 до сложных процессов Delivery с Аджайлами и Скрамами
4. Межличностные отношения – от теории малых групп до границ Берна

Расширяй - не хочу! Приземляй – не хочу! Ну просто сказка, а не инструмент!

Пользуйтесь!

А картинка следом, как и обещал.

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

На прошлой неделе заходил на Неформальный Стратоплан, пообсуждали проблемы руководителей отделов и СТО. Поотвечали на вопросы вместе с Сашей Орловым и Андреем Крыловым.

О чем успели поговорить:
- Как себя вести, если хочется карьерного роста, но никак не повышают
- Что делать, если у компании нет ресурсов, т е количество проектов увеличивается, а людей - нет
- Как получить от руководства реальные ожидания от своей позиции, если они их никак не сформируют
- Как решить проблему коммуникации со стейкхолдерами, когда излишне закрываешься на внутренних задача отдела
- Куда вкладывать ресурсы, чтобы расти, как СТО
- Как поступить, если на работе все хорошо, но категорически скучно
- Где брать базу/систему по менеджменту, когда учишься через свой опыт и шишки
- Что делать тимлиду, который раньше был инженером в команде, а теперь должен ей управлять и постоянно натыкается на дерзкого и токсичного сотрудника, не принимающего его начало

https://youtu.be/Jq_-HL0fFKc

А на этой неделе в предверии очередного запуска курса COO в OTUS провел открытый урок, где пообсуждали операционные стратегии и рассмотрели основные.

Были стратегии:
1. Снижение себестоимости
2. Повышение гибкости
3. Повышение качества
4. Сокращение времени

По каждой разобрали возможные варианты реализации, плюсы/минусы, применимость. Обзорно, но с понятными примерами.

https://youtu.be/8z1ChLwXuBA