Зачем мы здесь

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

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

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

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

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

Инжир-душитель

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

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

Каждый раз это был одинаковый подход — сделать снаружи слой API в виде отдельного сервиса / сервисов, который правдами и неправдами умеет делать нужные штуки в интегрируемой системе. В идеале, конечно, этот слой является стандартизированным API-фасадом для собственного API этой системы + добавляет полезных вещей типа обогащения запросов разными данными вроде авторизации. Но по факту как получится — здесь скорее простор для анти-паттернов, влючая походы напрямую в БД. Система же все равно под снос, можно и похулиганить напоследок.

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

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

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

Put the fish on the table

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

Одно из них — дача обратной связи.

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

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

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

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

От одного испанца, кто собаку съел на работе с людьми, я как-то услышал выражение put the fish on the table — означает оно выкладывание самого-самого неприятного на стол, чтобы оба это видели и могли обсудить. То есть сразу, никуда не откладывая, взять и выложить. И не забыть обозначить, что то что ты сейчас делаешь это put the fish on the table и вам необходимо это обсудить.

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

Делегирование vs переназначение

Иногда я прошу начинающих менеджеров объяснить на пальцах что такое делегирование.

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

Исполнение это когда и работа, и ответственность на одном и том же человеке — все просто.

Если менеджер передает работу сотруднику, сотрудник её факапит, а менеджер потом объясняет своему боссу что это сотрудник виноват — менеджер переназначил работу, а не делегировал её.

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

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

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

Система управления с обратной связью

По специальности я инженер АСУ-шник и как-то объяснял другому инженеру АСУ-шнику в чем принципиальное отличие подхода при переходе от руководстве командой к руководству руководителями. И вот именно в тот момент и придумал доклад "Система управления с обратной связью".

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

Это был осознанный эксперимент на прошлогоднем Saint TeamLead, который я признал неуспешным по трем причинам:
• была гипотеза сделать доклад на аудиторию team lead+ — те, кто руководит командой или только начинает путь тим-лида, с проблемами этого доклада еще не стокнулись и им он был неинтересен. Разброс в распределении оценок был значимо больше моих остальных докладов
• я капитально промахнулся с названием — даже из аннотации не до конца было понятно о чем пойдет речь. Это я осознал только тогда, когда в кулуарах конференции меня снабдили обратной связью на эту тему. Это было фиаско
• по сути я почти весь доклад переделал в предпоследнюю ночь — два месяца до этого пытался порассуждать про отличия с разных сторон и точки контроля, получалось академично, но без прикладного смысла. И когда уже приехал в Питер понял, что надо переделать всё. В итоге получилось сыровато, потому что обычно доклад у меня это куда более серьезная подготовка и шлифовка.

Чего вдруг я про все это вспомнил.

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

Во-вторых, мне пару дней назад приехал апрув моей заявки на доклад на Saint Team Lead 2025 — что ж, традиция и show must go on.

А, и ссылку на запись чуть не забыл.

Звездочки светят ярче

Я несколько раз начинал этот пост и каждый раз получалось совсем не то, что действительно хотел сказать.

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

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

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

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

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

Тед Лассо — сериал про пипл-менеджмент

По совету сразу нескольких друзей начал смотреть эппловский сериал "Тед Лассо". Одна из рекомендаций звучала примерно так: "там есть чему поучиться".

Пока взахлеб посмотрел первый сезон и это действительно сериал про пипл-менеджмент.

Коротко сеттинг: Теда Лассо, тренера университетской команды по американскому футболу из Штатов, приглашают тренировать футбольный клуб Английской премьер лиги. Тренер даже не знает правил этого вот английского футбола (он в Штатах же даже и называется soccer, чтобы не путать с football — американским футболом), но знает, как работать с людьми и с командой. Короче, выезжает только на софтах.

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

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

И да, если что, продюсер там Билл Лоуренс ("Клиника", "Терапия"), так что вайб вы поняли.

Подкаст про Цифровой этикет, который получился про голосовухи

Сегодня вышел выпуск "Вдруг тут что-то важное" по теме "Цифровой этикет", куда меня позвали Андрей Смирнов и Ульяна Батуева.

Классный монтаж от команды Ульяны конечно компенсировал многие ошибки, но небольшая ретроспектива:
• я уже понял, что к подкастам, особенно тематическим, надо готовиться и в этот раз я заранее накидал себе список тезисов, про что было бы интересно поговорить
• инсайт для меня в этот раз: надо не просто выписать список тезисов, но и выбрать основную мысль, вокруг которой эти тезисы собирать. После записи мне казалось круто, что я вспомнил про нейрохимию и six-pager-ы, но по факту много говорили про голосовухи и при подготовке анонсов показалось, что основная мысль в них :)
• и да, основная мысль должна была быть акцентирована, все остальное раскрывает, подкрепляет, дополняет — все как в докладе
• количество "ээээ" снизилось и это радует, но "вот" и "короче" прорвались даже сквозь монтаж :) Короче, до голосов Андрея Смирнова и Саши Афенова еще ой как далеко, вот
• раз уж разговор с "короче" и "вот", то надо больше кулстори — они вроде и есть, но я всегда под запись не берусь рассказывать, чтобы не наболтать лишнего. Надо вспоминать заранее, цензурировать и добавлять в список тезисов

А в остальном получилось неплохо и местами возможно полезно, послушать можно вот тут: https://kode.mave.digital/ep-22

«Лидер и племя» и подзатыльник

Когда рефлексировал про итоги 2024, книгой года однозначно определил «Лидер и племя». Мне казалось, что про теорию лидерства я знаю довольно много, но книга выписала мне знатный подзатыльник.

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

В переводе, в котором я читал, уровни называются так:
1) «Жизнь дерьмо» – тотальная враждебность людей в соотношении всех ко всем
2) «Моя жизнь дерьмо» – тут люди ощущают враждебность окружения по отношению к себе, но считают, что у остальных дела получше
3) «Я крутой (а вы нет)» – достигаторство и внутренняя конкуренция за то, чтобы быть самой красивой звездочкой
4) «Мы крутые (а они нет)» – кооперативное общее благо, мои достижения = достижения племени
5) «Жизнь прекрасна» – полный дзен и вдохновление других (я сам такого или не видел, или не понял)

Так вот, про подзатыльник. Мои любимые Апелло, Ленсиони и Де Марко рассказывают рецепты чего бы такого поделать, а «Лидер и племя» формулирует definition of done – целевое состояние, к которому нужно стремиться, ступеньку за ступенькой. А я, получается, фокусировался на процессе, а не на результате – это менеджмент, в лучшем случае, на троечку.

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

Flight Levels

За сегодня в двух разговорах вспоминал концепт Flight Levels, за последний год делал это наверное уже десятки раз и один раз даже чуть не включил в доклад. Поэтому надо сделать пост.

Сразу скажу, оригинальную книжку Клауса Леопольда не читал, а впервые услышал про концепцию в докладе Анатолия Панова на South Hub. Основная мысль Анатолия заключалась в том, что flight levels хорошо маппятся на нашу организацию и это действительно так.

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

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

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

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

Вообще, концепция простая и хорошо структурированная, как и многое у Клауса Леопольда. И самое главное, помогает правильно структурировать свою работу, если вовремя про уровни вспоминать.

ps если интересно больше идей из книжки, вот тут хороший обзор на русском.

Цели ради цели

Личные итоги года подводят в декабре в инстаграме на фоне елки, а корпоративные – в январе, когда все годовые показатели посчитаны, а елка уже убрана.

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

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

Да, бывают цели, где эффект неочевиден, а бывают, где в процессе достижения может перестать быть актуален. Выявить отличие можно через последовательные «зачем?» (строго говоря, «5 why» вполне можно перевести как «5 зачем»). Если в какой-то момент ответы на эти «зачем» приводят к целям или стратегии компании, значит, все в порядке. Если нет и ответ рекурсивно крутится вокруг самой цели, поздравляю, перед нами – цель ради цели.

Как же быть, если такую обнаружили?

В идеальном случае – выявить на старте и не ставить. Но чаще такие цели обнаруживаются уже в процессе.

Если есть возможность и предполагает система – убрать. Но здесь тонкая грань: если цели можно легко добавлять и удалять, то они превращаются в обычный бэклог, а не цели. Я лично противник изменения целей без очень серьезного обоснования. В конце концов, всегда есть соблазн выкинуть самый последний приоритет, который перестал помещаться в капасити. Чтобы ясно показать, что цель хотим убрать по причине утраты актуальности / необходимости, а не манипулируем этим самым капасити, идеальный план – заменить цель на эквивалентную по усилиям. Мы не будем делать А, но взамен сделаем Б, потому что поняли, что Б нужно, а А – нет.

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

Январь еще время постановки целей на наступивший год. И там где есть сомнения, самое время позадавать себе последовательно вопрос «зачем», чтобы мучительные выборы не пришлось совершать в течение года.