Применяем модель Херси — Бланшара
Сегодня рассмотрим как практике использовать модель Херси — Бланшара в управлении людьми.
Зачем вообще нужен разный стиль руководства
Когда команда маленькая, ты реагируешь интуитивно: одному даёшь больше свободы, другого держишь под контролем. Но когда в команде 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 до аналитики и управления процессами. Обучение органично встраивается в работу и помогает сделать команду сильнее, не останавливая проект.