Nie wiemy, kto naprawdę odpowiada za dany obszar
Seria o designie organizacji (2/4). Wcześniej: struktura utrudnia rozwój. Następnie: reorganizacja bez zmiany modelu.
„Wszyscy są odpowiedzialni” znaczy: nikt nie jest
Brzmi jak kultura współpracy. W operacji często wychodzi inaczej: Product mówi, że decyzję musi podjąć biznes. Biznes czeka na IT. IT czeka na compliance. Compliance pyta o priorytet u zarządu. Tydzień mija, temat wraca na ten sam status.
Odpowiedzialności nachodzą na siebie, gdy:
- dwie role mają ten sam cel, ale inne KPI,
- „owner” produktu nie ma budżetu ani ludzi,
- manager liniowy nadal przydziela zadania w zespole „samorganizującym się”.
Decyzje się ciągną, bo nikt nie ma prawa domknąć bez ryzyka, że ktoś powie: „ale ja nie byłem w loopie”.
Test na jednym incydencie
Weź ostatni eskalowany temat (opóźniony release, reklamacja klienta, audit). Zapisz:
| Pytanie | Twoja odpowiedź |
|---|---|
| Kto mógł podjąć decyzję w pierwszych 48 h? | |
| Kto faktycznie ją podjął? | |
| Kto czuł się odpowiedzialny, ale nie miał mandatu? |
Jeśli trzecia kolumna ma więcej niż jedno imię, masz rozmycie mandatu, nie brak kompetencji.
Delegowanie, które da się omówić
Tabele RACI na Confluence rzadko zmieniają zachowanie. Zmienia rozmowa o poziomie decyzji.
Delegation Poker z Management 3.0 robi dokładnie to: siedem poziomów - od „powiedz mi, co zrobić” po „zrób i daj znać, jak poszło”. Zespół i lider ustalają, gdzie dziś jesteście, zamiast udawać, że wszyscy wiedzą.
Przykład, który często wychodzi na warsztatach:
- zespół myśli, że ma decyzyjność w zakresie technologii,
- lider myśli, że tylko rekomenduje,
- architekt centralny ma veto, o którym nikt nie pamięta.
Jedna sesja pokerowa nie rozwiązuje polityki firmy. Ustawia wspólny język, żeby przestać mówić „odpowiedzialny” w czterech znaczeniach naraz.
Product Owner, manager, platforma
W większych organizacjach klasyczne tarcie:
- PO odpowiada za wartość, ale nie za capacity platformy,
- Engineering manager odpowiada za ludzi, ale nie za backlog,
- Platform team odpowiada za stabilność, ale nie za deadline biznesu.
Bez jawnego „kto domyka konflikt X” każdy konflikt ląduje u dyrektora. Stąd wrażenie, że wszystkie decyzje idą do jednej osoby - nawet gdy na slajdach macie „empowerment”.
Sensowny pierwszy krok: wybierz jeden obszar produktu (np. onboarding) i opisz na jednej stronie:
- kto decyduje o priorytecie,
- kto decyduje o jakości / długu,
- kto decyduje o terminie, gdy te dwa się gryzą.
Reszta firmy może na razie zostać. Nauka na jednym żywym przykładzie jest szybsza niż kolejny projekt „target operating model”.
Powiązane praktyki
- Management 3.0 - po co w ogóle - system, nie checklista
- Praktyki, które wdrażamy na warsztatach
- Dysfunkcje zespołu - gdy brak odpowiedzialności niszczy zaufanie
Dalej
Nachodzące role to często skutek struktury, która mnoży uzgodnienia. A czasem efekt reorganizacji, która zmieniła schemat, ale nie zasady decyzji.
Następny tekst: Każda reorganizacja rozwiązuje jedno, psuje drugie