Å jobbe tett med utviklere og teknologimiljøer i India over flere år har vært en av de mest lærerike erfaringene i min karriere. Ikke fordi det nødvendigvis var komplisert, men fordi det var annerledes. Når noe er annerledes, blir man også tvunget til å bli mer bevisst på hvordan man selv jobber og kommuniserer.
Samarbeidet strakte seg over mange år med jevnlige besøk til India og noen besøk tilbake også. Mellom reisene besto samarbeidet av videomøter, leveranser, justeringer, diskusjoner og perioder med høyt trykk, knyttet til utvikling av teknologiplattformer og løsninger vi jobbet med. Over tid begynner man å se mønstre, forstå dynamikken i samarbeidet og oppdage at internasjonalt samarbeid handler langt mindre om teknologi enn om kommunikasjon, forventninger og ledelse. Dette er noe av det jeg lærte.
Ja betyr ikke alltid ja
I starten kunne jeg oppleve at alt virket avklart. Jeg stilte et spørsmål, fikk et tydelig “yes”, og tok det som en bekreftelse på at både tidslinje og omfang var realistisk. Så gikk det noen uker, og leveransen viste seg å være noe annet enn det jeg trodde vi hadde blitt enige om.
Utfordringen var at oppgaven ble tolket på en annen måte enn hva jeg trodde jeg hadde formidlet. Et “ja” kunne bety at budskapet var mottatt, at man ønsket å vise vilje til å levere, eller at man ikke ønsket å skape friksjon i dialogen, men det betydde ikke alltid at alle forutsetningene var like tydelige for begge parter.
En annen del av friksjonen i starten av samarbeidet handlet også om hvordan kommunikasjonen var organisert. I begynnelsen gikk dialogen gjennom en prosjektleder mellom meg og utviklingsselskapet. Jeg trodde lenge at vedkommende jobbet hos selskapet som faktisk sto for utviklingen, slik han ga uttrykk for. Men etter hvert viste det seg at prosjektlederen tilhørte et eksternt konsulentselskap. Og vi vet jo at det noen ganger kan bli litt som hviskeleken når informasjon går gjennom flere ledd.
Da vi etter hvert begynte å jobbe mer direkte med ledelsen og produktansvarlige hos utviklingsselskapet, ble dialogen både raskere og tydeligere, og mange av misforståelsene forsvant nesten umiddelbart fordi vi snakket direkte med dem som både tok beslutningene og sto for utviklingsarbeidet.
Dette sitter igjen som en viktig lærdom om at det kanskje er viktigere å vite hvem du snakker med, enn hva du snakker om. Jeg lærte også å bli bedre til å sikre en felles forståelse, ikke bare ved å spørre om noe var mulig, men ved å be dem beskrive hvordan de selv oppfattet oppgaven og hva vi faktisk hadde blitt enige om. Noen ganger skriftlig, andre ganger ved å oppsummere i møtene.
Det høres kanskje banalt ut, men det gjorde en stor forskjell. Når begge parter formulerer forventningene høyt, blir det mye lettere å oppdage små forskjeller i forståelsen før de vokser til større problemer.
Lojalitet til oppgaven kan bli for bokstavelig
En av de tingene jeg satte stor pris på i samarbeidet, var respekten for rolle og ansvar. Når du gir en tydelig beskjed, blir den fulgt, punktlig og strukturert. Samtidig lærte jeg etter hvert at denne lojaliteten kan ha en bakside dersom jeg ikke er tydelig nok på konteksten rundt oppgaven.
Hvis du ber noen om å fjerne alle de røde mursteinene ved hjørnet av en bygning, så fjerner de alle de røde mursteinene. Ikke bare de som ligger løst utenfor, men også de som holder bygningen oppe. For det var tross alt det de fikk beskjed om.
Det handler ikke om manglende kompetanse. Tvert imot. Mange av utviklerne jeg har jobbet med i India har hatt solid teknisk forståelse og en sterk arbeidsmoral. Utfordringen ligger heller i hvordan oppdraget er formulert, og hvor mye rom man gir for egen vurdering.
Jeg måtte derfor lære meg å være tydeligere på hvordan jeg formulerte oppgaver. Over tid begynte jeg å være mer eksplisitt på noen enkle prinsipper:
- Forklar målet, ikke bare oppgaven
Når folk forstår hva vi prøver å oppnå, blir det lettere å ta gode beslutninger underveis.
- Be om den beste løsningen, ikke bare gjennomføring
Oppgaven jeg beskriver er ofte bare et utgangspunkt, ikke nødvendigvis den beste måten å løse problemet på.
- Inviter til bedre forslag
Be utviklerne si ifra hvis de ser en smartere eller mer robust løsning enn den du selv foreslår.
- Vær tydelig på at forslag er nettopp forslag
Det jeg ber om kan være basert på mitt eget perspektiv eller kompetansenivå, mens utviklerne ofte sitter på teknisk innsikt som kan gi en bedre løsning.
- Oppfordre til å stoppe opp ved risiko
Hvis noe virker feil eller kan skape problemer senere, er det viktigere å si ifra enn å følge instruksjonen slavisk.
- Gi rom for eierskap
Be folk ta beslutninger som om prosjektet var deres eget.
Da jeg begynte å si dette eksplisitt, endret dynamikken seg gradvis. Utviklerne begynte i større grad å stille spørsmål, varsle tidligere dersom noe kunne bli en utfordring, og ta mer eierskap til løsningene.
I ettertid har jeg også sett at dette ikke bare handler om kulturforskjeller mellom land. Det handler like mye om arbeidsmiljøer der lojaliteten til hierarki og rolle er sterk. I slike strukturer kan oppgaver lett bli utført akkurat slik de er formulert, selv når alle rundt bordet kanskje skjønner at noe burde stoppes eller diskuteres.
Resultatet er ofte det samme: Når folk får tydelig mandat til å si ifra, stille spørsmål og bruke sin egen vurdering, øker både eierskapet og kvaliteten på det som leveres.
Sterk vilje til å levere
Noe annet jeg la merke til, var den sterke viljen til å levere. Mange strekker seg langt for å vise at de kan levere på både tid og kvalitet. Det ligger stolthet i arbeidet, og et genuint ønske om å få ting til.
Men nettopp derfor kan utfordringer noen ganger bli forsøkt løst internt før de kommuniseres videre. Ikke fordi man ønsker å skjule noe, men fordi man først vil prøve å løse problemet selv.
Det er i utgangspunktet en god egenskap. Samtidig kan det skape utfordringer i prosjekter, fordi små problemer kan vokse seg større før de blir synlige for resten av teamet.
Som prosjektleder lærte jeg derfor hvor viktig det er å aktivt skape trygghet for å si ifra tidlig. Det må være helt greit å si at noe tar lengre tid enn planlagt, at en løsning viser seg å være mer komplisert enn først antatt, eller at prioriteringer bør justeres underveis.
Hvis ikke, kan man fort oppleve forsinkelser man i realiteten kunne ha unngått.
Presisjon i kommunikasjon er avgjørende
Samarbeid på tvers av kultur forsterker alle svakheter i kommunikasjon. Halve setninger, antydninger og underforståtte forventninger holder sjelden mål.
Det som ofte kan tolkes mellom linjene i Norge, må i internasjonale prosjekter sies tydelig. Erfaringen lærte meg derfor å bli mer konkret i formuleringene, mer strukturert i kravspesifikasjoner og mer eksplisitt i prioriteringene.
Samtidig ble det viktig å lytte mer aktivt og å sjekke underveis at vi faktisk hadde samme forståelse av det vi diskuterte.
Teknologien var sjelden den største utfordringen. Den virkelige utfordringen lå nesten alltid i forventningsstyringen.
Vær deg selv, men gi rom for selvstendighet
Når man jobber med andre kulturer over tid, kan det være fristende å forsøke å tilpasse seg fullt og helt, lære alle kodene, endre stil og bli mest mulig lik dem man samarbeider med. Min erfaring er likevel at det fort kan bli kunstig.
Det viktigste er å være seg selv, tydelig og ærlig i kommunikasjonen, samtidig som man er trygg på egen rolle og bevisst på at egne arbeidsvaner og måter å kommunisere på ikke nødvendigvis er universelle sannheter.
En av de viktigste lærdommene for min del var at det jeg først tolket som kulturforskjeller, ofte viste seg å handle mer om forskjeller i ledelse og forventninger enn om kultur i seg selv.
Når jeg var tydelig på mål, åpen for innspill og eksplisitt inviterte til selvstendige vurderinger, fungerte samarbeidet svært godt. Når jeg derimot var vag i formuleringene eller for detaljstyrende i oppgavene, oppsto misforståelser langt lettere.
Respekt, ydmykhet og tydelighet fungerer på tvers av landegrenser. Det gjelder i India, det gjelder i Kina, og det gjelder like mye i hverdagslige samarbeid her hjemme.
Man trenger ikke å bli som den andre, men man må skape rom for at den andre kan være sitt beste jeg innenfor tydelige rammer. Da unngår man at noen fjerner de røde mursteinene som holder bygningen oppe, og man bygger ikke bare programvare, men samarbeid som faktisk tåler belastningen over tid.
