Привет 👋 Меня зовут Тёма Пулявин, и последние 3 года я — технический директор в каршеринге Ситидрайв.

— «Перейдём на "ты", комфортно будет?» — с этой фразы я начинаю свои вопросы на собеседованиях. Мне привычнее общаться на «ты», поэтому и здесь я буду придерживаться этой практики. Спасибо за понимание 😊

Возможно, мы уже пересекались с тобой, когда я работал в Mail.Ru Group, Alpina Publisher или Mamba.

А может — в одном из многих стартапов, всех и не упомнишь, где я участвовал как engineering manager или даже как founder: Explory, PayText.Ru, FoodFox, Unitemp, FoodMate, Oprosso.

Или ты проходил мой курс по back-end разработке на Otus — или смотрел его в записи. А может, видел меня выступающим на DevConf, «Стачке» или Frontend Conf.

В любом случае, где-то мы с тобой точно пересекались!

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

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

😎 — Тема в точку и раскрыта как надо
🤔 — Неплохое чтиво на вечер
🤨 — Мог бы и лучше, уверен
🥴 — Вообще мимо, не зацепило

Писать буду о том, что точно не оставит равнодушными тимлидов, инженеров, продакт- и проджект-менеджеров.

Ну что, поехали 🚀 Подписывайся!

P.S. На фотографии — я в средней образовательной школе где-то в Бенине.

Выгорание подчиненного — это факап его руководителя…

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

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

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

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

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

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

Полностью контролировать сотрудника, ограничивая каждое его движение, особенно во время твоего обеда — не то, к чему стоит стремиться. Гораздо важнее — развивать в команде зрелую самостоятельность.

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

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

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

Если проблему можно решить деньгами — то это не проблема…

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

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

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

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

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

Что стоило сделать, когда Серёжа впервые пришёл с оффером? Важно понять, что его до этого состояния довело:
👉 Может, это сложный проект с бесконечным количеством правок, который тянется последний год;
👉 Может, ты недавно повесил на него дополнительную ответственность, и это дало перегруз;
👉 А может, это затяжной эмоциональный конфликт с соседней командой.

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

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

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

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

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

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

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

Работая в корпорациях, под высокой нагрузкой, с постоянным переключением контекста и большим потоком задач, которые нужно порешать, я выработал для себя идеальную формулу хождения в отпуск. Я хожу в отпуск минимум 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?