Autonomt team betyr ikke frihet fra avhengigheter
– men det betyr frihet til å håndtere avhengighetene.
Etterhvert som mange bedrifter får flere digitaliseringsteam som jobber ved siden av hverandre så blir det viktig å forstå hva slags frihet (autonomi) hvert team skal ha. Det vil si, hva de skal være autonome på. Jeg har hørt flere som har ment at teamet da bør ha frihet til å ta egne valg på teknologi, hvordan de bygger løsningene og hva de skal lage. At teamet skal ha autonomi på hva de skal lage er jeg en forkjemper for, men det er innenfor rammene av tydelige krav på hva teamet skal oppnå (effekt).
Men i dag har jeg altså lyst til å skrive om avhengigheter. Det meste av digitalisering skjer nå i et nettverk av forskjellige digitale løsninger, både interne og eksterne, og gjerne også der flere team bidrar til samme produkt. Avhengigheter krever koordinering, og hvordan koordinering skal skje er et organisasjonsdesignspørsmål.
Koordinering kan skje på flere vis, i følge Taylor (Scientific Management) så skal ledelsen håndtere all koordinering, mens vi finner en mer fornuftig tilnærming hos Mintzberg som beskriver 6 koordineringsmekanismer der ansatte håndterer en del av koordineringen:
- direkte ledelse (direct supervision)
- gjensidig tilpasning (mutual adjustment)
- standardisering av arbeidet (work)
- standardisering av output (output)
- standardisering av ferdigheter (skills)
- standardisering av normer/misjon/mål (norms)
Direkte ledelse er typiske mester-svenn-situasjoner der den ene forteller den andre hva som skal gjøres og hvordan. For eksempel en erfaren møbelsnekker som trener opp en ny møbelsnekker. Gjensidig tilpasning er det som skjer i team — vi finner ut sammen hva som må gjøres og hvordan. Begge disse koordineringsmekanismene fungerer når det er mye variasjon som skal håndteres.
De fire formene for standardisering fungerer for forskjellige grader av variasjon. Standardisering av arbeidet fungerer når det samme arbeidet skal gjøres likt mange ganger for å få samme resultat, det vil si når det er lite variasjon i arbeidet. For digitaliseringsteam er det ofte å legge ting i produksjon. Standardisering av output kan være at man definerer grensesnitt (f.eks. API) som gjør det enklere å håndtere avhengigheter mellom team. Standardisering av ferdigheter handler om å sikre at folk har de ferdigheter som trengs gjennom krav til utdanning og eventuelt videreutdanning. Denne standardiseringen fungerer når det er mye variasjon, for eksempel ved å stille krav til spesialisering for leger. Denne standardiseringen kaltes tidligere standardisering av input, og jeg tror det er nyttig som begrep for oss som jobber med digitalisering. Fordi en av stedene der det kan bli ufred i dag er på valg av teknologier å bruke, dvs. hva slags input har teamet for sitt arbeid. For eksempel kan det være at to team har litt forskjellige behov og dermed mener at to forskjellige rammeverk er best for deres behov. Det å bruke forskjellig teknologi for samme oppgave i samme bedrift gjør at det er vanskeligere å veksle mellom de forskjellige teamene. Derfor er det en fordel å standardisere. Standardisering av normer handler om å beskrive hva vi skal oppnå for alle teamene, og det er et eget stort tema som jeg vil ta opp en annen gang :-)
Grunnen til at vi organiserer digitaliseringsarbeid i team er fordi det er så mye variasjon at teamet må håndtere det selv — de må koordinere seg med gjensidig tilpasning. I tillegg må teamet koordinere seg med de andre teamene der det er nødvendig. Faktisk så er det slik at effektive team er de som er gode til å koordinere seg med andre (Šmite et al., 2023).
Likevel finnes det eksempler på at man setter opp roller som skal koordinere over teamene, for eksempel prosjektledere, eller arkitekter, eller… Og da kan man få slike situasjoner som beskrives her:
“The overall direction is set by the community… But it is very challenging, e.g., if they [headquarters] have an architect who has the power to decide, and he comes here and commands us to do something, and then he is told that he cannot decide… that you don’t have the power, you can say whatever you want, but the community will decide and make the implementation anyway. So, we have kind of the reputation of a pirate ship in the sense that we have bravely made decisions outside the main-stream that in retrospect have turned out to be very good.” (Moe et al., 2021)
Ved å sette opp en koordineringsrolle over teamene i tillegg til den koordineringen som skjer på tvers av teamene har altså denne organisasjonen lagt til rette for koordineringskonflikter. Noen vil da kanskje konkludere med at det er best at koordinering skjer bare et hakk over teamene slik at noen kan ha kontroll. Utfordringen med det er at det er mye koordinering som bør skje, og dermed blir det fort mange tråder å holde rede på samt at mye kunnskap forsvinner i overleveringen fra det ene teamet til koordineringspersonen til det andre teamet og tilbake. Derfor er min anbefaling:
Å være et autonomt team betyr ikke frihet fra avhengigheter, men frihet til å håndtere avhengighetene!
Referanser:
Mintzberg, H. (2023). Understanding Organizations… Finally!: Structuring in Sevens. Berrett-Koehler Publishers.
Moe, N. B., Šmite, D., Paasivaara, M., & Lassenius, C. (2021). Finding the sweet spot for organizational control and team autonomy in large-scale agile software development. Empirical Software Engineering, 26: 101(5), 1–41. https://doi.org/10.1007/s10664-021-09967-3
Šmite, D., Moe, N. B., Floryan, M., Gonzalez-Huerta, J., Dorner, M., & Sablis, A. (2023). Decentralized decision-making and scaled autonomy at Spotify. Journal of Systems and Software, 200, 111649. https://doi.org/https://doi.org/10.1016/j.jss.2023.111649
