Отпуск — это для слабаков!

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

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

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

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

💡 Но важно не только следить за выполнением своего графика отпусков, а ещё и своих подчинённых! Если кто-то засиделся и последние полгода в отпуск не ходил — самое время напомнить, насколько это важно, и отправить сотрудника отдыхать.

P.S. На картинке это не галлюцинация AI с третьей рукой — просто cabana boy принёс пинаколаду и скромно ушёл из кадра 🙃

В жизни каждого лида наступает тот самый неожиданный момент, когда приходит HR и говорит: «А напиши-ка список обязанностей к кандидату для новой вакансии разработчика в твою команду».

И часто получается вот такой списочек обязанностей:
🔸Разрабатывать и поддерживать микросервисы на Python 3.x, используя лучшие практики и принципы SOLID, DRY, KISS
🔸Писать чистый, хорошо документированный и тестируемый код
🔸Участвовать в code review, обеспечивая высокое качество кода
🔸Решать задачи по оптимизации производительности и масштабируемости микросервисов
🔸Участвовать в разработке и улучшении архитектуры микросервисов
🔸Вносить свой вклад в создание и улучшение технической документации
🔸Активно участвовать в обсуждениях и принятии технических решений

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

Что здесь не так? Давай разбираться.

☝️Во-первых:

Уверен, это далеко не всё, чем предстоит заниматься разработчику на этой позиции. Много внимания уделено хард-скиллам и бесконечному улучшению всего, что есть в сервисе, но ничего не сказано про процессы в команде — будет ли сотрудник грумить задачи, участвовать в планировании и оценке, делать демо? Или вот: код должен быть чистым, документированным и тестируемым — а чтобы он был безопасным с точки зрения ИБ, это разве не нужно? Само собой подразумевается — скажешь ты. ОК, тогда едем дальше.

✌️Во-вторых:

Один и тот же смысл повторяется разными словами в разных пунктах, например:
🔶«Решать задачи по оптимизации производительности и масштабируемости микросервисов»
🔶«Участвовать в разработке и улучшении архитектуры микросервисов»

Или же одно — это просто обобщение другого. Например, выполнение принципов DRY и KISS — это частный случай написания тестируемого кода.

Список обязанностей для вакансии — это лишь один из видов списков, которые тебе предстоит составлять. Есть ещё регламенты, инструкции или тезисы для аргументации расширения найма в команду.

И чтобы все твои списки выглядели убедительно, они должны соответствовать следующим правилам:

👉 Убедись в полноте списка (Collectively Exhaustive) — в нём должно быть всё, чтобы покрыть предмет описания. Если пунктов много — сгруппируй их по логике
👉 Сгруппировал? Теперь проверь, что уровень абстракции и гранулярности у всех пунктов одинаковый — чтобы не вышло что-то вроде: лето, зима, январь, осень
👉 И напоследок — пробегись по списку и убедись, что пункты не пересекаются и не дублируют друг друга (Mutually Exclusive), и что один не является обобщением другого

Эти правила описывают принцип MECE (Mutually Exclusive, Collectively Exhaustive), который был разработан в McKinsey и уже более 50 лет используется консультантами для чёткого и логичного структурирования информации.

❓А твои списки соответствуют принципу MECE?

О чём говорить с сотрудником на one-on-one?

Да о чём угодно, серьёзно! О спорте, рыбалке, прочитанной книге на выходных или о финансовых показателях компании за последний квартал. 1:1 — это ещё один инструмент в арсенале руководителя, и каждый сам решает, как именно его использовать.

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

Если, к примеру, сотрудник заинтересован в твоём менторстве, опыте и росте, а ты каждый раз рассказываешь, как прошёл очередной уровень в Split Fiction, при этом не вникая в его рабочие проблемы и тревоги — всё это прямая дорога к его демотивации. Как следствие — выгорание, конфликты, уход.

Где-то встречал мысль, что идеальное распределение на 1:1 — это когда 30% времени говорит менеджер, а 70% — сотрудник. Тут всё индивидуально и зависит от самого сотрудника, его уровня зрелости и текущей ситуации:

☝️ Иногда сотруднику нужно просто выговориться — тогда у него 100%, у тебя 0%
✌️ Иногда сотрудник приходит со списком вопросов — и ты в ответ говоришь 90% времени
🤟 А бывает, обсуждаете что-то по-партнёрски — 50% на 50%

Но если все ваши 1:1 проходят в формате, где ты непрерывно говоришь, а сотрудник только кивает — это тревожный сигнал. Твоя задача — понять, что происходит, а не просто делиться своим мнением. Дай сотруднику пространство, не перебивай, не спеши “лечить” советами.

💡И главное — не бойся тишины.

Один из моих бывших руководителей как-то сказал: «Для взрослых людей молчание — это тоже разговор». Твоя задача — услышать сотрудника, ведь чем больше говоришь ты, тем меньше раскрывается он. Если сотрудник задал вопрос — не спеши с ответом, возьми паузу. Если он задумался — не заполняй тишину своим комментарием. Используй паузу как инструмент — пусть он сам её заполнит.

Свои 1:1 я всегда начинаю с вопроса: «Привет! Как настрой, какие новости?», давая сотруднику полную свободу выговориться в свободной форме, а сам в это время слушаю, фиксирую уточняющие вопросы и задаю их только после того, как он полностью выскажется — не перебивая.

❗️Помни, сотруднику важно твоё личное внимание, оценка его работы и мнение по событиям в команде или компании, но не занимай всё пространство собой — встреча не про то какой ты классный 🙃

Не забывай хвалить сотрудников

Причём сразу — не жди 1-2-1, ревью или какой-то другой формальной встречи.

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

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

А если хвалить не за что?

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

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

Поэтому,
👉 если тебе важно, чтобы сотрудники проявляли инициативу — и кто-то её проявил, похвали
👉 если тебе важно, чтобы в команде помогали друг другу — и кто-то помог, похвали
👉 если сотрудник нашёл элегантное решение проблемы — скажи, что это именно тот уровень, который ты хочешь видеть

Но⚡️Важно не просто отправить эмоджи сердечка в мессенджере или похлопать рукою по плечу — важно объяснить, за что именно ты хвалишь и почему это важно: тебе лично, команде или компании в целом.

Обычные фразы вроде «Круто, молодец!» или «Супер, так держать!» — не говорят, что именно было сделано хорошо, и не дают сотруднику ориентира, чтобы он мог повторить этот успех снова.

Так, а как хвалить? Да как тебе удобно:
👉 можешь — публично, а можешь — приватно, на 1-2-1
👉 можешь — написать в мессенджере, а можешь — проговорить голосом

Тут я большой разницы не вижу — главное, чтобы суть была донесена.

Единственное — будь осторожен с публичной похвалой.

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

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

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

❓А ты хвалишь своих сотрудников?

Красивая теория печальной реальности Story Points

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

Как это обычно происходит?

Команда начинает делать задачи без оценок. Через пару спринтов появляются первые «эталонные» задачи — те, которые понятны по составу, объёму и рискам. Таких задач набирается штук 5–7. Они сортируются по сложности по возрастанию: первой присваивается сложность 1 story point, второй — 2, и так далее, например, до 7.

Чтобы не возник соблазн сравнивать задачи арифметически (мол, «эта в два раза сложнее, чем та»), берут последовательность Фибоначчи: 1, 2, 3, 5, 8, 13, 21…

То есть первая задача получит 1 SP, вторая — 2, третья — 3, потом 5, 8 и т.д.

Дальше перед каждым спринтом команда оценивает новые задачи по этой шкале — с помощью Planning Poker, Bucket System или просто когда тимлид включает Expert Judgment и сам проставляет оценки.

В чём проблема?

Во-первых ☝️ высокая стоимость входа. Нужно минимум 3–5 спринтов, чтобы наработать список эталонов и начать по ним нормально оцениваться.

Во-вторых ✌️ оценка неуниверсальна. В одной команде «5 SP» — это одно, в другой — совсем другое. А если две команды совместно реализуют мета-фичу, продактам приходится ломать голову, как вообще выстроить общий релизный роадмап.

Получается примерно как в истории с Mars Climate Orbiter, когда NASA поручила компании Lockheed Martin разработку софта и ожидала, что конфигуратор будет работать в метрических единицах (ньютон-секунды), а Lockheed сделала всё в имперских (фунты-секунды). NASA настроила аппарат, запустила — и тот вошёл в атмосферу Марса слишком низко. В итоге 125 миллионов долларов налогоплательщиков сгорели в марсианском небе.

Но самая главная проблема — story points требуют регулярного обслуживания. Со временем эталонные задачи устаревают:
👉 технологии и подходы изменились — эталонные задачи стало делать проще
👉 состав команды меняется — никто уже не помнит, почему у той задачи было «8 SP»
👉 проект или доменная область команды меняются, и старые эталонные задачи уже оказываются неактуальными для новых реалий, а команда продолжает сравнивать текущие «красные» задачи с «тёплыми» задачами из прошлого

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

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

В лучшем случае команда пытается что-то с этим сделать: провести ревизию, как-то упростить или адаптировать систему, и, например, приходит к самому частому сценарию — когда говорят, мол, story point — это типа идеальный день разработчика. Если задача тянет на три таких идеальных дня, то и оценка ей «3 SP». Узнали себя?

Как жить в такой ситуации? Да никак. Каждая команда находит свой «уникальный» и невоспроизводимый путь, адаптируя оценку под свои реалии.

❗️ Самое главное — не врать себе, что твоя команда продолжает оценивать именно сложность задач в story points. Потому что чаще всего — вы просто оцениваете время. Но делаете вид, что нет.

Это, наконец-то свершилось — завтра в твою команду выходит новый сотрудник!

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

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

☝️ Первое, что нужно сделать до выхода сотрудника — подготовить список задач, которые он должен закрыть за испытательный срок. Определи, какие из них критичные — то есть обязательные, а какие nice to have — будет здорово, если он успеет сделать и их. Для себя пойми, что именно ты считаешь успешным выполнением этих задач. Продумай, как ты будешь проверять результат, по каким критериям и как в целом будешь оценивать его работу по итогам испытательного срока. Всё это ты будешь обсуждать с новичком — это и станут его целями на период испытательного срока. И если тебе всё понятно, важно сделать, чтобы и новичку было прозрачно: чётко объясни, что от него ожидается и по каким критериям ты будешь оценивать успешность его адаптации.

Во-вторых ✌️ выбери кого-то из своей команды в качестве бадди для новичка. Если ты ставишь задачи и проверяешь их выполнение, то нужен ещё один человек, который будет помогать новичку эти задачи выполнять. Бадди должен выстроить с новичком партнёрские отношения, быть с ним на равных, создать неформальный контакт и стать «своим человеком» — тем, кто поддерживает, объясняет, направляет. Это сделает процесс вливания в команду более мягким и понятным. Роль бадди помогает расти текущим сотрудникам и разгружает тебя как тимлида.

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

❗️ Почему это важно? Пришедший к тебе новичок уже имеет определённый опыт, сформированный в предыдущих компаниях — вместе с ним он приносит свои поведенческие паттерны и подходы к работе. В тех компаниях была своя культура и свои процессы, которые могут сильно отличаться от ваших. Это не значит, что человек «не подходит» — он просто действует так, как его научили раньше. Твоя задача — помочь ему адаптироваться и перестроиться под вашу культуру и ожидания. И чем раньше ты это сделаешь, тем быстрее он поймёт, что от него требуется, как у вас принято работать, и начнёт приносить пользу.

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

Очень хотел в этой заметке рассказать, через какие этапы онбординга проходят новички в моих командах, но это уже тема для отдельной заметки — stay tuned 🙃

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

Но как понять, таков ли он, за собеседование длиной в час? Спросить!

Серьёзно, просто спросить. Только не в лоб, конечно.

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

Ты когда-нибудь себе признавался в нечестности или безответственности? Нет? Вот и он тоже — нет 🙃

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

Как спрашивать?

Не надо придумывать гипотетические ситуации и просить кандидата представить, как бы он себя повёл. Пользы в этом мало. Например, если ты хочешь проверить результативность, то антипаттерн — это вопрос вроде:
👎 «Представь, ты делаешь важный проект, не укладываешься в сроки — что ты будешь делать?»
Спроси иначе:
👍 «Была ли у тебя ситуация, когда ты не укладывался в сроки? Что ты тогда сделал?»

Или ты хочешь проверить умение работать с конфликтами, и спрашиваешь:
👎 «Представь, ты не согласен с решением своего руководителя — как ты дашь ему фидбэк?»
Лучше спросить так:
👍 «Как ты строил работу со своим руководителем на прошлом месте? Были ли случаи, когда ты был не согласен с его решением? Расскажи о самой запомнившейся ситуации»

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

А если у него в принципе нет таких кейсов — это тоже сигнал 🧐 Например, странно слышать, что фронтенд-разработчик с 5+ годами стажа ни разу не конфликтовал с бэкендом из-за API.

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

Важно ☝️ не направляй его к «нужному» тебе ответу. Лучше держи паузу — дай человеку вспомнить, как всё было на самом деле. И не торопи. Этот метод — не про стресс. Тут наоборот — важно создать доверительную атмосферу, чтобы кандидат раскрылся. Это должно быть больше похоже на диалог, чем на допрос.

Такой способ общения с кандидатом называется поведенческим интервью.

Чтобы метод сработал, нужно заранее определить ключевые компетенции, которые ты хочешь проверить. Не пытайся охватить всё — 3–4 компетенции за интервью вполне достаточно. Иначе оно превратится в опросник по чек-листу, и это точно не будет похоже на живой разговор.

А ещё важно выбрать подходящую методику интервью. Их много разных, например: STAR, SOAR или DARE. У всех есть нюансы — в зависимости от того, какую сторону кандидата ты хочешь раскрыть. Я лично использую STAR — она универсальна и хорошо работает. В следующих заметках обязательно расскажу про неё и какие компетенции я через неё проверяю на своих собеседованиях.

❗️И не попади в ловушку. Поведенческое интервью строится на предположении, что прошлое поведение человека предсказывает его будущее поведение. Это в целом верно. Но люди — не статичны. Мы учимся, развиваемся и меняемся. Тот кейс, о котором кандидат рассказывает, может быть для него не провалом, а точкой роста. Он мог вынести из него опыт, стал мудрее, и в следующий раз поведёт себя иначе.

Вау! Я совершенно не ожидал собрать за сутки почти 100 подписчиков из своих контактов. И это для канала с не самой уж популярной тематикой! 🚀

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

💡 Оно старо как мир, но все менеджеры рано или поздно доходят до него сами и думают, что именно они его и придумали.

Контекст

В команду приходит новичок, и ты даёшь ему первую задачу. Он начинает разбираться и, конечно, натыкается на блокеры. Например, для сборки проекта нужно установить специальную переменную окружения, или вы осознанно сидите на старой версии компилятора, а новичок поставил новую — и в итоге ничего не собирается. Скорее всего, эта информация где-то у вас записана, и, возможно, вы её проговаривали на старте — но он мог не уловить. И вот он начинает искать доки, сражается с компилятором, проект не собирается, ошибки сыпятся, он лезет на Stack Overflow, пытается найти похожие кейсы, пыхтит и пыжится… Проходит 5, 10, 30 минут — а результата нет. Знакомо?

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

Именно 15 минут. Этого времени, как правило, достаточно, чтобы попытаться разобраться: поискать в доках, полазить на Stack Overflow, посмотреть логи.

❗️ Здесь же нужно дать и вторую установку: если новичок просит помощи, не разобравшись вовсе — нужно спросить, что он уже попробовал сделать. И если ничего — объяснить, что это перекладывание ответственности и нужно для начала предпринять самостоятельные попытки, а уже потом обращаться.

Почему это важно?

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

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

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

❓ А твои сотрудники не боятся попросить о помощи? Или всё ещё боятся выглядеть глупо?

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

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

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

Так как же принимать негативную обратную связь?

☝️ Для начала — перестань автоматически защищаться. Чувствуешь, как кулак сжимается, мозг отвергает услышанное, а рот уже готов выдать аргумент в ответ? Сделай паузу. Выдохни. Не спорь. Не оправдывайся. Особенно не отвечай агрессией на агрессию — особенно если разговор случился публично.

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

✌️ Раздели форму и суть. Точно так же, как ты учишься принимать обратную связь, твой руководитель может учиться её давать — и делает он это пока без заботы — жёстко и эмоционально. Да, форма важна. Но даже неидеальная форма не отменяет сути, которую стоит уловить.

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

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

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

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

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

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

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

Модель Такмана (Tuckman Model)

Эта модель описывает четыре последовательные стадии развития, через которые проходит любая команда. Она была предложена Брюсом Такманом в 1965 году. Стара как мир — но до сих пор актуальна.

Важно понимать:
👉 стадии нельзя «перепрыгнуть», но можно откатиться назад
👉 лидер может влиять на скорость перехода от одной стадии к другой — ускоряя или замедляя его

Мы набираем сотрудников и начинаем формировать ☝️ (Forming) из них команду — хотя пока что это всё ещё просто группа людей. Связи между участниками ещё не выстроены, «правила игры» отсутствуют, роли и границы размыты, и каждый сосредоточен на своих задачах. Общей цели, которая могла бы объединить, ещё нет.

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

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

Постепенно команда перезнакомилась, и начинается распределение социальных ролей. Люди начинают испытывать систему на прочность: оспаривать решения, критиковать, защищать своё мнение. Появляются локальные группки, которые «дружат» против кого-то — команда начинает «бурлить», и её шатает. Начинается Шторминг ✌️ (Storming).

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

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

Ну всё, поругались, наконфликтовались и наконец-то притёрлись друг к другу — начинается стадия 🤟 Norming. Команда поняла как работать друг с другом — кто, как и за что отвечает. Появляется уважение, люди замечают не только слабые, но и сильные стороны коллег. Роли устоялись, появились неформальные лидеры и первые элементы культуры. Причём культура начинает защищать себя: если кто-то ведёт себя не по правилам команды — остальные возвращают его к норме.

💡 Руководителю на этом этапе важно задать правильный культурный код, вокруг которого команда будет дальше развиваться. Это может быть культура ответственности, результата, взаимопомощи — а может, и культура подколов и токсичности.

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

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

Но… стоит в команде появиться новому человеку — и вся система откатывается в шторминг. Снова…

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

❓ А на каком этапе сейчас находится твоя команда?

Наконец-то мы разобрались с теорией и поговорили о модели Такмана — теперь можно перейти к практике 😎

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

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

И только работая над проектом VK Taxi в Ситимобил, мне удалось плавно, шаг за шагом, откатываясь в шторминг после выхода каждого нового сотрудника, пройти весь путь формирования команды — от 0 до 5 сотрудников. Вот про этот опыт я и хочу рассказать.

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

Итак, 2019 год 🙃 Мне предлагают возглавить разработку нового, экспериментального проекта внутри агрегатора такси Ситимобил — VK Taxi. Это front-end приложение для заказа такси на платформе VK Mini Apps, встроенное в соцсеть ВКонтакте.

До меня подрядчики уже сделали и запустили MVP, который даже генерировал ~30 поездок в день 🚀 Теперь же стояла задача развивать продукт и собрать команду вокруг него.

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

Поиск оказался недолгим — где-то через три недели ко мне присоединился молодой, дерзкий, но перспективный front-end разработчик.

Нас стало двое. И вот что я делал, чтобы он быстрее влился в работу и начал приносить пользу.

☝️ Во-первых — я не выстраивал иерархию «начальник–подчинённый»

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

Тут важно не забывать, что у сотрудника нет рядом никого, кому он мог бы пожаловаться на «тиранического» 🫡 начальника и просто выговориться. Накопленное недовольство, плюс чувство одиночества почти всегда заканчиваются конфликтом и увольнением.

В то же время не стоит сразу «дружить семьями». Это должны быть здоровые рабочие отношения. Команда, скорее всего, будет расширяться — вас откатит в шторминг, и сильная эмоциональная привязка может только осложнить этот период.

✌️ Во-вторых — я максимально увеличил частоту и скорость коммуникации

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

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

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

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

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

А о том, как всё меняется, когда в команде появляется второй и третий сотрудник — расскажу в следующем посте.

Stay tuned 👀

Хочу рассказать про одну из своих управленческих ошибок, которую я допустил вот уже как 10 лет назад, но осознание её пришло гораздо позднее.

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

Читалка хорошо продавалась в B2B-сегменте и, если мне не изменяет память, около 200 компаний развивали свои корпоративные электронные библиотеки с нашей платформой.

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

Так вот, сверстали road map проекта и там получилось несколько месяцев кропотливой и усердной работы: нужно было сделать кучу интеграций с интернет-магазином «Республики», синхронизировать купленные книги, настроить единую аутентификацию, в конце концов — разработать отдельную админку для команды поддержки «Республики». И всё это было на мне. А параллельно на меня ещё сыпались задачи из текущего B2B-стрима — кому-то нужно было докрутить фичу в корпоративной библиотеке, где-то починить баг.

В общем, зашивался я тогда знатно 🥵

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

От такого привалившего счастья менеджер насыпал нам почти в два раза больше задач. Шутка ли — нас теперь двое, значит, и работать будем в два раза быстрее! Но Олега надо погружать в проект, давать простые задачи, обсуждать его решения. Дедлайн проекта никуда не делся, моих задач меньше не стало, а на обсуждение задач с Олегом у меня банально не хватало времени.

А Олег был пытливый и небезразличный. Помню, как я пару раз пресекал его попытки обсудить текущую архитектуру проекта и подходы:

«Олег, у нас проект и его надо херячить. Будет следующий проект – там хоть каждый день будем с тобой архитектуру переосмысливать»

В общем, я бы не сказал, что это был лучший онбординг, который я провёл в своей карьере. Я не уделял Олегу достаточно внимания и не оказывал нужной поддержки. Стоит отдать ему должное — он был опытным, смог преодолеть этот этап и ещё долго работал в компании после моего ухода. Но, Олег, если ты читаешь это — прости меня 🤓

Этот кейс отлично иллюстрирует закон Брукса, сформулированный в книге «Мифический человеко-месяц» (The Mythical Man-Month, 1975):

«Добавление людей в запаздывающий проект только замедлит его ещё больше»

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

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

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

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

👉 обязательно нужно проговорить с менеджером, что не нужно с первого дня напихивать в road map проекта новые задачи в связи с выходом новичка – реальную пользу он начнёт приносить только через несколько недель, а вот снижение моей продуктивности стоит учесть как потенциальный риск

Вопроса в конце для саморефлексии не будет — скажу лишь, что дальше продолжу тему про рост команды 🙃

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

Итак, количество поездок в ВКТакси росло кратно из недели в неделю, и проект набирал популярность 🚀 Команда из двух разработчиков — меня и Максима (назовём его так для удобства) — уже не справлялась с объёмом продуктовых гипотез, которые сыпались от менеджера. Нам был нужен ещё один разработчик.

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

И у них с Максимом случился конфликт. И если бы только один — это была череда несогласий, конфронтаций во всех точках их взаимодействия. Максим проработал архитектуру, но Дима не согласен и предлагает кардинально другой подход. Дима отдал на ревью свою первую задачу, а Максим написал ему 100+ комментариев. Каждый из них выводил меня «покурить» по несколько раз в день и жаловался друг на друга.

👉 Позиция Максима понятна: «Я тут работаю уже несколько месяцев, кучу всего сделал, а Дима только пришёл, ничего не внёс, но уже указывает, как надо делать»

👉 Позиция Димы тоже понятна: «Я хочу привести новые крутые штуки в проект, а постоянно сталкиваюсь с возражением»

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

Скорость команды упала. Нас откатило в шторминг.

Выход каждого нового человека в команду вынуждает эту команду перестраивать социальные связи. Чем больше человек уже есть в команде, тем меньше и слабее этих связей обычно надо перестроить. Поэтому, например, выход нового человека в команду из 6 человек обычно происходит без большого стресса. У нас же с Максимом нужно было разрушить старые связи и строить всё заново уже на троих.

Что делать, шеф?

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

Забегая вперёд, расскажу, что так случилось с Максимом. Он, не получив от меня 100% поддержки, затаил обиду и через несколько месяцев покинул команду.

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

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

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

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

❓ А ты сколько штормингов помнишь в своей команде?

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

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

Давайте, для начала, вспомним, что это за модель такая.

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

Какие же это 5 типов?

👉 Инструментальный тип — для него деньги — это единственный мотиватор. За деньги готов работать дольше, сильнее, больше и даже по выходным. Переработку не оплатят? Тогда и ему нет смысла работать.

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

👉 Патриотический тип — ради компании готов хоть в лепёшку расшибиться. Если вовремя отмечать важность его вклада в развитие компании и выдавать почётные грамоты — это будет самый надёжный и верный сотрудник.

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

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

И вот недавно наткнулся на статью про то, как Герчиков разрабатывал эту модель — и меня осенило! Я понял, в чём у меня тогда было противоречие.

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

Уловил уже мысль, да? 60-е годы, Советский Союз времён Брежнева, завод, рабочие... Я вполне могу представить себе патриотичную 👩‍🏭 Дарью, которая с мыслями «Партия сказала — надо! Комсомол ответил — есть!» нарисовала стенгазету о том, что её завод — лучший в регионе по выработке норм часов, или же люмпена 🫠 Колю, который палец о палец не ударит, если ему не вставят пистон.

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

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

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

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

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

Можешь пройти тест Герчикова, чтобы убедиться, что ты не люмпен. А тем временем, нас уже 300+ 🚀

Однажды, работая в Ситимобил, я искал себе руководителя back-end разработки. Воронка была небольшой, выбирать было не из кого, а рекрутер постоянно сетовал мне, что не сезон и вообще, у меня очень высокие ожидания к профилю кандидата 😔

Думая, как же можно расширить воронку, ко мне в голову приходит идея, с которой я иду к рекрутеру и говорю — «Собери все профильные конференции и спикеров на них, пробегись по должностям, и тех, кто нам подходит, найди в LinkedIn и сразу предлагай им собес со мной».

И вместо «Хорошо, принято» я услышал — «Хорошо, только можешь накидать мне список сайтов конференций, с которых ты бы хотел, чтобы я посмотрела спикеров?».

Вот что тут произошло? Да чистой воды манипуляция! 😠 Я, как заказчик, пришёл поставить задачу рекрутеру, а вместо этого сам получил от неё задачу.

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

В обоих этих кейсах общее — сброс ответственности. Или, как пишут Уильям Онкен и Дональд Уосс в статье «Management Time: Who’s Got the Monkey?», опубликованной в 1974 году в Harvard Business Review, — произошла «передача обезьяны».

🐒 «Управленческая обезьяна» — это проблема или задача, которой кто-то должен заниматься.

И во втором случае, когда руководитель разработки услышал от меня: «ОК, я разберусь», — он пересадил свою обезьяну со своих плеч на мои. Конечно же, у меня полно своих дел, и я не бросил всё и не побежал разбираться, что там происходит между отделами. Но знаете, что сделал руководитель разработки через пару дней? Он начал «кормить» свою обезьяну, написав мне: «Подскажи, когда тебе удастся решить наш конфликт?».

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

Что делать, шеф?

👉 Научись понимать, когда на тебя хотят посадить чью-то обезьяну

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

👉 Если чужая обезьяна уже на тебе — верни её владельцу

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

👉 Отбивай желание вешать на тебя чужих обезьян

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

👉 Корми или пристрели обезьяну

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

❓ А сколько чужих обезьян сейчас на тебе?

Планирование Q3, Performance Review, стратегическая сессия — и меня знатно выкинуло из жизни на пару недель 😫 Заметка сама себя не напишет, поэтому надо наверстывать упущенное.

Лето, а значит, вы, как и я, погружены в процесс Performance Review — кто-то только начал собирать обратную связь по сотрудникам, а кто-то уже даже прошёл процесс калибровок. А дальше — дача обратной связи сотрудникам.

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

💡 Самое главное в фидбеке в рамках Performance Review — он должен быть предсказуемым для сотрудника.

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

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

В общем, разобрались: дача негативного фидбека в рамках Performance Review — это не про расправу и не про охоту за головами. Так про что это?

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

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

Чтобы фидбек выглядел убедительным и аргументированным, к нему нужно хорошо подготовиться:

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

И на самой встрече:

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

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

❓ А ты сам когда-нибудь получал негативный фидбек в рамках Performance Review?

Как-то мне в наследство перешёл в подчинение лид, и вот этот лид взял себе нового Golang-разработчика и на каждом 1:1 начал жаловаться мне на него: мол, перформанс низкий, слабо обучаем, тяжело управляем. Когда я спросил, какой же план по развитию этого сотрудника, мне лид сказал, что вообще не готов заниматься им. И на мой вопрос — А, собственно, зачем ты вообще тогда брал его на работу? — я получил очень удивительный ответ: А я и не хотел его брать, меня рекрутер заставил. Занавес.

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

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

Рекрутер 90% своего времени работает вне компании — он общается с холодными кандидатами и пытается всеми правдами и неправдами дотащить их до первого этапа собеса: где-то уговаривает, где-то давит, где-то продаёт. Как бы ни действовал рекрутер — его подходы работают, кандидаты на собесы идут, и KPI закрывается. И если уж кандидата удалось затащить на собес, то нет повода бросать проделанную работу на полпути — теперь надо кандидата тащить дальше до оффера и вывода на работу. И дело даже не в KPI, рекрутмент — это про достижение результатов.

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

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

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

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

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

❓ А на тебя давили рекрутеры?

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

Мы же с тобой хотим быть хорошими лидами 😎, поэтому давай попробуем сначала разобраться, что там по финансовым метрикам, и сегодня копнём в различие между Revenue и GMV.

💡 Важно! Для простоты расчётов в примерах я сознательно опускаю НДС. Но имей в виду: если товар продаётся за 1200₽ с 20% НДС, то в Cash Flow отражается вся сумма — 1200₽, а в P&L — только 1000₽, без НДС.

Любая компания либо продаёт товары, либо оказывает услуги. Представь, наша компания произвела и продала за месяц 100 холодильников по 1000 рублей. За 80 холодильников наши клиенты заплатили сразу, а за 20 — оплата пока задерживается.

Итого имеем:

👉 Выручка (Revenue): 100 × 1000₽ = 100 000₽ — это сумма всех продаж, независимо от того, оплатили их или нет.

👉 Входящий денежный поток (Cash In): (100 − 20) × 1000₽ = 80 000₽ — это поступление реальных денег в компанию.

👉 Дебиторская задолженность: 20 × 1000₽ = 20 000₽ — это деньги, которые покупатели уже должны, но ещё не заплатили.

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

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

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

Впрочем, не все компании продают товары или оказывают услуги собственного производства. Маркетплейсы — такие как Ozon, Wildberries или Авито — продают не свои товары. Агрегаторы, такие как Яндекс.Такси, Профи.ру или Травелата, — не свои услуги. В таких компаниях выручка — это не объём проданных товаров и услуг, а лишь комиссия (процент) с этих продаж.

Тем не менее, чтобы продемонстрировать масштаб бизнеса, маркетплейсы и агрегаторы часто акцентируют внимание на метрике GMV (Gross Merchandise Value) — это общая стоимость всех товаров и услуг, проданных через площадку.

Чтобы стимулировать продажи, маркетплейсы и агрегаторы раздают покупателям кэшбэки, промокоды, скидки и другие плюшки, например бесплатную доставку или же второй товар в подарок. Всё это называется CI (Customer Incentives). Самое забавное, что CI снижает стоимость товара для клиента, но в расчёт GMV всё равно попадает полная цена товара. Более того, GMV не учитывает возвраты товаров, а ещё включает в себя НДС 🙈

Представь, что мы — маркетплейс. За месяц через нашу площадку продали 1000 товаров по цене 1000₽ каждый. Всем покупателям мы раздали скидку в 10%, поэтому фактически они заплатили по 900₽ за товар. Таким образом, все клиенты заплатили: 1000 × 900₽ = 900 000₽

Однако 10% товаров оказались бракованными, и мы вернули деньги клиентам за 100 единиц. Следовательно, чистые денежные поступления после возвратов составили: 900 000₽ − (100 × 900₽) = 810 000₽

А теперь внимание, вопрос: сколько мы зачтём себе GMV? Правильно — 1 000 000₽ 🙈

Как ты уже понял, GMV — это просто красивая метрика, которая показывает товарооборот на площадке, но по ней никак нельзя понять, как в целом у компании идут дела. Часто бывает даже так, что площадка раздаёт сумасшедшие скидки клиентам: GMV летит в космос 🚀 а вот выручка — отрицательная 😢 Как в том анекдоте, когда мужик продавал рубль за 99 копеек: прибыли нет, но оборот бешеный.

❓ А сколько GMV в месяц делает твоя компания?

Дорогой друг, поделюсь с тобой своими переживаниями.

Так уж сложилось, что к вещам, которые я делаю, я отношусь основательно: планирую, реализую, вычитываю, выверяю и проверяю — это моя сильная сторона. Она же и слабая 😢 Там, где нужно на хромой козе въехать в дом из соломы и навоза — я не сильно подхожу. Сначала козу подлечу, потом дом укреплю, и только потом поеду. Результат, конечно, выше ожиданий, а если ещё и проект взлетит — его к тому же потом легче и проще поддерживать. Но если не взлетит, то спрашивается: зачем на всё это тратилось столько усилий, если можно было бы и без них?

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

И за последние два месяца ко мне несколько раз прилетал фидбек: «Тёма, у тебя лонгриды. Сокращай — тяжело читать!».

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

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

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

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

И не забывай ставить реакции к постам. Это мой источник дисциплины писать регулярнее.

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

На этом с моими переживаниями всё — дальше расскажу, как я изобретал унифицированную систему оценки задач для кросс-команд 🙂

P.S. На фотографии — я во дворце Гугун в Пекине.

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

Одной из моих постоянных задач было формирование новых команд разработки и расформирование старых. И я заметил, что каждый раз команды тратили много времени на то, чтобы адаптировать процесс разработки под себя. Часто они выбирали story points для оценки задач — и только где-то к пятому спринту успевал накопиться нужный объём задач, относительно которых можно было начать калибровать эти story points. Пять спринтов у мобильной команды — это 10 недель, или 2,5 месяца 🫠! И это ещё не считая того, что спустя какое-то время командам всё равно приходилось пересматривать эти «эталонные» задачи, чтобы оценки оставались актуальными.

Мы находились в фазе быстрого роста и не могли себе позволить тратить по 3 месяца на стабилизацию новой команды. Плюс была ещё одна проблема — story points разных команд не совпадали. А у нас частенько делались большие задачи на 2 и более команды — и продуктовые менеджеры просто не могли друг друга понять. Один менеджер говорил: «Эта задачка на 5 story points», — а другой менеджер не понимал, о чём речь, потому что у него в команде «5 story points» — это вообще про другое.

И мы поняли, что нам нужна другая система оценки — такая, которая была бы:
👉 понятна всем (как time-based подход),
👉 одинаковой для всех команд,
👉 простой во внедрении и не требующей постоянного обслуживания, как story points,
👉 и при этом — не скатывалась в абсолютную time-based точность, вроде «3 дня и 2.5 часа».

Мы нашли компромисс между гибкостью story points, которые позволяют оценивать сложность задачи, и time-based подходом, который фокусируется на времени выполнения. Так у нас и появилась абстрактная единица оценки — CityPoint (далее просто CP). Она аналогична часам, но при этом в оценке задач можно использовать только фиксированные значения: 1, 2, 4, 8 и 16.

Где:
👉 1 CP (~30 мин) — совсем мелочь, типа «сбегать за кофе» или «подвинуть компонентик на пиксель»
👉 2 CP (до 2 часов) — что-то несложное, типа «запилить формочку» или «накинуть фантик к анимашке»
👉 4 CP (до 4 часов) — нормальная задача, можно две такие за день закрыть
👉 8 CP (до 1 дня) — существенная задача, займёт весь рабочий день
👉 16 CP (до 2 дней) — крупная задачка, один день точно уйдёт, и второй зацепит

Итого,
👉 точная оценка тут не обязательна. Если есть уверенность, что задача займёт примерно 3 часа — нет нужды дробить её на подзадачи по 1 и 2 CP. Гораздо логичнее дать ей сразу 4 CP и спокойно в неё уложиться.
👉 даже если задача совсем мелкая — она всё равно должна получить оценку в 1 CP. Нет смысла объединять кучу мелких задач в одну и ставить ей какую-то общую оценку, или, наоборот, пытаться присвоить 0 супер-маленьким задачам.
👉 CityPoint задаёт и верхнюю границу тоже. Если кажется, что задача займёт около трёх дней — значит, её нужно декомпозировать на несколько задач. Максимальная оценка одной задачи — 16 CP.

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

❓А в чём ты оцениваешь задачи в своей команде? Если хоть в чём-то оцениваешь — поставь реакцию под постом. Хотя если не оцениваешь — тоже поставь реакцию 🙈

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

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

Логика там была абсолютно простой. Бюджет на senior-ставку был 350 000 рублей gross (и такие вилки когда-то были), и он был абсолютно уверен, что, наняв двух джунов до 150 000 рублей gross, он даже сэкономит 50 000 рублей компании с каждой senior-ставки, за что будет большим молодцом.

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

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

Через год случился performance review, и HR пришли с бюджетом на повышения. Изначально, для этих двух senior-ставок было забюджетировано повышение в 60 000 gross рублей на обе ставки суммарно, а вот джуны, которые херячили весь год, за год выросли и хотели повышения должности и повышения зарплаты — минимум +60 000 рублей gross каждый. И всё справедливо — выйдя на рынок, их точно бы уже оценили в middle и дали бы те самые 210 000 рублей gross.

Математика проста 🧮 Даже если взять экономию в 50 000 рублей с каждой senior-ставки и сложить с бюджетом на повышения в 60 000 рублей — это будет 160 000 рублей. Это меньше ожидаемых повышений, которые ожидают наши джуны — 240 000 рублей gross. И становится совершенно непонятно, откуда брать остальные 80 000 рублей gross. Повысить всем по чуть-чуть? Кому-то повысить, а кому-то не повысить? — все эти подходы ведут к нашей с вами любимой тройке развития событий: демотивации, конфликту и увольнению.

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

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

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

❓ А ты готов рискнуть и сплитить ставку? Поддержи автора — поставь реакцию под постом.