Привет, Хабр!

Сегодня рассмотрим как практике использовать модель Херси — Бланшара в управлении людьми.

Зачем вообще нужен разный стиль руководства

Когда команда маленькая, ты реагируешь интуитивно: одному даёшь больше свободы, другого держишь под контролем. Но когда в команде 5–7 человек и задачи сложнее обычного CRUD, без осознанного подхода быстро начнутся проблемы:

• Один человек тянет всё на себе и выгорает.

• Второй вроде опытный, но топчется на месте.

• Третий мотивацию теряет, хотя раньше был лидером.

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

Основа модели: компетентность и мотивация

У модели всего две оси:

• Компетентность (навык) — насколько человек умеет решать задачу.

• Мотивация (готовность) — насколько он хочет это делать, насколько вовлечён.

Комбинируя эти параметры, получаем четыре ситуации:

Senior‑разработчик может быть на уровне S1, если впервые берётся за ML. Или наоборот — мидл может быть на уровне S4, если он тащит фичу, которую писал уже 3 раза.

S1: человек хочет, но не может

Типичное поведение: глаза горят, много вопросов, путается, тормозит.

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

Что делать:

• Дать пошаговые инструкции.

• Не давать свободы — она здесь вредит.

• Постоянная поддержка и контроль на уровне задач.

Поведение тимлида: ты руководишь напрямую — сам ставишь задачи, сам проверяешь, сам корректируешь. Это нормально. Это не микроменеджмент, это нужно на старте.

Частые ошибки:

• Слишком быстро отдаёшь инициативу — человек теряется.

• Считаешь что «пускай сам разберётся» — теряется доверие.

S2: человек может частично, но уверенность падает

Поведение: раньше работал хорошо, а теперь тянет время, спорит с задачей, сомневается.

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

Что делать:

• Поддерживать, но не контролировать.

• Проговаривать, зачем нужна задача.

• Делать рефлексию вместе: что мешает, чего не хватает.

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

Частые ошибки:

• Продолжать давить — это усугубляет сопротивление.

• Полностью отпустить — человек уходит в фрустрацию.

S3: умеет, но мотивация нестабильная

Поведение: человек может сделать, но не делает. Или делает с холодным лицом, без инициативы.

Обычно это сеньор, который устал от «всё на мне», или опытный мидл, которого перестали замечать. Тут работает не контроль и не наставничество, а именно вовлечение.

Что делать:

• Показать, что он влияет на решения.

• Дать задачки, где можно выбирать подход.

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

Поведение тимлида: ты партнёр, а не руководитель. Ты не ведёшь, а включаешь человека в общее дело.

Ошибки:

• Не замечать отстранённость — в итоге потеряешь специалиста.

• Считать, что «раз делает, значит всё ок» — нет, не ок.

S4: всё умеет, всё хочет — не мешай

Поведение: человек берёт тему, сам разбирается, сам реализует, сам презентует. Тебе даже не надо проверять — всё работает.

Что делать:

• Доверять.

• Делегировать зоны ответственности.

• Подключать к найму, ревью, продуктовому планированию.

Роль тимлида: не вмешиваться в мелочи, но задавать стратегическое направление. И быть рядом, если что‑то пойдёт не так.

Ошибки:

• Давать мелкие задачи — это оскорбление.

• Микроменеджерить — выжжешь мотивацию за две недели.

Что делать, если в одной команде все четыре стадии?

Это нормально. Один человек может быть в S4 по фронту, но в S1 по DevOps. Или в S2 по задаче с Legacy‑сервисом.

Модель применяется не к человеку вообще, а к связке «человек + задача».

Практика:

• Раз в 2 недели делаем таблицу: кто где сейчас.

• Обсуждаем это на 1-on-1: «Как тебе даются эти задачи?», «Чего тебе не хватает?».

• На ретро прогоняем команду по модели и спрашиваем, как помочь.

Пример применения модели

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

Джун у тебя — на стадии S1: хочет, но не может. Ему ты даёшь подробный план, ревью каждый день, синки на коротких итерациях. DevOps — тоже на S1, но по другим задачам: он технически зрелый, но в бэкенде не ориентируется, поэтому ты по нему применяешь такой же директивный стиль, хотя формально он далеко не новичок. Мидл, который полгода был на фронте, но вернулся в бэкенд — это S2: уже может, но стал задаваться вопросами, теряет мотивацию. Ему ты даёшь больше обсуждений, вовлекаешь в проектирование и часто даёшь фидбек. А вот сеньор, который сам вытягивает целый модуль, — это чистый S4. Ты его не трогаешь, кроме согласования целей и рамок, а всё остальное он берёт на себя.

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

Заключение

Если ты руководишь одинаково всеми — кто‑то перегружается, кто‑то теряет мотивацию, кто‑то сгорает. Модель Херси — Бланшара помогает понять: что человек умеет, чего он хочет и что с этим делать.

Сильный лидер не давит. Он создает среду, где каждый работает в своём уровне.

Тимлид отвечает не только за задачи, но и за рост команды. Корпоративные программы OTUS закрывают этот запрос: гибкие форматы, практическая направленность и ключевые треки — от разработки и DevOps до аналитики и управления процессами. Обучение органично встраивается в работу и помогает сделать команду сильнее, не останавливая проект.

А чтобы оставаться в курсе актуальных трендов управления в IT и первыми узнавать новости о бесплатных мероприятиях, подписывайтесь на Telegram‑канал OTUS4Business.