Використовуємо Org Topolgies для оцінки стану military tech стартапу в Україні

💡 Усі статті, обговорення, новини про оборонні технології — в одному місці. Приєднуйтесь до DefTech спільноти!

Вітаю, мене звуть Тетяна Голуб. За свою кар’єру я пройшла шлях від першого Скрам Майстра в Райффайзен Банку і Менеджера програм у Люксофті до консультанта розвитку менеджерів та організацій. Понад 13 років я працюю з розвитком команд та зростанням лідерів.

В Україні сьогодні досить багато організацій military tech, котрі розробляють продукти для оборонно-промислового комплексу нашої держави. Більшість з таких організацій мають виклики, які не відрізняються від складнощів компаній в інших доменах. Адже команди та організації всюди формують люди.

В цій статті я хотіла б познайомити з методом оцінки організацій, котрий може допомогти багатьом компаніям переосмислити їхню організаційну структуру та змінити культуру. Наше знайомство буде відбуватися на прикладі опису кейсу military tech стартапу (з дозволу СОО компанії).

Коротко про Org topologies

Метод Org Topolgies був створений Олексієм Кривицьким на базі свого величезного досвіду співпраці з різними організаціями на їхньому шляху трансформації.

Мапа 2×2 — це фактично дизайн організації залежно від типу активності (та їх характеристик), котру виконує підрозділ, команди команд, команди або AI-агенти.

Метод Org Topologies містить наступні етапи:

• Мапування (Map) системи «як вона є».
• Оцінка (Assess) системи «як вона є».
• Дизайн майбутньої системи.
• Перехід зі стану системи «як вона є» в «майбутній стан».

Залежно від того, в котрий з квадрантів були замаповані активності команди, є три топології організації: Resource, Delivery чи Adaptive.

Метафорично три топології можна назвати таким чином:

• Ресурсна (Resource) топологія — «машина»- має на меті досягнення максимальної ефективності та утилізації ресурсів (усіх, в тому числі людських).

• Делівері (Delivery) топологія -«спеціалізована бригада» реалізується завдяки кросфукнціональним командам з фокусом на делівері зрозумілого обсягу роботи.

• Адаптивна (Adaptive) топологія -«стартап»- фокусується на адаптивності команд на рівні всього бізнесу та має на меті задоволення клієнта (а не впровадження конкретної фічі).

Трошки інформації про military tech start-up

Стартап був заснований трьома друзями як хобі-проєкт одразу після початку вторгнення в Україну. Основна діяльність — виробництво FPV-дронів.

Як і більшість стартапів, історія почалася з невеликої команди «як сім’я» до 20 осіб із кросфункціональним (на перший погляд) підходом. Головними клієнтами стартапу спершу були більші виробники, які постачали на фронт мільйони FPV-дронів.

Усі члени команди завжди мали сильну мотивацію працювати в такій організації, адже або втратили близьких на війні, або їхні рідні досі служать у Збройних силах України.

Тобто раніше org topology виглядала адаптивною (Adaptive), допоки команда була маленькою. Мапа 2×2 виглядала тоді приблизно ось так: усі члени команди виконували задачі у квадранті Driving, окрім двох функцій (юристи та бухгалтерія), котрі з самого початку були віддані на аутсорс, тому тяжіли в квадрант Doing.

Наразі стартап росте, щоб масштабувати виробництво (більше людей зможе збирати більше готової продукції). Під час масштабування сімейна організаційна структура перестає бути ефективною. Більше того, виявилося нереалістичним розширювати команди без впливу на виробничу лінію (найдосвідченіші члени команди відволікаються на навчання та менторство новачків).

Головний виклик, з яким стикається клієнт, — утримання команди під час зростання та підтримання належного рівня ефективності виробництва.

Запит від COO

Під час початкових сесій COO компанії висловила критичну потребу в змінах. Її турбувала поточна культура команди. Старші члени команди, які були першими співробітниками та тепер виступають інструкторами для новачків, схильні до токсичності та маніпуляцій, що негативно впливає на команду загалом.

Ми розглядали різні інструменти для вирішення культурної проблеми. Постало питання: якщо змінити оргструктуру, чи зміниться й культура команди?

Тому було прийнято рішення спробувати Org Topologies. Ми визначили кілька етапів: спочатку зафіксувати поточну організаційну структуру та її місце в рамках трьох топологій. Потім вирішити, чи потрібно змінювати оргдизайн. Якщо так — якою має бути цільова модель.

Як ми намагалися впровадити Org topologies в дію

Коли починаю трансформаційний процес з організацією, я зазвичай документую все, що можу отримати «з поверхні» — від історій до схем.

У цьому випадку через міркування безпеки (щоб потрапити на територію, потрібно пройти перевірку служби безпеки, що зайняло час) ми проводили експеримент онлайн за допомогою Miro.

Відображення наявної організаційної структури

Ми намалювали просту візуальну діаграму, як працюють усі підрозділи поточної організації та які функції потенційно потрібні, щоб робота не зупинилась. Варто зазначити, що не всі підрозділи наразі саме так виглядають — це скоріше таргет оргструктура, яку бачить СОО найближчим часом.

Очевидні висновки з цієї простої вправи були дуже показовими:

• Засновники не залучені у виробничий процес.
• Більшість ролей (підрозділів), зображених на схемі, фактично виконує одна людина, яка «носить кілька капелюхів», що працювало для Adaptive Org Topolgies, але перестало працювати для Resource org topolgy.
• Через багатозадачність деякі функції час від часу блокуються.
• Якщо команда НЕ буде розширюватися за ролями, організація не зможе масштабувати виробництво.

Де наш стартап серед трьох топологій

Коли ми відобразили підрозділи та ролі на 2×2-мапі, чітко проявилася ресурсна (Resource) топологія з нетиповим втручанням COO у «Driving realm».

Деякі конкретні спостереження, які стали зрозумілими на цьому етапі:

• Збирачі FPV-дронів не відчувають відповідальності за свою роботу (не приходять на зміну, не попередивши керівника; чекають на абсолютно чіткі інструкції, що й коли робити).
• Водночас вони вважають, що мають право й навіть обов’язок вказувати колегам на те, що ті «не виконують роботу належним чином».
• COO (наш клієнт) постійно ділиться надлишковою інформацією з усією командою й пропагує командні цінності.

Результати аналізу

В процесі аналізу поточної топології організації COO проговорила, що змінювати організаційну топологію не бачить сенсу. Тобто ми не рухалися з клієнтом далі по наступних двом етапам методу Org topology — Design and Elevate.Таким чином ми не отримали відповідь на питання, чи зміниться культура компанії зі зміною оргдизайну (culture follows the structure).

До чого я особисто дійшла в процесі аналізу: кейс military tech start-up є яскравим відображенням, як часто на початках адаптивна компанія під час масштабування робить крок не вперед, а назад з точки зору оргдизайну — у бік ресурсної топології.

Перехід в ресурсну топологію відбувся таким хаотичним чином, що СОО вимушена гасити міжособисті пожежі в команді збирачів та інструкторів FPV-дронів, не лишаючи часу для СОО спілкуватися з реальними замовниками.

Тому станом на сьогодні прийнято рішення стабілізувати ресурсну топологію організації як вона є:

• Будуть введені чіткі посадові інструкції, щоб кожен збирач FPV мав чітке уявлення, які задачі входять в його обов’язки.
• Також буде проведено майстерню для створення домовленостей у командах (Team agreement), щоб після зростання вони мали чіткі правила взаємодії.

Після стабілізації СОО та її підлеглі менеджери зможуть вивільнити капасіті для розвитку бізнесу замість того, щоб вручну управляти командою.

Гонка за Agile, бо то наразі модно, — взагалі некорисно для виробничої організації, котра має зовсім інші цілі. Інколи замість стрімких кроків вперед з надривом варто зафіксувати поточний стан системи та взяти паузу перед наступним етапом змін.

Підписуйтеся на WhatsApp-канал DefTech спільноти!