Про продажу задач

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

Твоя задача может быть очень важная и нужная, но если ты не "продал" её в условиях конкуренции за ресурсы - она не будет сделана.

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

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

Базовая проверка аналитика

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

Суть: человек принимающий решения (например, менеджер проекта) просит подопытного срочно специфицировать новую фичу, которая "прям точно нужна, делаем ASAP".

Провалом проверки будет ситуация, когда подопытный без лишних вопросов подрывается и пишет ТЗ со слов ЛПР и в меру своей фантазии.
Успехом будет ситуация, когда вы услышите от подопытного подобные вопросы:
- а зачем нам это делать?
- почему это нужно сделать срочно? Что случится, если мы сделаем позже?
- у меня в работе фичи А и Б, мне их приостановить из-за этой срочной фичи?

По этим вопросам станет понятно:
1. Человек не смущается, когда кто-то уверенно говорит ему "дичь". Прежде всего он думает своей головой.
2. Человек думает о качестве конечного результата, а не просто тупо исполняет то, что ему сказали.

Когда не надо здороваться в чате

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

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

Вместо этого лучше писать свой вопрос сразу вместе с приветствием в одном сообщении. Тогда собеседник с первых секунд после прочтения начнёт думать над вашим вопросом (но это не точно) и вы повысите вероятность получения быстрого ответа.

Мне очень понравилось как эту идею доходчиво изложили на сайте https://nohello.net/ru/ (время чтения макс. 2 минуты).

P.S. Про второй вид поведения напишу в следующем посте.

Про мета-вопросы

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

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

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

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

Эту проблему коротко и наглядно расписали на сайте - https://nometa.xyz/ru.html (время чтения макс. 2 минуты).

Сегодня вечером выступаю на конференции DevOops на площадке в Москве с темой "Mobile SRE — когда надежность нужна не только на бэкендах"🤘
В своём докладе я проведу рефлексию одного крупного сбоя в мобильном банке, расскажу про полезные изменения, которые стриггерил этот сбой и предложу советики, которые можно применить прямо сразу после доклада на благо мобильного приложения вашей компании🙂

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

Представьте, что у вас 10+ млн. пользователей в сутки. И примерно 0.001% из них может обратиться в поддержку каждый день. Чтобы им помочь, вам нужны подробные логи вашей системы. Писать такие подробные логи всегда и по всем пользователям - слишком дорого. Но без подробных логов им не помочь. Как бы вы решили эту проблему?

Пока я готовлю очередной содержательный и полезный пост (а других постов у меня и нет😜), предлагаю вам почитать мою первую статью на Хабре, где я затрагиваю и эту тему🔥

Статья представляет из себя расшифровку моего мартовского доклада с конференции DevOpsConf, где я рассказывал про особенности SRE и observability в мобильных приложениях. В самом докладе я делюсь как общими соображениями на тему мониторинга со стороны фронта, так и конкретными метриками и наработками/опытом на эту тему. В общем, должно быть не скучно. К слову, хоть я и рассказываю про мобильное приложение, на деле часть идей вполне применима и для других фронтов типа веба.

Чуть не забыл саму статью - https://habr.com/ru/companies/tinkoff/articles/762058

Почему технари ничего не могут без менеджера

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

Одна из ключевых "фич" менеджера - наводить и поддерживать порядок. Порядок в процессах, порядок в целях работы. И это как раз то, чего часто не хватает инженерам, которые сильно вовлечены в работу ИТ-системы. Из-за того, что они глубоко знают и увлечены внутренностями системы, они могут забывать про то, для чего вообще она существует, какова ее ценность для бизнеса и клиентов. А если забыть про эти вещи, то легко начать делать то, что ценности не добавляет. Такая работа запускает цикл разрушения: делаем то, что не даёт ценности > бизнес тратит ресурсы впустую или делаем то, что нафиг не нужно клиентам > они не пользуются нашим добром > инженеры грустят, мораль падает. Как грится, сначала они говорят зачем нам вся эта менеджерская шелуха, а потом они жалуются на выгорание.

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

Сегодня выступаю на митапе Big Monitoring Meetup X - https://monhouse.tech/big-monitoring-meetup-x/.
Буду рассказывать свой доклад с DevOops с минимальными доработками, тема "Mobile SRE - когда надёжность нужна не только на бекэндах". В докладе будет рефлексия одного крупного сбоя в мобильном банке, про то как мы системно закрывали причины его возникновения и про выводы, которые могут быть полезны инженерам, которые даже не занимаются фронтами.

Чуть позже сделаю здесь несколько постов с выжимкой самой сути из этого доклада.

Про неприятную обязанность менеджера

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

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

И тут есть определенная развилка:

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

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

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

Сегодня в обед буду выступать на конференции Mobius 2023 Autumn в Санкт-Петербурге. Тема моего доклада «А у нас сейчас всё норм работает?» или Что такое observability мобильного приложения.

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

Фух, надеюсь, все получится🤘

Менеджерское одиночество

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

А почему? Я вижу, по крайней мере, 2 причины:
1. Конфиденциальность. Ты раньше всех узнаешь, кто планирует увольняться или переходить в другую команду. У кого с кем конфликты. Какое направление руководство думает свернуть. И всё такое. И всё это секретики, которые надо хранить, но которые, однако, могут сильно влиять на настрой менеджера и на принимаемые им решения. А к кому идти за поддержкой, когда ты переживаешь из-за чего-то такого секретного?
2. Ожидания лидерства. Мы все знаем, что хороший менеджер это лидер, который вдохновляет других. Но что, если он сам потерял вдохновение и позитивный настрой? К людям из команды с таким не пойдешь, ведь, если попадется недостаточно зрелый человек, то вид подавленного лидера может демотивировать его самого. Да и как поддержать приунывшего лидера? Это тоже вопрос.

Но не все так грустно. Я думаю, что подавленный лидер может обратиться к таким источникам "исцеления":
1. Друзья и семья. Иногда просто выговориться и услышать взгляд со стороны - сильно продвигает в решении проблемы.
2. Коучинг. Специально обученный человек может сильно ускорить собственную рефлексию и помочь удержаться в конструктивном русле.
3. Коллеги менеджеры. Наверняка они тоже сталкивались с чем-то подобным, и если у вас достаточно доверительный контакт, то они могут поделиться своим опытом.
4. Руководитель. Если с ним сложился хороший контакт, он открыт и опытен - его взгляд на ситуацию может быть очень полезен и открыть новые грани.

Появилась публичная запись с моего последнего доклада c конференции мобильных разработчиков Mobius «А у нас сейчас всё норм работает?» или Что такое observability мобильного приложения.

Поделюсь анонсом с сайта конференции (не зря же его писал!):

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

Даниэль расскажет, чем плох подход «запустить и потыкать руками» и поделится тем, как в Тинькофф подходят к observability (наблюдаемости) мобильного банка – основного приложения компании с ежедневной аудиторией свыше 10 млн. клиентов. Спикер также расскажет о том, как и за какими метриками следят и какие практики показали свою эффективность в этой теме.

Если эта тема вам интересна - welcome на ютуб😊
https://youtu.be/EkT-EvUYww8

Твой код никому не нужен

Равно как и тест-кейсы. Или эти дейли-митинги, планирования и ретро. Они тоже не нужны вместе с грамотно описанным ТЗ. Оптимизации производительности, метрики и мониторинг туда же. А тем более все эти задачи в Jira и прочих трекерах. Все это никому не нужно...
...если не несёт пользы для бизнеса, если не помогает зарабатывать больше или тратить меньше.

Техническим менеджерам в этой теме выпала нелёгкая доля. Если в "бизнесовых" задачах типа "нарасти конверсию в действие Х" понятна денежная ценность (выше конверсия -> больше целевых действий -> больше выручка), то в технических задачах она далеко не так очевидна. Как, например, посчитать денежный профит от ускорения ответа от веб-сервиса? Как оценить влияние на метрики бизнеса от миграции с одной СУБД на другую? И это далеко не самые сложные примеры.

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

А как
А как именно строить такую связь от техники к бизнесу? Об этом напишу в одном из следующих постов.

Про связь технических задач и бизнеса

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

Условно "идеальным" мерилом важности задачи являются деньги. Чем больше задача позволяет зарабатывать или экономить в конечном итоге, тем она важнее и срочнее. Однако в большинстве технических задач влияние на деньги неочевидно, мягко говоря. Нельзя просто взять и оценить сколько рублей нам принесёт, например, переделка фреймворка для автотестов или ускорение ответа от веб-сервиса на 300 мс. Да и оценивать все задачи в деньгах довольно утомительно, если это делать хотя бы с какой-то точностью.

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

Для примера давайте возьмём пример с переделкой фреймворка автотестов для какой-то системы.
Какая польза от этой задачи? На кой её вообще делать? Если сказать по-простому, то, например:
1. Чтоб тесты быстрее проходили
2. Чтобы код был более понятным
3. Чтобы проще был расширять функционал.

Неплохо, цели благие. Но какие метрики могут быть у этих целей? Другими словами, на какие метрики непосредственно влияет выполнение этих целей?
1. Чтоб тесты быстрее проходили -> Сокращается время прогона тестов
2. Чтобы код был более понятным -> Сокращается время онбординга новых QA в проект + сокращается кол-во багов в тестах
3. Чтобы проще был расширять функционал -> Сокращается время время написания новых автотестов.

Так. Становится понятнее? Теперь мы знаем, какие метрики объективно покажут пользу от этой задачи (или бесполезность). Но где тут бизнес-метрики? Где тут денежки?

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

Так вот, возвращаясь к нашему примеру с фреймворком автотестов. Как видно, все они влияют на время, которое входит в общее время цикла разработки. Т.е. с этими автотестами разработка должна ускориться. И в этом главная ценность этой задачи!
Для измерения времени разработки давно существует метрика Lead Time и её старшая сестра TTM (Time to Market, но она больше про общее время выпуска фичи, не только про разработку).

Таким образом, переделка фреймворка тестирования сделает разработку быстрее, и это будет видно на метриках Lead Time и TTM. С этими метриками бизнесу работать уже намного проще т.к. стоимость времени разработки, как правило, понятна и её сокращение можно посчитать. Через эти метрики можно обсуждать приоритет с "бизнесменами".

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

Когда подчинение менеджеру это зло

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

А портит всё оно тогда, когда от команды ожидается креативность и даётся большая степень свободы в принятии решений. Мол, вот вы команда, у вас есть всё, что нужно, мы не будем говорить вам ЧТО ИМЕННО делать, скажем только ЦЕЛИ, а дальше решайте сами. Пока-пока, ждём результатов! Такая модель хорошо зарекомендовала себя в т.н. "продуктовых" командах, которые имеют сами в себе всех нужных людей, чтобы добавить какую-то ценность в продукт. Например, новую фичу. Такой подход показал свою эффективность во многих компаниях в мире.

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

Так, а что делать то?
Если команда подходит под критерии о необходимости "креативности" и "свободы принятия решений", то у менеджера продукта не должно быть прямых подчиненных в команде. Разработчики должны быть подчинены руководителю разработчиков и так далее с каждой ролью. Менеджер должен управлять ими только в рамках функции команды и не принимать решений, влияющих на зарплаты и премии. В такой конфигурации в команде допускается продуктивный конфликт, когда никто не боится высказать своё мнение, даже если оно противоречит мнению менеджера. Менеджер не может просто "задавить" сотрудника своим словом, придётся более конструктивно и продуманно доказывать что делать и почему именно так. Зачастую, именно в таких конфликтах и рождается наиболее элегантное решение вопроса.
Конечно, это требует больше энергии со стороны менеджера, но что поделать - таков путь.

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

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

Оглавление

Как я первый раз уволил человека
Когда продолбать задачи не так уж плохо
Про продажу задач
Базовая проверка аналитика
Когда не надо здороваться в чате
Про мета-вопросы
Про первую статью на Хабр
Почему технари ничего не могут без менеджера
Про неприятную обязанность менеджера
Менеджерское одиночество
Твой код никому не нужен
Про связь технических задач и бизнеса
Когда подчинение менеджеру это зло
Про то, как уходить из команды
Про медовый месяц менеджера
Про догфудинг
Про аэропорты
Про важность сегментации
Про переработки у инженеров
Про AI тулы в работе
Про мотивацию выступить
Про выбор темы для выступления
Часть 1. Что делать, если я не знаю о чем рассказать
Часть 2. Что делать, если я не знаю о чем рассказать
Про книгу Хорошая стратегия плохая стратегия
Про сбой CrowdStrike и Windows
Про MongoDB и удержание пользователей
Technical Product Manager'ы не нужны
Про Meeting notes
Про признание среди инженеров
Про эмоциональный аттач к продукту
Про темную сторону data-driven подхода
Про важные мелочи при запуске продукта в соло
Про ограниченную ответственность продакта
Про конфликт команд продаж и продукта
Про книгу OpenTelemetry
Зачем большие вендоры систем мониторинга поддерживают OpenTelemetry?
Зачем большие вендоры систем мониторинга поддерживают OpenTelemetry? часть 2
Про то, когда менеджеру НУЖНО обсуждать людей у них за спиной (1/2)
Про то, когда менеджеру НУЖНО обсуждать людей у них за спиной (2/2)
Про мои собесы в Яндекс 1
Про мои собесы в Яндекс 2
Когда TPM все таки нужен (а когда нет)
Про книгу "Искусство войны"
Про фокус на результатах

Про то, как уходить из команды

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

Думая об этом, я выделил 4 признака менеджера-чудака:

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

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

3. Ломает рабочие процессы. Горе-менеджер не заботится о том, чтобы в его отсутствии процессы продолжали работать слаженно - он не ищет себе замену в этих процессах, не поддерживает их до последнего рабочего дня. Процесс нарушился, а это теперь не его дело!

4. Оставляет много неопределенности. Кто будет вместо тебя? Что нам делать, пока нет замены? Когда именно ты уходишь? И ещё куча подобных вопросов ожидаемы и легко прогнозируемы, но наш воображаемый менеджер не хочет потрудиться, чтобы ответить на них ради своей команды.

А, ну и не забудьте сделать всё наоборот, конечно, если вдруг.

Про медовый месяц менеджера

Когда менеджер приходит в новую компанию или в новую команду, у него возникает совершенно замечательный период - так называемый, медовый месяц менеджера. Почему медовый? Потому что это время имеет два особенных свойства:
1. Минимальные ожидания (если он не кризис-менеджер, конечно).
Обычно в компаниях дают неделю-две-месяц на то, чтобы заонбордиться, прочитать важные документы, познакомиться с командой и всё такое. В этот период от нового человека не ждут свершений или прорыва в проектах - достаточно будет, если он вникнет в базовые дела и начнёт выполнять начальные задачи для этой роли. С ходом времени эти ожидания будут расти и через месяц они будут существенно отличаться от начального состояния.
2. Высокая толерантность к неосведомленности.
Другими словами можно задавать любые тупые вопросы без риска показаться глуповатым. "Почему решили перейти на Postgres вместо MySQL? Почему на ретро вы не делаете icebreaker? Почему поставлены именно такие цели на этот квартал?" - новичку прощаются любые вопросы. И этим надо пользоваться, чтобы глубже понять контекст работы. Конечно, в будущем лучше тоже задавать вопросы, даже если они кажутся глупыми, ведь легче задавать глупые вопросы, чем исправлять глупые ошибки. Но, согласитесь, некоторые вопросы выглядят менее уместными через месяц-другой работы в команде.

Кроме учёта этих свойств, есть ещё пару особенных действий, которые важно сделать в этот период:
1. Познакомиться с ключевыми людьми. Руководителем, лидами команд, клиентами и другими стейкхолдерами. Важно понять их ожидания (if any), разобраться с зонами ответственности (с какими вопросами к ним приходить), да и просто по-человечески познакомиться (вживую, если есть возможность). На своём опыте ни раз замечал, что после личного знакомства совместная работа идёт более гладко.
2. Договориться о целях в своей роли. Нужно в явном виде и как можно более однозначно определить, что ожидает руководитель (в идеале, ещё и его руководитель, но эту мысль пока придержим🤐) и как он будет оценивать выполненную работу. В противном случае можно начать делать не то, что нужно и, в лучшем случае, узнать об этом по ходу выполнения, а в худшем - в конце испытательного срока. Поэтому правила игры лучше зафиксировать на старте.

Как считаете, что ещё важно сделать во время медового месяца менеджера?

Про догфудинг
Да, если вы не слышали этот термин раньше, то выглядит он дико. Интернеты говорят, что в ИТ это определение впервые в 1988 году использовал менеджер компании Microsoft Пол Мариц, когда отправил коллеге, менеджеру по тестированию Microsoft LAN Manager (который уже канул в Лету - я не про коллегу, а про продукт), письмо с заголовком «Eating our own dog food», призывая увеличить использование собственного продукта внутри компании. Как бы там ни было на самом деле, сейчас этот термин используется в том смысле, что сотрудникам компании предлагается использовать собственный продукт как и их клиентам, в тех же условиях и в том же виде. Мол, "попользуйтесь тем, что сами создали. Ну как, нравится?".

А причём тут технический менеджмент, спросите вы?

А вот причём. Я искренне убежден, что если технический менеджер не использует свой продукт регулярно как обычный пользователь, то он теряет 80% возможностей для его улучшения. Цифру я, конечно, придумал, но сути это не меняет.
Не используешь свой продукт:
- не видишь очевидных провалов в сценарии использования (кто-то же другой их должен заметить, да?)
- не замечаешь раздражающих багов (которые уже давно есть в беклоге, просто "не горят")
- не примечаешь напрашивающихся улучшений.

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

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

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