Jak zburzyć silos IT?

Aby przełamać bariery informacyjne i popchnąć transformację do przodu, liderzy biznesowi muszą zaangażować się w bezpośrednie kontakty z przedstawicielami działów technicznych i nauczyć się zadawać właściwe pytania.

Dyrektor generalny firmy usługowej na rynku nieruchomości zgłosił się do nas ostatnio z problemem. Cała firma czekała z niecierpliwością na nowy system, nad którym zespół technologiczny pracował przez ponad rok. Dyrektor generalny ubolewał nad tym, że teraz trzeba całkowicie przebudować to rozwiązanie przy wykorzystaniu innej technologii – co opóźni projekt co najmniej o kolejne pół roku i sprawi, że firma pozostanie jeszcze dalej w tyle za konkurencją.

Mogłem przewidzieć odpowiedź na moje następne pytanie, ale i tak je zadałem dyrektorowi: A jak zespół informatyczny uargumentował potrzebę przebudowy systemu? Dlaczego to było potrzebne akurat teraz i jakie były rozwiązania alternatywne?

„Nie mam pojęcia – brzmiała odpowiedź. – Jak miałbym ich o to zapytać? Jestem liderem biznesu, a nie programistą!”

Firma miała kłopoty, a dyrektor wpadł w powszechną pułapkę. W istocie taka rozmowa ma miejsce tak często w naszej konsultingowej praktyce, że nawet nadaliśmy nazwę leżącemu u jej podłoża wzorcowi: „otoczony murem ogród technologii”.

Trzymanie przedstawicieli działów technicznych w takim wygodnym silosie ochronnym może siać spustoszenie w strategicznych priorytetach i wyzwolić kaskadę różnych skutków w wielu częściach organizacji:

Inżynierowie oprogramowania uwijają się jak mrówki w samym ogrodzie – dopieszczają i udoskonalają swoje oprogramowanie, eliminują błędy i refaktorują kod.

Liderzy technologii uwijają się, broniąc ogrodu – czyli chroniąc inżynierów i informatyków przed interwencją z zewnątrz i określając najlepsze praktyki.

Członkowie personelu kontaktujący się z klientami przeżywają koszmar poza murami ogrodu, musząc stawiać czoła wściekłym użytkownikom domagającym się korekt i funkcji, które wydają się nigdy nie pojawiać, a nowe inicjatywy sprzedażowe tkwią w martwym punkcie z powodu braku wsparcia produktów.

Liderzy biznesu, jak nasz dyrektor generalny, mogą uważać się za outsiderów w rozmowach o technologii, rozmowach, których terminologia i podejście do tematu wykraczają poza zakres ich wiedzy eksperckiej, a tym samym są mniej skłonni do interwencji. To często wymusza rodzaj ślepego zaufania do swoich liderów i zespołów zajmujących się technologią.

Zauważyliśmy dwie wyróżniające się cechy tego antywzorca. Po pierwsze, z taką samą częstotliwością pojawia się w organizacjach zacofanych jak i w najnowocześniejszych. Niezależnie od tego, czy firma korzysta z metodyki Agile lub DevOps, przyjęła najnowsze narzędzia techniczne i języki programowania, wytworzyła kadrę wysoko wykwalifikowanych liderów zarówno wewnątrz grupy zajmującej się technologią, jak i poza nią, żaden z tych plusów nie uchronił naszych klientów przed hermetycznością działu informatycznego.

Drugą cechą wyróżniającą otoczony murem ogród jest jego niezwykła dźwiękoszczelność: inżynierowie znajdujący się wewnątrz organizacji technologicznej są często nieświadomi narastających wokół nich lawinowo problemów spowodowanych opóźnieniami we wdrażaniu technologii oraz brakiem komunikacji. Po drugiej stronie muru nietechniczny interesariusze, tacy jak pracownicy działów rozwoju biznesowego, marketingu i obsługi klientów, mogą czuć presję na rozwiązanie problemów, ale czują się zbyt onieśmieleni, aby się sprzeciwić lub działać, ponieważ brakuje im technicznej wiedzy eksperckiej, która pozwoliłaby im stawać na równi z inżynierami. Z tego powodu mury pozostają niewzruszone, a wydajność i morale lecą w dół.

W wielu przypadkach końcowy wynik nie jest dobry dla firm: projekt jest klapą, techniczni liderzy przechodzą na inne stanowiska, a czasem wszystkie zadania informatyczne zostają zlecone na zewnątrz. Aby uniknąć takich scenariuszy, ważnym jest zrozumienie, jak organizacje w aż takim stopniu uzależniły się od nieprzeniknionej grupy wyposażonej w specjalistyczną wiedzę przy minimum powiązań komunikacyjnych. Musimy wiedzieć, jak rozbijać mury wewnątrz organizacji, i bardziej zbliżyć do siebie zespoły technologiczne i liderów biznesowych. Aby rozwiązać obie te kwestie, firmy i menedżerowie muszą lepiej zrozumieć, jakie krytyczne pytania trzeba zadać oraz to, jakie rozmowy muszą się odbyć.

Musimy wiedzieć, jak rozbijać mury wewnątrz organizacji, i bardziej zbliżyć do siebie zespoły technologiczne i liderów biznesowych

Zrozumieć, jak powstają mury

W poprzedniej dekadzie rosnące znaczenie technologii w biznesie doprowadziło do gwałtownego wzrostu zjawiska transformacji biznesowej – i niezależnie od tego, czy wybierze się wariant metodyki cyfrowej, DevOps, Lean czy też Agile, celem jest przyspieszenie i tworzenie innowacji. Czemu więc mamy do czynienia z tak wieloma murami i tak mizerną komunikacją?

Kiedy pracujemy z klientami podczas działań transformacyjnych, często widzimy dobrą zgodność ze standardowymi procesami metodyki Agile, z takimi rytuałami jak pielęgnowanie rejestru produktu (backlog grooming) czy codzienne poranne spotkania całego zespołu (stand‑up meetings). Ale kiedy rozmawiamy zarówno z liderami technicznymi, jak i nietechnicznymi, słyszymy uderzająco podobne bezproduktywne komunikaty. Nie świadczą one o dobrej współpracy, choć w teorii te rytuały mają ją umacniać:

„Nie rozumiem powodów, dla których inżynierowie robią to, co robią, i prawdę mówiąc, jest mi to obojętne”.

„Wiem wszystko najlepiej; musimy ich tylko przekonać, żeby tak właśnie postąpili”.

„Nie muszą wiedzieć, dlaczego to właśnie jest nam potrzebne; muszą tylko zrobić, co im każemy”.

Znakomity specjalista w dziedzinie nauk społecznych Chris Argyris określił mentalność stojącą za takimi deklaracjami jako Model I teorii działania, który charakteryzuje się dążeniem do zachowania twarzy, pokazania się jako osoba rozsądna i wygrania sporuIndeks górny 1¹. Ten rodzaj myślenia wyłącza ciekawość i transparentność, uniemożliwiając pojawienie się nowych pomysłów. Argyris przeciwstawił tę teorię Modelowi II, w którym nacisk kładzie się na uczenie, gromadzenie jak największej ilości informacji oraz opcji od każdego w pokoju spotkań oraz podjęcie możliwie najlepszej decyzji, a nie na wygraną za wszelką cenę. To ten rodzaj myślenia wyraźnie sprzyja produktywnej współpracy. Z pracy, w ramach której Argyris przebadał ponad 10 000 ludzi na całym świecie, wynika, że wszyscy konsekwentnie twierdzą, że zgadzają się i opowiadają za Modelem II – ale ich faktyczne zachowania w ogromnej większości uosabiają Model I, szczególnie w sytuacji, gdy głęboko zależało im na tym, jaka decyzja zostanie podjętaIndeks górny 2².

Często organizacjom szkodzi pełna napięć komunikacja, a ich otoczone murem ogrody biorą się stąd, że liderzy technologii – często albo świeżo zatrudnieni, albo ze świeżo nabytymi uprawnieniami w firmie – działają w dobrej wierze, aby stworzyć lepszy proces dla opracowywania oprogramowania. Starają się stworzyć środowisko, w którym unika się nierozwiązanych konfliktów po to, aby można było stworzyć oprogramowanie. Widoczny tutaj problem jest symptom poważniejszych problemów w obszarze kultury organizacyjnej, których nie rozwiązano podczas rzekomej transformacji. Naszym zdaniem, jest to jeden z najważniejszych czynników prowadzących do porażki transformacji: zwykłe małpowanie zachowań zespołów odnoszących sukcesy nie tworzy magicznie kultury i mentalności potrzebnej do przezwyciężenia myślenia w duchu Modelu I.

Zazwyczaj wszystkie strony mają dobre intencje i ciężko pracują, by je zrealizować – inżynierowie, którzy mają na celu stworzenie oprogramowania wysokiej jakości, które dobrze działa, oraz nietechniczni członkowie zespołu, którzy podporządkowują się technicznym ekspertom i mają nadzieję, że ostatecznie wszystko będzie dobrze. Ale pomimo ich wszelkich starań konsekwencje są zbyt często katastrofalne. Nic dziwnego, że Argyris nazwał to zjawisko, które można opisać jako bezproblemowe osiąganie skutków przeciwnych od zamierzonych, „wprawnym niedołęstwem”Indeks górny 3³. Jak możemy uniknąć tej pułapki? Jak możemy utrzymać zaangażowanie działu informatycznego i sprawić, by nie pozostał zamknięty za murem Modelu I?

Rozmowy burzą mury

Co potwierdza wiele przykładów, metody analizy konwersacyjnej Argyrisa z powodzeniem pomagają firmom wyrwać się z ogrodzonego murem ogroduIndeks górny 4⁴. Te techniki traktują rozmowy jako jednostkowe moduły procesu uczenia się i ulepszania komunikacji, czynią z rozmów przedmiot analiz dokonywanych przez wszystkich członków organizacji (zarówno personel techniczny, jak i nietechniczny). Wdrażając zasadę czterech R – recording, reflecting, revising, role‑playing (rejestracja, refleksja, rewizja, odgrywanie ról) – w swoich rozmowach, uczestnicy uczą się przyjmować podejście oparte na transparentności i zaciekawieniu w duchu Modelu II i zaczynają budować zaufanie i kulturę twórcząIndeks górny 5⁵.

Jako przykład przeanalizujemy rozmowę między Elijahem, członkiem starszej kadry kierowniczej, oraz Umarem, liderem technicznym. W tym przypadku Elijah zarejestrował w pamięci, co myślał i czuł podczas rozmowy i co każdy uczestnik powiedział.

Elijah: „Musimy rozpocząć instalację nowych urządzeń w laboratorium pilotażowym do dwudziestego”.

Co Elijah myślał: Jestem tak sfrustrowany. Musimy pokazać klientom jakieś namacalne postępy, bo nas porzucą i co się wtedy z nami stanie?

Umar: „Nie ma mowy. Projekty wysokiego i niskiego poziomu wciąż nie pasują do siebie. Potrzebujemy co najmniej miesiąca planowania, zanim będziemy mogli choćby zacząć działać z ich interfejsami programowania aplikacji”.

Co Elijah myślał: Dlaczego nie widzisz, jak krytyczne ma to znaczenie? Zapomnij o projektach – jak stracimy tę umowę, możemy zacząć pracować nad projektem planu zwolnień.

Elijah dokonał refleksji nad tą rozmową, wpisując znaki zapytania (wskaźniki zaciekawienia) oraz nieujawnione myśli i odczucia (wskaźniki braku transparencji). Dalej zrewidował rozmowę tak, aby zbliżyć się do bardziej otwartego, twórczego procesu, a następnie przeprowadził próbę zmienionej rozmowy w formie odgrywania ról z coachem, zanim ponownie porozmawiał z Umarem, który równolegle pracował nad poprawą komunikacji poprzez podobne analizy. W rezultacie Elijah odkrył, że może podzielić się swoim niepokojem i zadać autentyczne pytania Umarowi na temat nieprzekraczalnych terminów i opcji; podobnie Umar i jego zespół nauczyli się reagować nie za pomocą lekceważącej dla laików technomowy, lecz w sposób wyrażający głęboką empatię dla interesariuszy i ich obaw.

Powyższa konwersacja jest inspirowana autentyczną rozmową, szczegółowo opowiedzianą nam przez dyrektora generalnego oraz przez wiceprezesa ds. inżynierii z firmy medycznej, z którą współpracowaliśmy. Silos IT w tej firmie zazwyczaj potrzebował co najmniej pół roku na dokonanie najdrobniejszych zmian. Po poprawieniu jakości swoich rozmów i zbudowaniu zaufania ci dwaj liderzy odkryli, że główną barierę dla osiągnięcia szybkich wyników stanowił lęk przed spowodowaniem zagrożenia dla zdrowia lub życia pacjenta, który prowadził do nadmiernej ostrożności i komplikacji rozwiązań. Gdy poprawili swoją komunikację dla zbudowania spójności i nakreślili swoje obawy, znaleźli też czas na zweryfikowanie słuszności tych obaw. Dowiedzieli się dzięki temu, że elastyczność w zakresie wymogów jest znacznie większa, niż ktokolwiek mógł oczekiwać; okazało się, że znacznie mniej skomplikowane metody kontroli jakości są do zaakceptowania, a ich wdrożenie nie oznacza mniejszego bezpieczeństwa, pod warunkiem że są dobrze udokumentowane i kontrolowane. Firma odkryła, że może dokonywać zmian oprogramowania co dwa tygodnie po przyjęciu nowych technik.

Te przykłady ilustrują, w jaki sposób przeprowadzanie trudnych rozmów budujących zaufanie i zmniejszających obawy może pomóc organizacjom w burzeniu silosów. Ponadto odkryliśmy, że analizowanie i ulepszanie jakości rozmów pomaga w trzech kluczowych obszarach: określaniu jasnego celu, uczeniu się skutecznego zaangażowania oraz tworzeniu dwukierunkowej odpowiedzialnościIndeks górny 6⁶. Firmy, których personel opanował sztukę prowadzenia trudnych rozmów oraz techniki ich ciągłego doskonalenia, odkrywają nie tylko to, że współpraca z działem informatycznym staje się prostsza i bardziej zadowalająca, ale także to, że zwiększają przychody i udział w rynku, gdy wszystkie strony odkrywają uprzednio ukryte opcje i rozwiązania. Otoczony murem ogród jest piękny, ale destrukcyjny; zburzenie muru uruchamia prawdziwą transformację kulturową.

PRZYPISY:

1. C. Argyris, R. Putnam, and D.M. Smith, “Action Science: Concepts, Methods, and Skills for Research and Intervention” (San Francisco: Jossey‑Bass, 1985), ss. 90‑99.

2. C. Argyris, “Organizational Traps: Leadership, Culture, Organizational Design” (Oxford, United Kingdom: Oxford University Press, 2010), s. 17.

3. C. Argyris, “Skilled Incompetence,” Harvard Business Review 64, numer 5 (wrzesień‑październik 1986): ss. 74‑79.

4. C. Argyris and D.A. Schon, “Theory in Practice: Increasing Professional Effectiveness” (San Francisco: Jossey‑Bass, 1974), s. 41.

5. D. Squirrel and J. Fredrick, “Agile Conversations” (Portland, Oregon: IT Revolution Press, 2020), oraz R. Westrum, “A Typology of Organisational Cultures,” Quality & Safety in Health Care 13, Dodatek 2 (grudzień 2004): ss. ii22‑ii27.

6. D. Squirrel and J. Fredrick, “Agile Conversations,” ss. 83, 87.