Привет! Напомню, что мы анализируем развитие нашего подразделения по методологии Адизеса и сейчас находимся на этапе «Давай‑давай» ближе к его окончанию. В прошлом посте мы подробно разобрали одну из пяти ключевых проблем этого этапа. Сегодня поговорим, пожалуй, о самой сложной: монополизации и последующей институционализации E‑функции (предпринимательской роли).

Почему это проблема?

По Адизесу, к концу этапа «Давай‑давай» компания должна начать передавать E‑функцию от основателя другим сотрудникам. Причина проста: организация растёт, задач становится всё больше, и основатель неизбежно оказывается в «Ловушке основателя». Он пытается единолично принимать маркетинговые, технические, финансовые и кадровые решения — хотя по‑настоящему силён, как правило, лишь в одной области. В нашем случае ситуация сложилась иначе: основатель к этому моменту уже покинул компанию, а значит, не мог осуществлять преград в этом деле. Дополнительно здесь нам сильно помогла матричная структура.

Как мы распределяли E‑функции с опорой на модель Адизеса

В книге Адизеса есть наглядная схема (приведена ниже), показывающая четыре подсистемы организации и их связь с PAEI‑ролями. Каждая подсистема включает компонент развития (e) и компонент сохранения (p): * Взаимодействие с клиентами (E): Маркетинг (e) — поиск новых возможностей и рынков, Сбыт (p) — непосредственно продажи; * Трансформация (P): Конструирование (e) — внедрение новых технологий, оптимизация процессов разработки, Производство (p) — собственно реализация новых программных функций; * Человеческие факторы (I): HR-отдел (e) — обучение и рост сотрудников, Управление персоналом (p) — поддержание корпоративной культуры, мотивация; * Финансовые факторы (A): Финансы (e) — инвестиции и рост доходов, Бухучет (p) — контроль расходов и финансовая устойчивость.

Мы постарались распределить эти подсистемы между разными руководителями. На тот момент мой отдел разработки мобильных приложений насчитывал около 25 iOS‑разработчиков и 35 Android‑разработчиков. Я был единственным формальным руководителем всей команды. В мои обязанности вошло: * представлять и продвигать наш отдел перед бизнесом (владельцами продуктов) — Маркетинг E(e); * прорабатывать развитие и эффективность производственных процессов — Конструирование P(e).

Владельцы продуктов, в свою очередь, отвечали за финансовые аспекты (A): бюджетирование, оклады, премии, окупаемость команд и т. д – Финансы, P(e) и Бухучёт P(p).

Управлять таким большим отделом (при общепринятой норме управляемости в IT – 7–10 сотрудников) было невозможно в одиночку. Поэтому я выделил шесть доверенных сотрудников — каждый курировал подгруппу из 7–8 разработчиков. Важные нюансы: * формально эти сотрудники оставались рядовыми разработчиками — штатных руководящих позиций тогда не было; * 70 % времени они работали в продуктовых командах наравне с остальными; * оставшиеся 30 % посвящали административным и управленческим задачам.

Со временем мы вывели некоторых из этих специалистов на руководящие должности — так они смогли полностью сосредоточиться на управлении персоналом и процессами. В их зону ответственности вошли найм (E), документооборот (A), мотивация команды (I). Все то, чем обычно занимается HR-отдел и отдел управления персоналом. Да, да, этими функциями пришлось заниматься напрямую нашим руководителям отделов, о чем я, например, совсем не жалею. В их зону ответственности также вошли и общие между продуктовыми командами рабочие процессы P(p).

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