Мобильный Финтех – Кирилл Маканков

Ставка на рост: джуны вместо A+

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

Сегодня – о том, кого стоит нанимать к вам в подразделение на этапе «Давай-давай» по Адизесу.

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

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

Адизес в книге «Управление жизненным циклом компании» «обнаружил, что лидеры аномальных компаний, достигших данного этапа осуществляют дополнительные выплаты своим подчиненным, как бы покупая их согласие со своими действиями». Мы тоже этим грешили, учитывая уровень зарплат специалистов A+. Но нам это не помогло: такие специалисты к нам не особо шли, а те, кто пришёл, в итоге уходили.

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

Удивительно, но это сработало. Позже я нашел у Адизеса объяснение этому: на этапе «Давай-давай» компании организуются вокруг людей, а не ролей. Часто один сотрудник закрывает сразу несколько направлений: «Например, один известный мне президент компании возглавлял отдел закупок, отдел сбыта и конструкторский отдел. Работники отдела сбыта осуществляли также некоторые закупки, а бухгалтер время от времени подменял офис-менеджера». В таких условиях люди чувствуют свою ценность и незаменимость, даже не являясь экспертами в каждой из задач. Они готовы учиться и развиваться в любом деле, которым занимаются. Это как раз про джунов и мидлов: климат этапа «Давай-давай» им идеально подходит.

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

Вывод простой:

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

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

Не переключайтесь!

Презумпция профессионализма: как перестать бояться делегировать

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

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

Поэтому сегодня я расскажу несколько инсайтов, которые помогли мне пройти эту проверку.

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

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

Оказывается, второй принцип даже в закон о госзакупках внесен. 😳

В итоге эти два принципа позволяют снизить страх, что другие сделают плохо, а отвечать Вам. И заменить его другим – что сотрудникам не хватит знаний и профессионализма ^.^ Лично мне иметь дело со вторым страхом сильно проще, чем с первым. Здоровый контроль, обучение сотрудников западающим компетенциям, мой собственный профессионализм и уверенность в своих силах отлично страх отсутствия профессионализма у сотрудников закрывают.

Эффективно делегировать можно только тогда, когда в команде есть люди, которым действительно можно доверять. Но кто эти люди? Из специалистов какого уровня должна состоять команда? Из одних сеньоров? Может, стоит избегать джунов — ведь делегировать придётся даже самые сложные задачи? Об этом — в следующем посте. Спойлер: на стадии «давай-давай» по Адизесу лучше предпочитать (внезапно!) джунов…

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

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

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

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

Не переключайтесь!

Доверие (I)

В прошлой публикации я подробно (с картинками) рассказал, как мы институциализировали, т.е. децентрализовали и распределили Е-функцию.
А вот тут я делился опытом, как я зарабатывал доверие у своих сотрудников и вместе с ними — у бизнеса.

Сегодня поговорим о том, как мне самому приходилось выдавать кредиты доверия – и все ли они возвращались…

Децентрализация: не просто делегирование

Децентрализация — процесс непростой. По Адизесу, она принципиально отличается от делегирования:
- При делегировании руководитель принимает решение, а сотруднику передаёт только право его исполнить. Это безопаснее для лидера — он сохраняет монополию на принятие решений.
- При децентрализации сотрудникам (пусть и не всем, а самым доверенным) передаётся право принимать решения в рамках их компетенций.

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

Было ли мне страшно? — Конечно!
Был ли у меня выбор? — Вряд ли.

Тогда я еще не знал о методологии Адизеса, но прошел крутые курсы повышения квалификации руководителей в ПСБ. Там я освоил базовые принципы делегирования. Подсознательно я понимал: нужно делегировать именно принятие решений, а не только их исполнение. Можно сказать, жизнь сама подвела меня к тому, к чему Адизес шел десятилетиями.

Как это работало на практике

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

Случай 1: отсутствие тимлида

В некоторых продуктовых командах не было тимлида — и владельцу продукта приходилось брать эту роль на себя. Многие делали это органично: методология Scrum это предполагает. Но находились и те, кто пытался переложить управление продуктовой командой на технического руководителя — в том числе на меня. К сожалению, лично для меня это закончилось потерей одной из мобильных ролей. Что ж…

Случай 2: расширение зоны ответственности

Бывали и обратные ситуации: некоторые руководители чувствовали в себе столько сил, что начинали вмешиваться в зоны ответственности коллег. Особо часто этим «болели» именно технические руководители. Кажется, что и я сам был какое-то время подвержен этому пороку.
Позже в таких случаях я:
* хвалил за рвение — инициатива это хорошо;
* чётко обозначал границы;
* объяснял: я не против делиться задачами и принимать помощь, но прошу предварительно обсуждать это со мной — потому что право принятия решений в зоне своей ответственности я не делегировал.

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

Выводы: что я понял про доверие и децентрализацию

1. Умение слушать — ключ к разграничению полномочий. Если вы умеете слышать человека (а этому неплохо учит вот эта книга), то договориться о зонах принятия решений несложно. Главное — не жадничать :)
2. Не бойтесь доверять. Люди действуют из лучших побуждений. Если у них есть компетенции, они будут принимать решения не хуже, а иногда и лучше вас. А если ошибутся — вы всегда поможете исправить ошибку. Более подробно об этом будет мой следующий пост.
3. Великие свершения невозможны без децентрализации. Один человек не способен принимать столько верных решений, сколько принимают несколько дюжин квалифицированных сотрудников.

Что получилось в итоге

Наша структура не была идеальной: нехватка штатных руководящих позиций сдерживала рост. Но она позволила решить главную задачу этапа — распределить E‑функции и другие роли PAEI между разными людьми и уровнями управления:
* я взял на себя стратегическое развитие и представление отдела — Маркетинг E(e) и Конструирование P(e);
* владельцы продуктов управляли финансами и бухучетом – A(e), A(p);
* выделенные начальники отделов курировали процессы и персонал – I(e), I(p), P(p);
* тимлиды отвечали за выполнение продуктовых задач и связь с бизнесом – P(e), P(p).

Это снизило нагрузку на одного человека и создало систему, где предпринимательские и другие решения принимались на разных уровнях — то есть начался процесс институционализации E‑функции.

С какими сложностями мы столкнулись

Несмотря на прогресс, процесс шёл непросто. Основные трудности:
* в некоторых командах не было тимлидов — функции планирования и контроля оставались без ответственного;
* совмещённая роль «разработчик + руководитель» создавала перегрузку: 30% на управление часто оказывалось недостаточно;
* из‑за отсутствия официальных должностей возникали вопросы авторитета и зоны ответственности;
* несогласованность и непонимание своей зоны ответственности между различными руководителями.

Эти проблемы требовали решения — и мы постепенно их устраняли. Но подробности я оставлю для следующего поста: там мы подробно разберём, как преодолевали эти сложности и какие уроки извлекли.

Вывод

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

Главный итог: предпринимательская роль перестала быть монополией одного человека — ни один человек не стал «узким местом» для принятия решений. Решения начали приниматься на разных уровнях (Тимлиды могли управлять производством (E(p) + P(p)), владельцы продуктов контролировали бюджет (A), а я фокусировался на стратегии и эффективности производства (E(e) + P(e)), что сделало организацию устойчивее и гибче. Распределение подсистем по модели Адизеса позволило нам чётко определить зоны ответственности и сбалансировать развитие (e) и сохранение (p) на каждом уровне.

А у вас распределены E‑функции в команде? Не толкаетесь ли вы локтями с коллегами-руководителями? Делитесь в комментариях — будет интересно обсудить!

Институционализация E‑функции (AI)

Привет!

Напомню, что мы анализируем развитие нашего подразделения по методологии Адизеса и сейчас находимся на этапе «Давай‑давай» ближе к его окончанию. В прошлом посте мы подробно разобрали одну из пяти ключевых проблем этого этапа. Сегодня поговорим, пожалуй, о самой сложной: монополизации и последующей институционализации 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).

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