Мнимая управляемость

Конференции как навигатор 

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

На свою первую конференцию я пошел почти сразу после того, как сам стал тимлидом. Потому что довольно быстро обнаружил проблему: технические задачи я решать умел, а что есть работа с людьми - не знал. Руководителя, у которого можно было бы подсмотреть, у меня до этого толком не было. Со мной никто не проводил 1-0-1 (я о них даже не знал), не давал системной обратной связи, никаких ИПР и прочих менеджерских радостей я в глаза не видел. Документацию к людям почему-то не приложили, на stackoverflow не пишут, как повышать или увольнять - поэтому я пошел смотреть, как вообще эту работу делают люди, которые, кажется, знают, что делают. Тогда каждый доклад для меня был золотом. 

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

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

Например, именно конференции когда-то помогли мне понять, что мне особенно интересен people management и какой (какие) у меня тип руководителя. Никакого великого озарения не было - я просто в какой-то момент заметил, на какие доклады постоянно хожу, с кем остаюсь разговаривать после и какие мысли потом продолжаю крутить в голове. Это осознание позволило мне направить свои силы в выбранную сферу и получать удовольствие от работы. 

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

Поэтому конференции для меня теперь - возможность триангулировать собственное положение и понять, куда меня действительно тянет, а куда, кажется, просто положено ИИдти

Тимлиды, вы ещё думаете идти ли на наш митап? 👀

В карточках собрали программу, чтобы у вас не осталось никаких сомнений.

➡️Регистрируйтесь ⬅️

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

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

Пошел сезон конференций, на некоторых я буду в роли спикера/эксперта. Вот одна из таких. Регистрируйтесь, приходите

Готовим сегодня ИИшницу

2/2

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

Потому что у него есть железное алиби: “Я правда сделаю быстрее”.

Да, сделаешь.

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

Но после каждого такого случая полезно честно ответить себе на три вопроса:
1. Почему я не смог отдать это в команду?
2. Что надо изменить, чтобы в следующий раз это можно было отдать?
3. Какую работу я сейчас вытеснил своим “быстро сделаю”?Если ответов нет, скорее всего, я не ускоряю систему.
Я просто беру ее неуправляемость на себя.

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

Я говорю о ситуации, когда в уже запланированную работу прилетает ad-hoc. Мелкий баг, срочная просьба, быстрый PoC, небольшая доработка - буквально на один вечер.

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

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

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

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

Во-первых, команда перестает видеть реальную нагрузку.
На планировании у нас есть capacity команды. Есть задачи. Есть сроки. Все вроде бы сходится. Но потом часть незапланированной работы внезапно растворяется в руководителе.
Снаружи система выглядит лучше, чем она есть. Команда как будто справляется. План как будто не пострадал. Ad-hoc как будто ничего не стоил. Но он стоил, это не бесплатная работа - просто ее стоимость никто не увидел.

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

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

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

1/2

Это вторая часть про инструменты адаптации. Первая тут.

III. Контекстные инструменты создают рамки прозрачности (и, как следствие, предсказуемости - причем двусторонней). Эти инструменты должны помочь новому сотруднику понять, как устроены продукты, их архитектура и главное - почему именно так.

Здесь к нам снова придет на помощь документация, но теперь по продуктам команды и с актуальной картой сервисов. Тут уже может не обойтись без консультаций со стороны ответственных за сервис коллег и лучше это организовать в виде QA-встречи. Полезно практиковать и гембу - дать в руки сервис или, если продукт направлен на определенный тип пользователей, примерить на себя их роль и “прочувствовать”, каково это пользоваться конкретным сервисом.
В идеале новичок (как и каждый член команды) должен понимать не только ЧТО происходит в системе, но и ПОЧЕМУ ТАК, а не иначе

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

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

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

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

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

Мы с сообщниками из Management Hub постарались раскрыть тему адаптации максимально полно, почитать общий текст можно тут - часть 1 и часть 2. Читайте, подписывайтесь на авторов

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

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

Культурные договоренности. После формального знакомства с командой стоит посвятить новичка в свод неписаных правил, чтобы убрать социальное трение. Сюда входят правила коммуникации: принято ли включать камеры на встречах, пишем ли мы в чаты после 19:00 (или используем беззвучный режим), и с кем в команде можно сразу переходить на «ты». Четкое понимание этих границ в первый же день избавляет новичка от необходимости угадывать контекст и бояться совершить социальную ошибку - то есть меньше стресса, а это уже хорошо.

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

Чаты (в том числе неформальные) - чат с мемами, random и даже чат “без начальника” - клей для команды, рекомендую.

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

II. С социальной частью разобрались, но нам еще и работу делать, поэтому включаются Функциональные инструменты. Они нацелены на обеспечение возможности разработчику в принципе делать свои задачи, то есть на его исполнимость (если угодно, execution capability).
Очевидно, тут первым делом идет выдача доступов. Новичку с этим нужно помочь в первую же очередь (после знакомства), иначе все остальное сделать просто не получится, а сам он запутается и вообще обалдеет.
Теперь по самим инструментам. Тут основной упор на обучении с реальной рабочей средой и проектами команды:

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

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

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

Остальные инструменты в продолжении.

Мнимые цели.

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

Спрашивается, вот че ты доебался в чем же проблема? Объяснение не всегда было в моей голове, сначала я просто чувствовал, что без нее дизориентирован. Сейчас я могу ответить, что управление - целенаправленный процесс, предполагающий, очевидно, наличие определенной цели.


I. Цель должна БЫТЬ.

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

• Невозможно оценить результат
Без цели невозможно сказать успех это или нет; мы продвинулись или просто что-то поделали.

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


II. Цель должна быть прозрачна сотрудникам.

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

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


III. Цель должна быть согласована с бизнесом и, в идеале, с прочим внешним контекстом.

Цель конечного подразделения должна быть согласована с целями отдела; цели отдела - с целям департамента; у того - с целями компании, а дальше зависит от того, где и чем компания занимается. в отдельных местах цели компании могут (или должны) быть согласованы с государственными.

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


Воспринимать цель нужно не как просто формулировку. Это ограничение на решения. “Заработать больше денег” не помогает выбрать между сокращением людей и запуском новых фич.

А значит - не помогает управлять.

НАМ ПИШУТ

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

Победил Михаил @Mix_Kup, поздравляем! Его пост открывает серию👇

Почему вы недополучаете ресурсы от руководителя, даже если всё делаете правильно

Есть популярная концепция «языков любви».
Смысл простой: людям важно не то, что вы даёте, а как они это воспринимают. Например, можно заваливать партнёра подарками, деньгами, и он всё равно будет чувствовать себя нелюбимым, если его язык — слова или прикосновения.

С руководителями работает точно так же. У каждого есть свой «язык управления» — способ, через который он замечает людей, принимает решения и распределяет ресурсы. И если вы говорите на другом языке, то вас могут просто не слышать, не видеть, отдавать приоритет не в вашу пользу.

Какие вообще бывают языки руководителя:

1. Язык эффективности
Руководитель ценит результат и цифры, бизнес-эффект.
Самый базовый и понятный язык. Говорить не просто, что делали, а что получили. «Вот что мы сделали, вот результат, вот метрики». Если вы просто старались — это не эффект.

2. Язык видимости
В слабых/токсичных системах это про громкость. В более благоприятной — про прозрачность. Руководитель хочет видеть и знать контекст вашей работы.

Как говорить в слабых системах:
• «поднимать на флаг» даже небольшие победы,
• пинговать и дёргать, если нужно решить проблему.

В сильных: подсвечивать статусы, риски и планы.

Если вы молча делаете свою работу и не даёте контекста, руководитель вас не видит.

3. Язык исполнительности
Руководитель ценит надёжность и способность доводить задачи до конца.

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

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

4. Язык инициативы
Руководитель ценит не исполнителей, а тех, кто сам находит проблему и приносит решения.

Как говорить:
• приходить сразу с вариантами решения, а не просто с вопросами,
• брать ответственность за предложения и результат.

Доверие
Это квинтэссенция всех 4-х языков. Если вы в правильной ситуации используете нужный руководителю язык, возникает доверие. Руководитель знает, что вы даёте результат, держите в курсе, не подводите и думаете наперёд.

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

На самом деле именно этот пост был первым, что я написал 👇

Мнимая прозрачность. Часть I. Продукт.

Самая опасная ситуация в управлении - не когда ничего не видно, а когда кажется, что всё видно.

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

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

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

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

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