Datateam: Dere vet ikke hva dere bygger

Mange datateam fanges ikke av dårlige valg, men av valg ingen sa høyt. Med Kahnemans System 1 og System 2 som linse ser vi hvorfor stilltiende antagelser er det som dreper datakvalitet.

Sett gjennom brillene til Daniel Kahneman

Det starter ofte uskyldig: en rask dataleveranse for å løse et konkret behov. Det leveres fort, fungerer godt – og blir plutselig brukt som om det var bygget for gjenbruk, langsiktighet og felles sannhet. Det er i dette gapet – mellom intensjon og forventning – mange datateam havner i trøbbel.

Datateam kan bli fanget mellom to hensyn: rask leveranse og god kvalitet. I praksis er det en forenkling. Den egentlige spenningen handler sjelden om hva man velger å gjøre – men om man er tydelig på hvilket valg man faktisk tar, og hvilke forventninger som følger med.

Daniel Kahnemans skille mellom System 1 og System 2 gir et nyttig språk for dette. System 1 er rask, intuitiv tenkning – autopiloten som løser ting uten å bruke for mye energi. System 2 er langsommere, mer analytisk og ressurskrevende. Kahneman bruker dette skillet til å forklare hvordan mennesker tar beslutninger, men det treffer overraskende godt når man ser på hvordan datateam jobber. Begge systemene er nødvendige. Problemet oppstår når vi forveksler dem – eller later som om vi kan kjøre System 1-tempo og likevel få System 2-resultater.

Caset: vi skulle bygge ned et gammelt datavarehus

I ett av oppdragene vi kjenner godt, var utgangspunktet fornuftig: etablere et team for å bygge ned et eldre datavarehus, steg for steg, og erstatte det med nye dataprodukter bygget på en moderne plattform.

Det høres ryddig ut. Og i teorien var det det.

Men ganske raskt ble det tydelig at vi sto i et System 2-ambisjonsprosjekt uten System 2-forutsetninger. Brukerne var ikke modne nok til å ta stilling til hva de faktisk trengte av nye dataprodukter – de var vant til å konsumere, ikke å eie. Dataplattformen var ikke rigget for et data engineering-team som jobbet i fullt tempo. Et data governance-rammeverk fantes knapt, og det som fantes var for komplisert til å faktisk brukes i hverdagen. Kildedata var heller ikke tilstrekkelig kartlagt eller klargjort.

Likevel var forventningen å «bli raskt ferdig». Ambisjonen var å jobbe System 1-raskt, og levere System 2-resultater. Det er en kombinasjon som sjelden går særlig bra.

Det som skjedde, var ikke at teamet sviktet. Det som skjedde, var at ingen hadde satt ord på gapet mellom hva de ønsket å oppnå og hvilke forutsetninger som faktisk var på plass. Og i fraværet av den samtalen, fylte alle inn sine egne antagelser.

System 1 er ikke problemet

Det er viktig å understreke: System 1-løsninger er helt legitime. Ikke alle dataleveranser trenger å være brede nok for hele virksomheten, fullt dokumenterte og designet for evig gjenbruk. I mange tilfeller er det riktig å levere raskt, teste om noe faktisk skaper verdi, og heller investere i langsiktighet dersom det viser seg at løsningen lever videre.

Problemet oppstår ikke fordi man velger en rask løsning. Det oppstår fordi valget tas uten å si det høyt – og fordi ingen sier høyt hva det betyr å ta det valget.

En analytiker som trenger et tall til et møte på fredag, trenger ikke en pipeline bygget for å vare i ti år, med full historisering og seks lag med tester. Men hun trenger å vite at det hun ser på er «godt nok for nå» – ikke «fasiten for alltid». Hvis ikke hun vet det, og lederen hennes ikke vet det, og dataprodukt-eieren ikke vet det, er grunnlaget lagt for et problem som plutselig er mye vanskeligere å løse enn selve tallene.

System 1 kan faktisk være tegn på modenhet

I modne datateam er veldig mye System 1 – og det er bra.

Når et team har jobbet lenge nok med de samme mønstrene, blir de automatiserte. Det betyr ikke at de er lite gjennomtenkte. Det betyr at de er gjennomtenkt én gang, satt i system, og nå bare fungerer. Standardisert innfasing for nye datakilder. Konvensjoner for modellering og lagdeling som ingen trenger å diskutere fra bunnen av. En fast standard for datakvalitetstester som sitter i pipelines uten at noen ber om det. En operasjonell rytme der alle vet hvem som eier hva, og hva som skjer når noe feiler klokken tre om natten.

Det er den typen System 1 man vil ha. Og veien dit er ikke å prøve å spare seg til fant på System 2-arbeidet, men å gjøre de riktige tingene grundig nok, lenge nok, til at de blir intuitive.

Målet er ikke å «jobbe i System 2». Målet er å gjøre de riktige tingene så mange ganger at de blir System 1.

Der problemene faktisk oppstår

De virkelige problemene oppstår i spennet mellom det valget man tar og de forventningene som stilles. For å gjøre det konkret: man bygger en hurtig dataleveranse for ett formål, og forventer likevel at det skal kunne gjenbrukes av andre team. Man unngår begrepsavklaringer fordi det tar tid, og forventer likevel konsistente tall på tvers av rapporter. Man dropper historisering for å spare tid, og forventer likevel stabile tidsserier når noen seks måneder senere spør om trenden.

Hvert av disse eksemplene er, i seg selv, ikke dramatisk. Det er kombinasjonen av dem som er problemet. Og det som gjør det vanskelig, er at ingen av valgene nødvendigvis er feil i øyeblikket de tas – de er bare ikke tydelig kommunisert. Så bygger forventningene seg opp. Og en dag er de blitt en gjeld som er vanskelig å gjøre opp.

Bevisste valg er selve kvalitetsindikatoren

Noe av det som skiller modne datateam fra umodne, er ikke nødvendigvis at de tar bedre beslutninger i teknisk forstand. Det er at de vet hvilke beslutninger de tar – og hvorfor.

«Dette er en rask løsning, og det er helt greit – men vi vet hva den ikke er.»

«Dette er et grunnlag for hva vi skal bygge neste gang. Derfor tar det tid, og det er riktig at det gjør det.»

De setningene høres enkle ut. De er ikke alltid lette å si. Særlig ikke når omgivelsene presser på for levering, og det er fristende å love mer enn man bør. Men datateam som konsekvent kommuniserer hvilken modus de opererer i, bygger noe som er vanskelig å kjøpe: tillit til at det de leverer er det det utgir seg for å være.

Det krever ikke mer tid å ta bevisste valg. Det krever tydelighet. Tydelighet overfor teamet om hva dere faktisk bygger. Tydelighet overfor forretningssiden om hva som er en midlertidig løsning og hva som er et fundament. Og tydelighet nok til å si ifra – tidlig – når forventningene ikke stemmer overens med ambisjonsnivået.

Det er ikke fart som dreper kvalitet i datateam. Det er stilltiende antagelser om at begge deler er mulig på en gang, uten at noen sier det høyt.

Så hva gjør man?

Det finnes ingen fasit som passer alle, men noen grep går igjen hos de teamene som håndterer dette spennforholdet godt.

Det første er å gjøre valget eksplisitt. Ikke i et retningsdokument ingen leser, men i selve arbeidsmåten. Når et team starter en ny dataleveranse, er det verdt å ta noen minutter på å avklare: er dette en System 1-leveranse eller en System 2-leveranse? Hva er konsekvensene av det valget? Og hvem trenger å vite det?

Det andre er å beskytte System 2-arbeidet. Modenhet bygges ikke i restkapasiteten. Standarder, rammeverk og god teknisk hygiene konkurrerer alltid om plass mot det som haster. Datateam som faktisk klarer å heve modenhetsnivået over tid, er som regel de som har gjort det til en eksplisitt del av planen – ikke noe man håper å rekke når det er stille.

Det tredje, og kanskje viktigste, er å snakke om det. Ikke som selvkritikk, men som profesjonalitet. «Vi tok et bevisst valg her, og dette er hva det betyr» er en setning som bygger tillit – både internt i teamet og overfor de som er avhengige av det dere leverer.

Kjenner du igjen spenningen? Vi i Glitni hjelper datateam med å sette ord på hvilken modus de opererer i – og hva som skal til for å bevege seg dit de vil. Ta kontakt hvis du vil snakke om hvordan dette ser ut hos dere.