Hypotese:
Læringslab

Jobber du systematisk med kompleksitet?

CoWork tror kompleksitetsforståelse i både organisering, prosjektarbeid og på individnivå kan hjelpe virksomheter til å vokse.

 

Kompleksitetsmatrisen

 

Nøkkelen for framdrift er å ufarliggjøre at ansatte har ulikt nivå av kompleksitetsforståelse. Vi må se på denne egenskapen som en ferdighet, som vi ser på alle andre ferdigheter. Har du en venn som er veldig ivrig på å lære seg å svømme, så må du ikke bli overrasket eller fornærmet over at han svømmer raskere enn deg. Har du en kollega som har en utdannelse i design med lang erfaring, så må du ikke bli fornærmet over at han har en større tyngde enn deg i faget (selv om du har lest en veldig bra blogg om designmønstre).

Kompleksitet, som vil si evnen til å se mange trekk framover, er ikke det samme som fagkunnskap. Selv om du er god i strategi, så kan du mangle kompleksitetsforståelse om du ikke forstår brukerdesign eller teknologi. Tverrfaglig samarbeid og gjensidig respekt vil alltid kompensere for enkeltpersoners manglende faglige bredde.

Kompleksitetsmatrisen

Men for mange virksomheter så er ledelse et fagområde i seg selv, og man trenger ingen andre faglige kvalifikasjoner. Er du i tillegg en usikker leder, så vil kontroll på beslutningene være en essensiell del av ditt lederskap. For virksomheter med sterke faglige enheter og lite tverrfaglig samarbeid blir det opp til ledergrupper og prosjektledere at kunnskapen flyter i virksomheten. Slike ledere kan lett bli «entusiaster» i vår kompleksitetsmatrise, hvor viktig informasjon forsvinner da lederen ikke forstår nyansene i beslutninger.Entusiasten har mye energi, men liten forståelse for hvordan man kan lykkes.

 

Den vanligste tekniske ansatte jeg møter, er tilskueren. Tilskueren forstår kompleksitet bedre enn de fleste, men får ikke lov til å gjøre det som er nødvendig. Lei av å stange hodet i beslutningsforum og ledere som ikke ønsker å endre et system, kapitulerer tilskueren for å kunne bruke «det var det jeg sa»på et senere tidspunkt. Tilskueren vil ikke lykkes i å bygge karriere, og blir sett på som et uromoment som ofte kan sprekke i frustrasjon.

 

En tilskuer kan derimot se på kollegaer, som vi har kalt nisjeleverandør, med oppgavefokus og uten kompleksitetsforståelse gjøre karriere. Nisjeleverandøren er lojal, og gjør det han får beskjed om. Manglende kompleksitetsforståelse er forfriskende deilig, og han er derfor mindre frustrert enn sin tilskuerkollega. For ledergrupper er nisjeleverandøren et trygt valg som sin neste kollega i ledergruppen.

 

Da sitter vi igjen med kompleksitetsrydderen, som vi av og til er så heldig å jobbe sammen med. Dette er kollegaen som ikke er redd for å endre arbeidsprosesser eller samarbeidsformer for å bedre kundetilfredsheten. En kompleksitetsrydder er ikke opptatt av stillingstitler, og i sin jakt på gode ideer og bedre kundetilfredshet kan han snu selskaper på overraskende kort tid. Utfordret blir de som finner sin trygghet i oppgavefokus, og de som mangler kompleksitetsforståelse.

 

Hvor god kompleksitetsforståelse har du egentlig?

Øvelse: Plasser deg selv i kompleksitetsmatrisen i forhold til det du jobber med i dag

Kompleksitetens største utfordring er at vi aldri kan vite hvor god kompleksitetsforståelse vi har.  En kompleksitetsrydder kan lett forstå at kollegaer har lavere kompleksitetsforståelse enn seg selv, mens det motsatte er vanskeligere. Det er derfor sannsynlig at du selv vil plassere deg i den øvre delen av kompleksitetsforståelsen, mens andre kanskje vil plassere deg i den nedre. Det er viktig å vite at du aldri har noen ende i kompleksitetsskalaen. Uansett hvor dyktig du er, så kan du alltid finne uløste problemer som du ikke forstår i dag. Mens mange blir skremt av dette, så er dette en kompleksitetsrydders trøst. Det er alltid bruk for en kompleksitetsrydder, da det alltid er problemer man må løse og kompleksitet å forstå.  

Kompleksitetsøvelse for tverrfaglige team 

Tverrfaglige team er en utmerket måte å jobbe på om man ønsker å øke den felles kompleksitetsforståelsen. Det finnes en rekke verktøy som teamene kan benytte, slik som systemkart og lærende iterasjoner. Med å bruke systemkart kan dere diskutere sammenhenger som ikke er åpenbare, og med iterasjoner kan dere raskt teste ut hypoteser dere har. Beslutninger bør gjøres i fellesskap, og man bør være åpen og ærlig rundt sine tanker og ideer.

CoWork har hatt suksess ved oppstart av en ny satsning i å fokusere på suksesskriteriene og kompleksitetsforståelsen. Som en øvelse plasserte vi alle ansatte i kompleksitetsmatrisen. X-aksen som indikerer fokus på silo eller resultatfokus, må i startfasen av et prosjekt defineres «commitment» aksen. Er du en som «hjelper til om noen spør», eller er du en som vil «presse på uansett hvilke utfordringer som dukker opp»? 6 måneder etter vår øvelse så vet vi at vi overvurderte vår kompleksitetsforståelse, og er glad for vårt tidlige fokus på «commitment» som avgjørende for å finne riktig team. Dette har investorer skjønt, og har ofte et større fokus på lederteamet enn hvor god en ide er for investering på et tidlig tidspunkt.

I vår innledende øvelse så vi at teamet manglet teknologisk kompetanse. Vi brukte derfor tid på å løfte en av våre kollegaer sin kompleksitetsforståelse, før han ble en permanent del av teamet.

Skal du redusere kompleksitet? Da må kundefokus komme først  

Overraskende ofte hører jeg hjertesukk og frustrasjon da kundene ikke gjør hva vi forventet at de skulle gjøre. For slik er kundene, de misforstår, finner feil, og bruker ikke løsningen slik du hadde tenkt.

Dersom du skal utvikle en ny løsning, så vil din smidigcoach fortelle deg at du skal lage brukerhistorier. Disse historiene vil da bli sett på som sannhet av utviklingsteamet, og bli implementert i en ferdig løsning. Det er ingen forskjell på om brukerhistorien er basert på en produktsjefs tilfeldige tanke, eller om den kommer som følge av brukers tilbakemeldinger.

CoWork mener derfor at vi må skille om en brukerhistorie kommer fra brukererfaringer, eller om det er en hypotese fra en ansatt.

  • Brukerhypoteser: Vi har en ide om hva en bruker vil like. Alle prosjekter som er i en oppstartsfase må basere seg på brukerhypoteser (da man ikke har en løsning i markedet). Det er veldig viktig å undersøke om brukerhypotesen holder vann, eller om den må endres etter hver som vi får erfaringer.
  • Brukererfaringer: Når løsningen din går live, så vil det være mulig å få tilgang på brukererfaringer. Du vil kunne se på datakvaliteten, statistikk og søkeordslogger om brukeren oppfører seg som forventet, eller om løsningen gir brukeren utfordringer. Disse erfaringene er veldig verdifulle som grunnlag for videreutvikling.
Brukerhistorier må spesifiseres om de er hypoteser eller erfaringer

Det vil alltid være plass for brukerhypoteser i et prosjekt, men det er viktig at prosjekt teamet får kunnskap om hvor sikre vi er på at en brukerhistorie er riktig. Denne kunnskapen vil teamet bruke til å lage en robust og fleksibel arkitektur. Mens hypoteser bli testet ut på raskeste og enkleste måte, vil løsninger vi er helt sikre på kunne bli en del av den robuste og stabile plattformen.

Teknisk arkitektur må tilpasses hvor sikker vi er på behovet