Первое увольнение

Сегодня я первый раз в жизни уволил человека. Вернее, не совсем прям я, а лид команды. Но я непосредственно участвовал в принятии этого решения, был на финальном разговоре с этим человеком, высказал свою позицию в пользу его увольнения на финальной встрече.
Он был разработчиком в нашей команде, и его производительность и способность прислушиваться к обратной связи не соответствовала тому, что мы ожидали. Перед принятием решения об увольнении мы давали ему шансы, давали т.н. "негативную обратную связь". Мы договорились с ним о наборе конкретных задач, которые ему нужно сделать за 2 недели. Человеку его грейда выделенного времени на такие задачи должно хватить с запасом. Но, к сожалению, прошло 3 недели, но ни одна задача так и не была сделана на 100%. Се ля ви. Благо, всё это обнаружилось и решилось в течении испытательного срока.
Я знал, что у него семья и временное разрешение на проживание в стране из-за работы. С одной стороны, это не моё дело, а с другой по-человечески я ему сочувствую и хочу помочь чем-нибудь. После увольнения у него было бы всего 15 дней, чтобы найти новую работу или чтобы покинуть страну. Звучит довольно жестко. Поэтому мы постарались максимально смягчить этот удар - предложили до конца испытательного срока (почти 3 недели) пойти в отпуск за свой счёт. Таким образом, он сможет искать работу с меньшим давлением, чем если бы он сразу оказался на улице. We did our best.
История, конечно, не из приятных, но я вижу это довольно полезным опытом. Причём полезным с двух сторон:
1. Эта ситуация показывает оборотную сторону "работы". Пока ты в "матрице" и перформишь на достаточном уровне - всё окей, система поощряет тебя. Но нельзя обольщаться. Как только твоя производительность упадёт ниже какой-то планки (не всегда очевидной) - система избавится от тебя очень быстро. Поэтому не стоит слишком сильно "прикипать" к своей работе. Я должен быть нужен работе больше, чем она мне.

2. Эта ситуация заставляет немного по-другому посмотреть на сотрудников в команде. Если раньше в моей системе координат увольнение было чем-то далёким и недостижимым, то сейчас моё "окно Овертона" расширилось. Теперь я, как менеджер, опробовал новый для себя инструмент в работе. И теперь я знаю, что ещё могу сделать, если сотрудник не прислушивается к ОС и показывает слабые результаты.

Когда продолбать задачи не так уж плохо

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

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

Эта идея звучит для меня как таблетка от FOMO (fear of missing out, боязнь пропустить интересное). Вместо того, чтобы переживать о том, что я что-то упускаю, лучше сфокусироваться на поставленных целях и задачах и принять как норму, что в чём-то второстепенном я точно продолбаюсь. Но если раньше я бы переключался и тратил энергию на то, чтобы не допустить этот провал во второстепенном вопросе, то сейчас я могу со спокойной душой забить. Ведь я сфокусирован на более весомых задачах.

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

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

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

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

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

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

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

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

Суть: человек принимающий решения (например, менеджер проекта) просит подопытного срочно специфицировать новую фичу, которая "прям точно нужна, делаем 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: дать явный фидбек сотруднику, что так делать неприемлемо, договориться об изменении поведения.
Плюсы: сохраняем мораль команды (деструктивное поведение не будет распространяться), развитие сотрудника (для человека может быть открытием то, как его поведение выглядит со стороны).
Минусы: придется напрячься (в таких ситуациях нужно ОЧЕНЬ хорошо подготовиться в общению), риск потери приятельских отношений и появление напряжения в отношении с сотрудником (не все адекватно воспринимают фидбек).

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