KOMMENTAR: Outsourcing

Nearshoring av utviklere til lavkostland – hvorfor feiler så mange?

Utviklingssjef Jan Strandbakke i Tripletex har åtte råd.

Jan Strandbakke, utviklingssjef i Tripletex.
Jan Strandbakke, utviklingssjef i Tripletex. (Foto: Oda Hveem / Tripletex)

Utviklingssjef Jan Strandbakke i Tripletex har åtte råd.

  • Debatt

Nearshoring av utviklere til lavkostland snakkes ofte om i negative ordelag. Men med det ekstremt skjeve tilbud/etterspørsel-forholdet etter utviklere i Norge, og spesielt i Oslo, er det mange som har vært nødt til å teste denne muligheten. Mitt inntrykk er at aller fleste feiler og ender opp med utviklere som er billigere enn de norske, men som er tilsvarende mindre effektive. Dessuten er det mange ledere som opplever at dette bidrar negativt i hverdagen.

Jeg har mange års erfaring med outshoringsteam i Ukraina og India fra tidligere arbeidsplasser. I Tripletex har vi jobbet med utviklere fra Romania i to år, og jeg mener at vi har funnet en oppskrift som fungerer utrolig godt.

Her oppsummerer jeg åtte tips som jeg mener er de viktigste ingredienser for å få dette til å fungere optimalt.

1. Behandle alle som egne ansatte: Det er jo litt tabu å si, men mange behandler utviklere i lavkostland som kode-roboter. Rett og slett. Og dette fungerer åpenbart ikke! Man må, slik jeg ser det, behandle alle i teamet som egne ansatte. Kode-roboter har ikke godt eierskap til eget domene eller egen kode. De vil produsere lavkvalitetskode, ferdig snakka.

2. Se hverandre fysisk hver 8. uke bare for å jobbe sammen: Etter mange team og mange års erfaring med outshoringsteam i Romania, Ukraina og India har jeg en veldig klar anbefaling å komme med når det gjelder hvor ofte man møtes. Jeg mener at noen (ikke alle) fra nearshoringslandet og noen fra Norge må møtes hver 8. uke. Dette kan høres mye og dyrt ut, men det må til, mener jeg. Man trenger ikke (og bør helst ikke) møtes for en workshop eller et arrangement som krever mye planlegging. Man møtes rett og slett for å jobbe sammen som kollegaer.

3. Bruk video – ikke snakk bare jobb: Flere jeg har møtt har tenkt at en spesifikasjon eller en mail er mer en nok for å få en utvikler til å lage noe. Dette kunne ikke vært mer feil. Man må snakke sammen om oppgaven! Og har man team som sitter et annet sted – ja, da gjør man det over video. I dag har alle store leverandører som Google, Skype og Slack video-systemer som fungerer veldig bra for team. Og et lite ekstra tips her: Minn folk på at video skal være på i videomøter. Jeg har vært i mange møter der noen av deltakerne slår av både mikrofon og kamera og sitter passivt og lytter. Dette fungerer circa like bra som å bare sende epost – altså, ikke i det hele tatt.

4. Brand the employees: I dagens arbeidsmarked med mange om beinet om flinke utviklere er employer branding meget viktig – også mot eksisterende ansatte. Man må jobbe og legge ned innsats for å beholde de beste. Dette er opplagt å tenke på i Norge, men jeg opplever at en del glemmer dette hos de som ikke sitter i Oslo eller Norge. Mitt råd er – prøv å behandle alle likt. Gir du ut klær eller andre effekter lokalt, er det viktig å gjøre dette hos de du har i ditt team i utlandet også. Enkle ting som t-skjorter, klistremerker og give-aways virker faktisk, og er med på å bygge stolthet rundt egen merkevare.

5. Ha team med medlemmer fra hver lokasjon. Ikke ha 100 % nearshore teams: Jeg har vært med å prøvd litt forskjellig opp gjennom, og den helt klart mest effektive formen for samarbeid er når du har et team som er cross-lokasjon. Det kan være fristende å tenke at vi skal ha et autonomt team i ditt nearshore/offshore-team, men min erfaring er dette teamet raskt lever et liv litt på siden av teamene i Norge og at de driver litt bort fra våre prinsipper om software-utvikling og ledelse.

6. Vis tillit: Vis tillit til alle. Det er veldig lett å si, men det er vanskeligere å stå i dette når noen akkurat har produksjonssatt en kjip bug fordi vi kjørte koden litt for fort ut i prod. Sier du tillit, må du også levere tillit i slike situasjoner. Har Tripletex en bug i prod er det ingen som blir «halshugget». Da er vi mest opptatt av å finne ut hvordan vi kjappest mulig kan fikse denne feilen. Tillit bygges over lang tid, men med én «halshugging» er all tillit borte.

7. Teambuilding for alle: Man må tenke relasjoner i et team, og relasjoner er nesten viktigere til de som sitter remote enn dem du ser hver dag i Oslo. Her må det investeres noe for å få god kommunikasjon og ærlige tilbakemeldinger. Det er viktig at de som sitter remote føler seg som en del av ditt firma og team. Be dem med med på ting dere gjør. Det er helt naturlig at de er med på julebord, turer, teambuilding etc. Og før noen spør; JA, det betyr at dere må ta julebordet på engelsk og at det kanskje blir litt stivere enn vanlig, men det er faktisk prisen å betale for å ha ansatte i andre land. Hvis de ikke blir invitert på dette føler de seg raskt som annenrangs deltakere i deres team.

8. Nordic management culture: Hva er Nordic Management Culture? Det må du reflektere grundig over og prøve å ta det beste fra denne kulturen og få dine utenlandske ansatte til å agere og forstå hva vi forsøker å få til med vår flate struktur. Dine utviklere i lavkostland må skjønne at de kan ta beslutning, påvirke og faktisk fikse den buggen de ser uten å involvere deg, selv om dette ikke nødvendigvis er vanlig kutyme i deres kultur der hierarkiet sannsynligvis lever i beste velgående. Skjønner de det, går både deres og din hverdag mye enklere.

Følger du rådene over og faktisk gir tillit til dine medarbeidere på forskjellig lokasjoner vil du ha mye større verdi av dine ressurser. Tillit (på ordentlig) er nok den vanskeligste her, men det viktigste er at vi tør å ta nok risiko. Ikke vær naiv, men gi stor tillit – da blomstrer utviklere!

Lykke til!

Kommentarer (4)

Kommentarer (4)
Til toppen