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

Ставка на рост: джуны вместо 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).

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

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

Код PaEi

Анализ показывает, что после слабого этапа «Младенчества», код которого в наших условиях был P-e-, мы существенно подтянули функции а, E и i и вышли на устойчивый код развития PaEi, необходимый для этого этапа – мы не просто реагировали на изменения, а учились управлять ими через баланс PAEI-ролей. Это позволило нам не только выжить в условиях постоянных реорганизаций, но и выработать навык работы в турбулентной среде. Руководителя с таким кодом Адизес называет «руководителем-профессионалом», т.к.он руководит с упором и использованием профессиональных знания и умений.

В следующем посте мы поговорим о делегировании полномочий, а также о монополизации и институционализации Е‑функции. Здесь наши действия были не самыми лучшими — и история получится уже не такой радужной. Но не ради ли этих историй люди читают чужие канальчики, верно? :)

До связи.

Проблемы этапа «Давай-давай» и способы их лечения: постоянные изменения и реорганизация

В предыдущем посте мы убедились, что оказались на этапе развития «Давай-давай» по Адизесу, а также обозначили 5 основных проблем, характерных для этого этапа. Сегодня я хочу подробнее рассказать, как именно эти сложности проявлялись в нашей практике и каким образом мы с ними справлялись — начнем с темы постоянных изменений. В скобках я буду указывать PAEI-код каждой активности, а в заключении мы подведем итог, как же выглядел наш код на этом этапе.

Постоянные изменения

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

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

Именно так выглядело и наше развитие. Мы существенно расширили штат (Е) — и тут же столкнулись с текучкой. Едва удалось стабилизировать ситуацию за счёт контроля перегрузок и документирования процессов (А), как бизнес поставил новую задачу: ускориться за счёт сокращения времени на исправление багов. Мы внедрили модульные тесты (АI) — количество ошибок снизилось, а время на их устранение сократилось. Но тут же последовал новый запрос: ускорить поставку фич (P).

Мы снова отреагировали: стандартизировали практики разработки (A), начали переиспользовать код (PA), создали единую дизайн‑систему (PAI). И снова — новый вызов: бизнес захотел независимых релизов для разных продуктовых команд.

На всё это накладывались внешние факторы: пандемия, санкции, необходимость импортозамещения. Они тоже требовали порой радикальных реорганизаций (I). Каждое такое изменение не просто меняло процессы — оно заставляло нас полностью перестраиваться. Работать по‑старому под новые завышенные требования было невозможно. При этом критически важной становилась сильная А‑функция: нужно было повышать эффективность здесь и сейчас, в краткосрочной перспективе.

Заметьте: способов повысить эффективность (AI) оказалось множество, и все они требовали внимания. Если бы мы попытались взяться за всё сразу, ничего бы не вышло. Мой личный девиз того периода звучал так: «Схватимся за всё — не вывезем ничего». Мы сознательно выбирали 2–3 ключевых направления на квартал, но внутри каждого прорабатывали сразу несколько подходов (EI). К примеру, чтобы сократить время на исправление багов, мы не только внедряли модульные тесты, но и активно продвигали принципы Low coupling/High cohesion — это помогало упростить взаимосвязи в коде и снизить его сложность (I).

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

Итог

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

Последние 5–6 лет прошли для нас в режиме непрерывной трансформации (I). Каждый квартал мы работали чуть иначе, чем предыдущий: поток изменений не останавливался ни на секунду (E). Но, оглядываясь назад, я понимаю: мы не просто выжили в этой турбулентности — мы выработали навык эффективно работать в условиях постоянных перемен. В будущих публикациях вы ещё не раз увидите, как этот опыт помогал нам решать новые задачи.

За этот месяц добавилось
4 темы:
- про одновременное достижение цели сразу несколькими способами, увеличивающими вероятность успеха;
- про презумпцию профессионализма и принцип позитивного намерения;
- про концепцию обратимых и необратимых изменений;
- про ИИ (куда ж без него?).

Количество тем для ретроспективы достигло 6 десятков.

Дорожная карта

Привет, друзья!

Этот пост — динамическое оглавление канала. Здесь будут собираться ссылки на ключевые публикации, сгруппированные по темам. Со временем он превратится в удобный навигатор: вы сможете быстро найти материал по интересующей вас теме, не пролистывая всю ленту канала.

1. Инструменты ретроспективы
2. Стартовая точка ( STAR, «Младенчество», P-e-)
3. 20% технического времени: как не превратить инвестиции в потери (EI)
4. Core‑команды — миф о супергероях в разработке (EI)
5. Core-команды: оберег
🪬 от решения ваших проблем (EI)
6. Технический долг как симптом болезни: диагноз и лечение (PAI)
7. О вреде рефакторинга и сокращении его необходимости
(Вопрос-ответ, PAI)
8. Лучшие практики по миграции с ObjC на Swift (PAI)
9. Модуляризация – локализация изменений (PAI)
10. Дух стартапа в Энтерпрайзе: плюсы модуляризации (AI)
11. Как модуляризация укрощает хаос связей: от экспоненты к линейности (AI)
12. Неудачная модуляризация (STAR)
13. Сложности модуляризации и их решения (PAI)
14. Экстенсивный vs интенсивный (AI)
15. Взрывной рост и текучка (STAR, «Давай-давай», PaEi, проблемы этапа и пути их решения)
16. Институционализация Е-функции (АI)
17. Доверие (I)
18. Презумпция профессионализма (I)
19. Ставка на рост: джуны вместо A+ (I)
20. Синергия и фокусировка (I)
21. План Б, Ц и Д (E)
21. Организация процесса («Юность», код, pAEi?)
23. Исчерпывающая документация (A)
24. Стандартизация практик разработки (A)
25. Шаблоны проектирования (AI)
26. Переиспользуй это! (PA)
27. Модульные тесты (PAI)
28. Не позволяй разработчикам ошибаться — (AI)
29. Пилоты/эксперименты/PoC — (E)
30. MVP и PoC— выкинуть или рефакторить? (AI)
31. Обратимые и необратимые изменения - (I)
32. Сложности внедрения — (I)
33. Автоматизация процесса — (AI)
34. Формирование Цели и Стратегии подразделения — (I)
35. Франшиза?
36. "Расцвет" по Адизесу
37. Избегание ненужных работ — (I)
38. Святое импортозамещение — (I)
39. Вверх по пирамиде тестирования: скриншот- и интеграционные тесты — (PAI)
40. Мультирезпозиторий против монорепозитория – (PAI)
41. Сокращение времени регресса — (AI)
42. Метрики — (AI)
43. Невероятные X10-программисты и где они обитают
44. Оптимизации
45. Апгрейд дизайн системы - (EI)
46. Автогенерация кода vs шаблонный код - (AI)
47. Безопасность — (I)
48. Неудачи?
49. "Поздний расцвет", "Старение", сокращения штата
50. О святой вере в научный метод
51. Искусство vs ремесло
52. Как читать книги? (AI)
53. Что дальше?
54. Дашборд.
55. Развитие доверия, уважения и принадлежности — (I)
56. Эволюционная архитектура? — (PAEI)
57. Омниканальность? (PEI)
58. Искусственный интеллект - (PAEI)
59. Экономия на внутренней интеграции (I)
60. Личные выводы: Что я приобрёл? Чем горжусь?
61. …

Пишите мне, какие темы добавить в дорожную карту — я учту ваши пожелания при планировании контента!