Виклик

Розповім, що мені показала робота в корпорації.

Компанія, яка швидко росте. Багато відділів, чіткі ролі, оргструктура, що виглядає логічно на папері. У кожного є функція.

І все ж.

Коли команда потребує чогось від іншого відділу — уточнити дані, дістати доступ до системи, прийняти рішення, яке перетинає межі між відділами — відбувається цікава річ. Іноді надходить миттєва, якісна відповідь. Хтось каже: «Зараз гляну. Перевірю і повідомлю за годину». Допомагають не тому, що запит був ідеально оформлений, а тому, що розуміють — допомогти значить допомогти компанії досягати своїх цілей.

Іншим разом чуємо таке: «А де ви були три тижні тому? Ми не можемо все кинути. Опишіть, будь ласка, що вам потрібно у формальному запиті».

Одна компанія. Ті самі інструменти. Той самий Slack. Абсолютно різні реакції.

Легко сказати: перша реакція — здорова, друга — поламана. Спочатку я так і думав. Той, хто швидко допомагає — «гарний колега». Той, хто просить оформити формальний запит — «бюрократ, який захищає свою територію».

Але чим довше я дивився, тим ясніше ставало, що все не так просто.

Саме «швидка допомога» — це та реакція, яка порушує правила.

Ось чому. Відділ — це не просто група людей, які опинилися в одному Slack-каналі. Це система — зі своїми цілями, своїми пріоритетами, своїм внутрішнім станом, своєю картиною того, що термінове цього тижня. Інший відділ, поруч на оргструктурі, — це інша система, з іншим внутрішнім станом. Ці дві системи — рівні по ієрархії, але живуть паралельно. Жодна не всередині іншої і не контролює іншу.

Є правило щодо того, як дві системи одного ієрархічного рівня повинні взаємодіяти. Його ніхто не записав у корпоративній політиці, але воно таке ж реальне, як гравітація: дві окремі системи не спілкуються елемент-до-елемента. Вони спілкуються через рівень, який містить їх обидві.

У компанії цей рівень має ім’я — це те місце, де ці дві системи зустрічаються. Якщо системи — це дві команди всередині одного відділу, рівень взаємодії — це керівник відділу та ліди команд. Якщо це два відділи, то це середовище управління з менеджерами обох відділів. Запит має піднятися вгору однією системою, зустрітися на рівні, який бачить обидві системи одночасно, і спуститися вниз іншою. Це не бюрократія. Це єдиний спосіб, який забезпечує і контекст, і повноваження сказати: так, це варто робити, варто перебивати іншу команду, і пріоритети з обох боків можуть це вмістити.

Тепер подивіться, що зробила «швидка допомога». Інженер з Відділу А написав інженеру з Відділу Б, і другий інженер відповів: «Зараз гляну, повернусь за годину». Допомога справжня. Роботу виконано. Але дві системи щойно встановили зв’язок від елемента до елемента, за спиною рівня, який мав би їх опосередкувати. Лід Відділу А не знає, що його відділ тепер фактично позичає потужність у Відділу Б. Ліду Відділу Б невідомо, що її інженер щойно взяв на себе роботу, якої немає в її плані. Дві системи тепер взаємодіють у спосіб, який ніхто вище них не бачить і не може врахувати.

Зроби так одного разу — нічого не станеться. Роби так щодня, як головний спосіб міжсистемної роботи, — і кожен план у компанії починає описувати роботу, якої насправді не відбувається, тоді як реальна робота йде в тіньовій мережі взаємних домовленостей. Керівники втрачають картину завантаження. Пріоритезація стає вигадкою. А коли інженер, який тихо всім допомагав, вигоряє або звільняється — ніхто не може пояснити, що раптом сповільнилося, бо це навантаження ніколи не було формалізовано.

Тепер подивіться ще раз на «бюрократичну» відповідь. «Опишіть, будь ласка, що вам потрібно у формальному запиті». Те, що ця людина насправді говорить — чи може вона це сформулювати, чи ні — це: цей запит має пройти через рівень, де наші дві системи зустрічаються. Лише там його можна чесно зважити проти всього, до чого моя система вже зобов’язана. Вона захищає системну комунікацію від імені всієї компанії, а не лише свою увагу. У термінах системної теорії — вона має рацію.

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

Отже, справжнє питання — те, про що цей сайт у цілому:

Чи є спосіб зберегти цей намір — прямий, швидкий міжсистемний потік цінності — і водночас поважати закон, що каже: окремі системи мають комунікувати через рівень, який їх містить?

Чи можна дозволити інженерам вирішувати питання без формальних запитів, щоб структури не втрачали суть того, що відбувається?

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

(Є друга, споріднена проблема — як інформація рухається вертикально, між старшим і молодшим з різних відділів компанії. У неї той самий корінь і та сама природа відповіді. Повернемось до неї у розділі 7 — там буде ясніше, як це виглядає структурно.)

Невидимі люди

Ще одне спостереження. У кожній крос-функціональній ініціативі, де я брав участь, є люди видимі — хто робить справи, швидко реагує, з’єднує інших. І є люди невидимі. Не відсутні. Не непродуктивні у своєму домені. Просто… не присутні в потоці цінності між командами.

Я думав, що це питання навичок та мотивації. Хтось — природний колаборант, хтось воліє тихо працювати.

Але потім зрозумів: невидимі люди невидимі не через те, хто вони є. Вони невидимі, бо структура не дає їм місця, де можна проявитись. Їх ніхто не запитав. Ніхто не з’єднав їхні навички з проблемою. Ніхто не показав, що саме їхня якість — може, глибоке знання домену, конкретний технічний скіл, чи навіть просто здатність перекладати між мовою інженерів і мовою бізнесу — була саме тим, що команді потрібно.

Проблема конекторів

Люди, завдяки яким крос-функціональна робота реально відбувається — хто з’єднує відділи, перекладає між командами, швидко реагує та будує мости — неймовірно цінні. І майже ніхто поза цими командами не знає, хто вони.

Вони не відображаються на оргструктурі. Їхній внесок не фіксується в жодному перформанс-рев’ю. Їхній менеджер може навіть не підозрювати, що вони це роблять. Вони тримають організацію разом через неформальні мережі, які ніхто не проектував і ніхто не вимірює.

Коли один з таких конекторів звільняється — всі відчувають. Але ніхто не може пояснити, що саме було втрачено. Бо це ніколи не було названо.

Скільки це коштує

Скажу чесно, я не маю ні цифри ні методології вимірювання структурного тертя. Ніхто не має — це частина проблеми. Але я бачу це в тривалості циклів. У подвоєній роботі. Коли дві команди будують схожі рішення, не знаючи одна про одну. Коли хороша ідея помирає, бо потрапила не в той відділ, і ніхто не переніс її далі.

Чим більша компанія, тим гірше. Більше відділів — більше кордонів. Більше кордонів — більше тертя. Більше тертя — менше цінності виходить на кожну одиницю ресурсу, що входить.

Це проблема, яку жоден окремий відділ не вирішить. Бо вона живе між відділами. Це не HR-проблема. Не IT-проблема. Не управлінська проблема. Це структурна проблема.

І вона має рішення. Не «зламати ієрархію і дозволити всім говорити з усіма» — це перша реакція у масштабі, і вона закінчується хаосом. І не «додати ще процесів» — це друга реакція у масштабі, і вона закінчується паралічем.

Деякі компанії вже відчувають цю проблему і шукають рішення. Вони створюють плоскі структури чи їх аналоги, але це все ж таки тактичні реакції без розуміння суті проблеми. Карго-культ. Коли вони копіюють чужі практики, не розуміючи, чому вони працюють.

Рішення — інший тип команди: такий, що сидить між рівнями за задумом, так, щоб швидка міжсистемна допомога перестала бути порушенням правил і стала їх проявом.

Ця команда має назву. Наступна сторінка — про те, де я її знайшов.