4#16 - Audun Fauchald Strand - Alignment in the Age of Autonomy (Nor)

«Det at det er en team sport; det tror jeg er i hvert fall noe data verden kan lære av (software development). / The fact that it’s a team sport; that’s definitely something the data world can learn from software development.»

Software development is ahead of the data world in many ways, but what can we learn from its methods? Audun Fauchald Strand, Director of Platform and Infrastructure at NAV, shares insights from building autonomous teams and balancing freedom with governance.

Here are my key learnings:

What is a platform?

• A platform is something you build on top of. Something that eases building applications, because if a common ground layer.
• A platform reduces the need for competency, since it predefines some choices.
• The capacity for change is higher when building based on a common platform, then when buying applications. 
• It’s important to find a balance in how much you should standardize through a platform and how much room for innovation should be beyond that.
• A platform can provide an «easy choice» that is the best practice way, but it should also allow for alternative, innovative ways to get jobs done.

Software Development and Data

• Software development has been a role model for data work, but they are at different stages of maturity.
• What is happening now in data platform is something Audun has experiences in Software 10 years ago.
• Yet, the principles are largely the same.
• Data is not as mature as software. There is still something to understand when it comes to use of tools and open source, etc.
• «Verden har blitt god å lage software. /The world has become real good at making software.»
• There is a certain agreement on what good looks like in software.
• Software has embraced open source in a much larger degree then data.

Data Mesh and the need for scale

• Data Mesh was a description if the data world from the perspective of a software developer.
• Change in architecture of operational environments have led to more possibilities to scale and to speed up operational data processing.
• This changes the need for speedy analytical data environments that have traditionally been built to compensated for the reduced flexibility of operational environments.
• Scaling up in a Data Mesh fashion, requires more data and analytical competency in teams.

Teams

• Working in teams, and having team ownership of products creates a certain sustainability over time.
• In software, with open source utilization, only teams can take technological decisions. Who else could decide what library to use for what purpose, then the team working hands on?
• You have to believe in autonomous teams for them to work. If not you will create dependencies that minimize their authority as a team and thereby capabilities to deliver.
• To create alignment there are some steps to take, from communicating openly, creating a tech radar to ensure alignment between team, to describing deliberate choices, rather then general principles.

5 learnings from article on alignment and autonomy:

1. Insource data expertise to ensure ownership, security, and business alignment.
2. Embed data professionals in cross-functional teams to enhance collaboration and generate actionable insights.
3. Balance team autonomy with governance by allowing flexible tool use within standardized data policies.
4. Foster continuous learning through asynchronous knowledge-sharing tools like wikis and Slack.
5. Provide clear direction with self-service data platforms to support scalability, efficiency, and governance.

Transcript

Intro

Speaker 1 0:00

Dette er Metadama, en helhetlig podcast om datamanagement i Norden. Hei og velkommen. Jeg heter Vinfried og takk for at du er med på en ny episode av Dama Nordens podcast, hvor vi sjåner å gi datamanagement i Norden et løft, vise frem den kompetansen og ikke minst det kunnskapsnivået vi har innenfor Fragfelt, og det er derfor jeg inviterer med meg nordiske eksperter innenfor både datamanagement og informasjonsforvaltning til en prat. Velkommen tilbake til Metadama, og jeg er superglad for å ha med meg en norsk ekspert for å sette opp autonome team, for å jobbe med team topologies, ikke bare i teorien, men også hvordan det praktisk anvendes i NAV. Audun Strand, velkommen.

Speaker 2 0:55

Tusen takk. Hyggelig å være her. Det er morsomt å være gjest på podcast.

Speaker 1 0:59

Ja, det er ganske morsomt når man selv har podcast. Du kjører plattformpodden.

Speaker 2 1:04

Det er ganske morsomt når man selv har podcast. Du kjører Plattformpodden. Ja, jeg og en kollega satte i gang Plattformpodden fordi vi hadde lyst på å dele for flere folk til å snakke om plattform og egentlig øke hva folk vet og hva folk kan om det. Det har blitt veldig gøy. Men det er enda gøyere å være gjest, for da trenger man ikke jobbe så mye i forkant.

Speaker 1 1:25

Uten å hoppe rett inn i tema, men hva er din definisjon på en plattform?

Speaker 2 1:31

Det er et veldig godt spørsmål, for jeg er slik litt Husk jeg leste en i Platform Strategy av Greg Hope som var litt sånn det man bygger ting opp på, det som hever hvor langt du trenger å gå for å bygge. Jeg husker ikke akkurat hva ordene var i den boka, men det han hadde i den boka, det synes jeg var veldig bra. Det er noe i den graden, det som elevates det stedet du trenger å bygge fra, og det synes jeg passer veldig godt.

Speaker 1 1:59

Veldig bra, spennende. Men du, før vi hopper rett inn i temaet, la oss snakke litt om hvem du er, hva du gjør i NAV og hva du kanskje gjør på fritiden din, når du ikke jobber.

Audun

Speaker 2 2:17

Ja, kan vi begynne med NAV? Jeg begynte å jobbe i NAV for nesten akkurat åtte år siden og har alltid tenkt på meg selv som utvikler, selv om jeg ikke har kodet så mye nå. De siste gangene jeg koda skikkelig mye var når det var pandemi. Så jeg håper litt egentlig på en ny pandemi, for jeg synes det var veldig gøy. Og nå tar vi opp denne podcasten i slutten av april og jeg skal hvert øyeblikk bli direktør faktisk for plattform og infrastruktur i NAV, og da får jeg ansvar både for applikasjonsplattform og dataplattform og en del sånne ting. Så da skal jeg prøve det å være ordentlig leder. Det synes jeg er litt skummelt, men det skal da gå på et vis oppå.

Speaker 2 2:52

Du har jo nevnt hobby. Jeg har barn, så jeg har ikke hobby nødvendigvis, men jeg er jo i Norvitt, er jeg veldig anlengd, 15-20 er veldig overbeves enn 15-20 veldig overbevarte menn i England. Så jeg liker å se på fotball og sykle og trene og sånn, men det er ikke noe sånn typiske hobbyer, vil jeg si. Uta er utsatt noen år til barnet har flyttet hjemmefra eller noe sånt. Da må man jo ha hoppyttre, så kan man finne på noe å gjøre?

Speaker 1 3:19

Tror du å fort eller favorittlager på fotball?

Speaker 2 3:21

Det er Tottenham, ja, og nå er det en uke igjen til de skal spille mot Bodø Blindt, og livet mitt kan enten bli bedre eller det kan ikke. Noen fotballmøter kan det ikke bli dårligere, så det er enten å holde seg dårlig eller bli dårlig.

Speaker 1 3:36

Du får enten nøvenner eller så tar du noen på dem i kamp. Ja, det kan være. Det er jo litt spennende, for vi snakker veldig mye om data, og data skal lære fra softwareutvikling. Det har vært en greie i mange år nå, Men du har jo hatt en fot i hver leier. Hvor ser du grensesnittet? Hva er det vi kan lære fra softwareutvikling?

Speaker 2 4:05

For det første vil jeg si at min oppfatning er, at man er fortsatt på et litt forskjellig modningsnivå. I hvert fall på plattformdelen, altså den applikasjonsplattformen, som jeg har til dels vært på lagen av den lagde jeg noe som lignet veldig på også for ti år siden. Det har ikke vært så mye nybrottsarbeid. Det har blitt bedre verktøy og mer modernisering og sånn. Men prinsippen er mye det samme. Men jeg har aldri hatt samme dybde kunnskapen på datam. Når jeg snakker med de ekspertene der, så er mitt inntrykk at det er ikke like modent. Man har forståelsen av hva er de riktige viktige vertene man skal bruke og hva er liksom de beste, og open source-miljø og alt det der er ikke liksom helt på samme sted. Sånn jeg ser det, så er det i hvert fall mer. Det regerer løsningsrom fortsatt. Men jeg tror at den tingen som har skjedd kanskje det siste det er begynnet å bli i fremtiden at verden har blitt ganske god på å lage software. Hvis man da må se på, hva er de største selskapene i verden, det de kan er å lage software i veldig stor skala, og uten at vi trenger å gå inn i alle kontroversene, så er det veldig mye som har blitt en konkurranse å lage best software, det å lage bil hadde jolig ganske enighet om hva det betyr å lage god software. Det stedet som har trukket fram best er Accelerate-boka At endringer er enkelt og tilgjengelig, at du håndterer feil bra, at du jobber tverrfaglig og alt det der er måten man lager software på, og spesielt på den delen endringsevne og smidig utvikling, uten at vi trenger å klage noe om hva det betyr.

Speaker 2 5:54

Så er liksom å få de verktøyene, få den prosessen. Det at det er en teamsport, det tror jeg liksom er hvertfall noe dataværen kan lære om. Så liksom bare på hvordan man jobber Og så på grensesnittet. Så tenkte jeg første gangen jeg leste datamersartiklene til Shabakta Ghani, så tenkte jeg at dette var på en måte, dette var dataværen. Beskrevet fra mitt ståsted. Det var liksom ta de godede gamle softwareutviklingene med SIP'en, med domain driven design og alt det der, og beskrive data i den verden. Og det viste seg å være altså sånn som alle sånne artikler. Så var det ikke. det var ikke bare å lese det og gjøre det, men jeg tror i hvert fall de tankene der er veldig bra å gjøre med. Så det tror jeg er en ganske viktig del av. Jeg tror som ikke-dataekspert at det er noe som kommer til å forme hvordan man jobber med data, men jeg tipper det kommer til å ta ganske lang tid.

Speaker 1 6:54

Rytter. Ja, det er litt spennende, fordi vi lever i en verden hvor folk er veldig kjappe å kalle ting for død. Så nå har det vel dette året begynt og datamash havner på den listen av ting som er død, Fordi mange av dem skal bare ha prøvd og det fungerer ikke akkurat slik det er beskrevet i læreboken. Så jeg tenker det er som du sier. det er en utvikling som går over tid.

Speaker 2 7:18

Og så har hun begynt med en startup og de kommer med den første lille leveransen av tingene sine nå for noen få dager siden. Jeg har ikke fått sett og lest noe på alt sammen, men for meg, så ut fra det jeg leste om det de skal lansere, så er det ganske store avstand også fra det de sier de lanserer. Sånn folk har tenkt at de lager datamesting. Så jeg tror nok det er et stykke igjen å gå Og at min take på det hvertfall er at sånn man har tenkt datamesting nå fortsatt har vært en ganske godt forankret inn i dataverdenen, mens noen av de prinsippene hvertfall som jeg hører fra den nyeste NextData, tror jeg det heter er tatt enda mye mer over mot applikasjonssida. Det er enda mer containerized data products og autonomi på dataproduktssida, som minner meg veldig om sånn jeg er vant til å lage applikasjoner og docker container og sånt som jeg tror kan ta hele greia et steg videre.

Speaker 2 8:16

Men det sier jo litt. De har jobbet i to år snart bare med det produktet. Det er sikkert dyrt og umodent. Jeg tror fortsatt man har et godt. Ja, det er lenge siden Amazon kom med EC2-server som bydde hele den sky og mikrotrans og den verden, og det er 20 år nesten. Det har tatt før. Det liksom har blitt ganske mainstream, og det kan fort ta like lang tid på data. Ser man høy, så tar det sikkert 15-20 minutter.

Speaker 1 8:43

Ja, men det, at ting tar tid, Det er litt spennende, fordi jeg føler at i softwareutvikling går ting litt kjappere enn i dataverden, Og så kjenner jeg på at mentalitet og bygge, prøve nye ting har den der. Det ser veldig flasket ut, men endring som en konstant Når det treffer dataverden, så tror jeg ikke det fungerer. Det er lett å oversette en til en Den der bygge-bygge-bygge-mentaliteten for å til en livssyklus-tenkning i data, hvor man skal tenke over mange ti-sju år-perioder, og vi liker å ha data i systemer hvor kanskje applikasjonen utdateres over tid. Men man må håndtere dataen til tross for det.

Speaker 1 9:29

Det er en veldig annen tankesett. Hvordan tenker du at dette kan spilles sammen på en god måte?

Speaker 2 9:34

Ja, det er jo alltid det som blir møtt meg ned. Hva med lineage, hva med å holde statistikken lener over tid? Og jeg tror jo at det er selvfølgelig noe annet. Men jeg tror ikke at det nødvendigvis trenger å bli at hvertøystakken og måten man jobber på blir sånn. Jeg sitter jo i NAV nå og vi har applikasjoner som er 40 år gamle. Det er selvfølgelig ikke det vanlige, men det er jo ikke mulig, det heller. Det viktigste, tror jeg, er og dette tror jeg også gjelder data. Jeg kan se for meg i hvert fall, at selv om man vil at dataene skal gå langt tilbake, så bør man jo ikke si at sånn det var i starten er sånn det skal være for alltid.

Insourcing and ownership

Speaker 2 10:13

Så endringsevnen, på tross av at man har historikken, tror jeg, er ganske viktig. Da og da begynner det å bli viktig. Og Det du sa med å godta endringer, det er min favorittsetning fra Smidigmanifest. Det er jo embrace change Og ikke bare se på at endringer er noe som skjer, men at endring sannsynligvis er på grunn av noe bra, noe du har lært nå, eller verden har forandret seg. Det eneste du kan gjøre er å tenke at det er en god ting. Du kan ikke bare si at nei, da orker jeg ikke mer.

Speaker 1 10:43

Ja, det er noe med aktiv eller passiv holdning til endringer, og at du kan faktisk være i forhold til å drive endringene i stedet for å bare være overvirket av endringene som skjer rundt deg.

Speaker 2 10:54

Ja, og det tror jeg også gjelder litt i koblingen mellom den operasjonelle og den analytiske verdenen. Jeg synes igjen det er lett å komme eksempler fra NAV, hvor man tidligere hadde noen få ganske store monolithiske utøver med store databaser som endret seg selv. Og da var det å lage en analyseplattform ved sidene av som relativt enkelt kunne ta kopier av dataen og hente ut dataene og kunne si, at hvis dere endrer dette her, så må dere si fra til oss, og så skal vi håndtere det. Men så har jo arkitekturendringene på nattrasjonelle siden blitt, at vi har fått mange flere databaser. Databasene er ikke lenger en integrasjonsmotor, så de kan endres mye fortere I NAV. Så endrer vi, ja, så endrer vi. Vi har 1000 studierapplikasjoner, vi kjøper nesten like mange databaser og vi deployer til produksjon 3000 ganger i uka. Og da går ikke alt å si, at man skal bare holde selv med det, at analyseplattformen skal være immun mot endringene.

Speaker 2 12:00

Eneste måten å ta i dem er jo liksom å lage et system som holder den endringen eller som ikke stopper den endringen. Fordi de aller fleste er enige med at det, at man endrer seg så ofte er bra på den operasjonelle siden, og da må man lage en analyseside som aksepterer det og som embracer den endringen da og sier at det står bra, at dere har blitt flinke og da må vi tilpasse oss det. Og da tror jeg at den eneste gode løsningen jeg vel egentlig har sett er liksom den datamers-tankegangen med at det operasjonelle siden må tilby analytiske dataprodukter som kommer fra applikasjonen sin, fordi da kan man jo tilpasse applikasjonene sine til å også håndtere de dataproduktene. Så tror jeg det betyr, at man trenger mer data og analysekompetanse inni de teamene. Så problemet med dette er, at du dytter enda mer på noen som allerede har nok å gjøre. Men fordelen er, at du gjør det på et sted hvor du kan endre systemet til å faktisk levere det.

Speaker 1 13:01

Det var en veldig smooth overgang fra verktøy til arbeidsmetodikk. Jeg synes det er helt spennende, og så skal vi dypdykke litt mer i dette med autonome team og team topologies etter hvert, men helt overordnet, hva tenker du er arbeidsmetodikken? Vi som jobber i data kan ta nytte av eller få lære fra softwareutvikling.

Speaker 2 13:24

Det som i hvert fall kjennetegner de tingene som er suksessfulle når man er på software, er at man jobber i team. De stedene som fungerer best, der er det mye part-programmering til og med mob-programmering, og man tenker ikke, at det er enkeltpersoner, det er teamet som eier det, fordi da har man jo en bærekraft og en tidsperspektiv som gjelder det. Så er det team. Kan du se for deg at kan eie noe over lang tid for teamet kan du bytte ut folken i med et enkelt. Men hvis det alltid er en ganske stor endring, er jo forholdet til leverandører og open source-kode egentlig. At software-verden i mye større grad er en brace av denne open source-verden, hvor man ikke lenger kjøper produkter som man bygger på, men man bruker de open source-bibliotekene som man trenger og lar det bli en del av applikasjonen, at man i mye større grad tar ansvaret selv, og det blir jo en litt annen arbeidsmetodikk av det også. Da er det jo mest at man har full kontroll i større grad, og det er flere sånne. Det er litt av denne autonome team-team-kombinen.

Speaker 2 14:40

Altså i den verden så er det bare teamene som kan ta teknologibeslutninger, det er ingen andre som kan sitte og si, nå skal alle bruke det biblioteket eller det biblioteket, fordi det er for komplisert. Men i en sånn verden nå, fordi da må man jo finne ut, ja, men hvis vi ikke skal kjøpe det, hva skal vi kjøpe da? når kan vi kjøpe noen? hvem er det som styrer hvordan vi bruker det? mens i en open source verden, så tenker jeg, det er mer distribuert. Man må jobbe annerledes for og få folk til å gå i samme retning enn når man har en avtalefestet av plattformen.

Speaker 1 15:18

Tenker du at det her? som jeg hører, det har en veldig tydelig innflytelse på hvilken kompetansekrav du må sette til disse teamene og individene i teamene, som er kanskje mye høyere, mye tydeligere forstået, mye tettere på leverandøren enn det det har kanskje vært før på leverandørene enn det det har kanskje vært før.

Speaker 2 15:39

Jo, det tenker jeg. Så tenker jeg at det er en av tingene som en plattform hjelper til med at den løfter opp sånn at man trenger ikke å forholde seg til alle disse tingene. En del av valgene blir tatt til en plattform og så lager man verktøy som teamene kan bruke sånn at de ikke trenger å alle disse tingene. Men du har et mye større grad av produktorientert mindset fra plattformen opp mot teamene, slik at de prøver å løse de problemer du har, og du har en endringshjelm på plattformen som er mye større enn kanskje på et kjøpt produkt.

Speaker 1 16:09

Når jeg leser team topologies, så er det et begrep jeg måtte tenke på nå når du forklarer dette, og det er cognitive load Og like er egentlig ikke det begrepet, fordi det høres ut som folk er veldig begrenset i hva man kan oppfatte eller oppta. Men dette handler mer om team enn det handler om individer Og sikre at man har et verktøy eller en basis som gjør det lett å gjøre rett, som tar gode valg, slik at ikke hvert team trenger å gå gjennom disse.

Speaker 2 16:42

Før Team Topology, så pleide jeg å si at plattformen vår skulle fjerne den unødvendige kreativiteten, fordi i en verden hvor du har veldig mange ting å velge mellom, så er det jo lett å forelske seg og fordype seg i noen av disse valgene som egentlig ikke er sentrale for at du skal produsere verdi. men jeg kjenner mange, og jeg er også blant dem, som tenker at det er minst like morsomt å finne ut hvordan vi skal gjøre lastbalansering eller logging som hvordan man skal tilby verdi for brukeren. Men det er en plattform som har mange av disse valgene for deg, og så er det så veldig viktig å balansere for noen av igjen. og det vanskelige er jo ikke å bli for grisk og prøve å bestemme for mye, men å klare å finne balansen på hvor mye du skal bestemme, sånn at du beholder innovasjonen men du også har farten.

Cross-functional teams and competencies

Speaker 1 17:28

Greg Hope i Platform Strategy-boka sier at det som er spesielt med software er jo at det ofte sier standardisering, fart, og det er ikke alltid, det gjelder andre steder men her gir det til og med innovasjon, fordi det er noen steder du innoverer på, utenom det du standardiserer på, og det tror jeg litt på, da Jeg har tidligere beskrevet det som en Formel 1-bil som har visse sikkerheter i bilen installert. Det har en guiding system, det har noe styring, som egentlig er bare der for å sikre at du kan ha mer fart enn uten.

Speaker 2 18:04

Det er ikke sant.

Speaker 1 18:05

Helt gøy Vi skal snakke litt om disse autonome teamene. Nå har vi nevnt det en del ganger. Det er også en veldig god artikkel som du har skrevet som heter «Optimizing for fast flow in Norway's largest biocracy». Det er noen år gammel, men jeg tenker den er like aktuell som den har vært denne gangen. Og så har jeg prøvd å se på hva er kjernen av det du skriver. På en måte er jeg enig eller uenig om at du rett kjerne her, men det er noen ting som er veldig spennende. Det ene er dette med innsourcing av dataekspertise Det å gå vekk ifra og ha et team offshore, et sted som tar valg på vegne av deg, til at du tar eierskap til de ulike selv. Og så er eierskap og ownership alltid en stor diskusjon i dataverden.

Speaker 1 19:08

Så det kunne vært veldig spennende å se hvordan denne innsourcingen av dataekspertise kan påvirke hvordan folk i selskapet kan ta eierskap. Det er det første. Det andre er dette med cross-funksjonelle team og har forskjellige kompetanser i et team, som jeg synes er kjempespennende, fordi det åpner muligheter til å kanskje se flere løsninger enn det du ville gjort hvis du ikke hadde andre disipliner involvert. Og så er det jo noe av det som er kjernen til mitt datagrafenens hjerte. Det er, hvordan balanserer man autonomi og styring, som dere hadde noen spennende tanker om. Kanskje vi kan begynne med den der innsåsing og utsåsing.

Speaker 2 19:51

Ja, vi må bare få lov å begynne å si at dette er basert på en presentasjon som jeg og Truls Jørgens hadde sammen, og det skal ikke nektes for at det handler om å skrive den neste parten av artiklet. Vi lagde jo på sånn en gang, men han synes det er morsommere å skrive enn meg. Men insourcing tenker jeg, det handler jo litt om. for det verste, så er det litt det. hvis du ikke insourcer, hvis du liksom outsourcer, så mister du egentlig. I en bransje som vår så går ting så fort, at hvis du ikke er med på ting, så mister du kompetansen, og da mangler du egentlig muligheten til å være en kompetent kjøper. Så liksom outsourcing blir verre enn bare outsourcing. Du ender opp å gå helt over og være helt bunnet av leverandøren, for du har ikke kompetansen til å skjønne hvordan du skal forholde deg til leverandøren.

Speaker 2 20:40

Og tidligere IT-direktøren Nath sa, at du må ha peiling for å kjøpe peiling, og det stemmer. Og problemet er, at for å få peiling så må du jobbe med det, og da etter hvert så trenger du ikke å kjøpe peiling. Det vanskelig å være fungerende i midten over tid. Derfor er det sikkert ofte en candle, fordi etter hvert, som du har god peiling, så finner du til at dette kan jeg kjøpe kompetent av noen, og så går det bra en stund, men så mister du peilingen. så har du ikke kjøpt det, og så finner du, at da blir du begynnende å bygge det selv I NAV skal ha ganske mye insourcing, for eksempel både på software og data.

Speaker 2 21:18

Vi har jo ikke en konkurransesituasjon som sånn. Vi har jo et ganske langt tidsperspektiv hvor vi vet, at vi kommer til å drive med dette her ganske lenge, og da er det dumt å være helt i lomma på leverandøy. Men det jeg tenker er universielt riktig på tvers av data og software er jo, at insourcing betyr, at du kan gjøre det her uten overleveringer. Du får liksom livssyklusen fra tenkinga til gjøringa til læringa, som igjen fører til tenkinga til gjøringa. Du kan jobbe iterativt mye lettere over tid og med kontinuerlig forbedring når du har insourcet det enn når du er en leverandør. Det var det forholdet andre.

Speaker 1 21:57

Hvordan forholder det seg til eierskapet i selskapet, eierskapet til datene, til produkter du jobber med?

Speaker 2 22:04

Ja, og der tenker jeg, at der tror jeg, man egentlig må slutte å tenke på data og applikasjoner som forskjellige ting og heller dele opp butikken din etter domener eller hva man driver med, opp butikken din etter domener eller hva man driver med. Og så må man dytte både data og komplikasjonskompetansen inn sammen. Og da her er det et eller annet sted, hvor jeg tror, man ikke helt har finnet hvordan man skal gjøre det, For noen ting er jo noe av det, kan man jo si, dette er bare programmering. Det er ikke noe å si om du programmerer et dataprodukt eller et API, Det er jo programmering uansett, og da kanskje man ikke trenger å ha sånne båser, man setter folkene inn i. Men andre ganger så er det jo litt sånn front-on-the-backend-programmering, dataprogrammering og backend-programmering ikke det samme. Så noe av det vil jo være hva man kan. Så må man finne ut h uten å lage sånne gigantiske team som har 20 stykker, fordi alt skal være der.

Speaker 2 23:00

Og det er et sted hvor jeg tror plattformen kan hjelpe litt, at noen sånne generalistmennesker kan lage litt av flere ting, så lenge du har gode, tydelige plattformer som er flinke til å veilede deg, til å gjøre de riktige valgene Lett å gjøre, rett som du sa. Det tenker jeg, gjelder både på data og applikasjoner På data. Det å kunne beholde historikken på data, det er liksom en sånn implicit ting som man bare vet er riktig. Men det er også noe du kan lage og gjøre det lettere å få til med et verktøy, At du kan lage en plattform som har det innbygd og som passer på at det skjer, akkurat som du kan ha en plattform som har god overvakning eller god lastbalansering eller god skalering. Jeg tror ikke det er noe annerledes egentlig. Det er bare den modenheten kanskje ikke er helt på samme nivå, at man har ikke de samme verktøyene på det, jo midt i dette med cross-funksjonelle team.

Speaker 1 24:01

Og så snakket vi innledningsvis om software engineering, softwareutvikling som et sted, vi kan ta læring fra for data, men det er mange andre steder vi også kan ta mye læring fra. Man begynner med risikomanagement eller business and errors. Hvor bredt skal disse crossfunksjonale teamene være stilt opp? Skal det være noe forretningskunnskap der? Skal det være noe datakunnskap? Skal det være noe utviklingskunnskap? Hva tenker du?

Speaker 2 24:28

Jeg tror det handler litt om hva du jobber med i navn, hvor i de teamene, hvor man lager, automatisere loven. Det kan du ikke gjøre, hvis du ikke er en jurist eller tre sannsynligvis i teamet ditt. Det går ikke. Mens på mer tekniske ting det er jo Wi-Fi før, for eksempel så har du muligheten til å gjøre mer med bare teknologi eller teamet som monterer NAV enda. Så når du er med teknisk problem, da trenger man mindre, kanskje litt mer kommunikasjon og sånn, men du trenger ikke den samme bredden av fagkunnskap som er noe som er så domenen, altså så juridisk, for eksempel som saksbehandling. Jeg tror det er litt forskjellig, men det vanskeligste er jo, hvis du ender opp med å spørre noen andre hele tiden. Det funker jo ikke. Teamet må jo ha kunnskapen som skal til for å løse problemet. Og så er det noen problemer mer tverrfaglige enn andre.

Speaker 1 25:26

Men målet er å kunne løse problemet i teamet uten at du trenger noen rundt deg som skal sette på noe styring eller noe input utenifra.

Speaker 2 25:41

Ja, det tenker jeg. Så er det selvfølgelig tilfelle, hvor du kanskje må ha hjelp av noen, ikke fordi problemet er vanskelig, men fordi konsekvensen er så store. Det er en ting, man skal leve spare, fordi det er så mye penger eller det er så stor risiko, men det, tenker jeg, blir noe annet. Det handler jo ikke om problem løses, men konsekvensen av løsningen. Men ellers er det jo det. Og da tenker jeg, det er mange som synes at noe med team høres skummelt ut. Men hvis du har satt team i stand til å ha all kompetansen som trengs, så bør du ikke være så skummelt. Og i NAV for eksempel, så har vi ganske mye matrisorganisering, og jeg tenker jo, du har inn i det teamet, ikke lage rammer, men få noen med til å lage det, Da er du jo den sikre, at det blir bra. Så er det selvfølgelig veldig få som har personer nok, da setter de flinkeste folkene seg inn overalt. Men sånn er det jo alltid. Det vil alltid være begrenset ressurser, så da må man jo prioritere.

Speaker 1 26:38

Jeg har jo tidligere beskrevet datateam i Data Mesh som et solarsystem, og så tenker jeg på autonome team som domeneteam, som graviterer rundt en plattform, men det er noe som holder de sammen. Og så er det i mitt hode noen sentrale styringspunkter som man har, standarder som man setter opp i plattform, for eksempel, som man kan kodifisere, men det er også noe som kanskje må struktureres på tvers eller noen sånne hva skal vi kalle det? ytre rammer av governance. Og der blir det veldig lett å tenke ja, men disse ytre rammene, hvis de skal være like for alle team, så må det være et sentralt team som styrer dem. Og der er vi tilbake til hvordan balanserer man autonome team på den ene siden med den der styringen? og klassisk norsk oppsett er jo at man har et styringssystem et eller annet sted som har satt opp noen policy som man skal forholde seg til, som er kanskje kun i prosa, som alle team skal ha, som er et utgangspunkt. Men hvordan klarer man da å ha autonome team hvis man skaper disse avhengigheter til noe som ligger utenfor teamet?

Balancing autonomy and governance

Speaker 2 27:52

Der tenker jeg, at for det første, så må man jo innse, at det som skal til for å lage et godt software er autonome team. Det er for en måte det verden har vist seg sånn, at det går ikke an å sitte, at noen skal sitte og bestemme hva alle skal gjøre. Du må tro, at det er så komplisert og så teknologisk, at det er blitt tett på som kan gjøre det best. Og da må du ta den neste steget, som er å gjøre det i tverrfaget. Altså de må ha for å væreøse problemet. Men det er jo sannsynligvis så. Vi må da fortsatt ha en slags retning på ting. Du vil jo ikke at alt skal gå i helt forskjellig retning. Og det som var altså den presentasjonen som den artikleren bygget på vi fikk ikke lov å kalle artiklerne, men opprinnelig til den presentasjonen er jo alignment in the edge of autonomy, autonomy, og det synes jeg, det er det vi prøvde å beskrive der og det, og igjen, dette var både Truls og meg det beskriver egentlig det styringssystemet vi hadde over tid klart å lage for arkitektur og teknologi i NAV, og det baserte seg egentlig på et sent avverteg, som var fire ting egentlig, men jeg kan prøve å gå inn en dag For det første. Så var det, noen av de var deskriptive, noen av de hadde bare om å beskrive hva som skjedde, for det er mye alignment i, at du vet hva andre gjør. Og så var det noen som var normative, som vi mister i grad fra noen hva som var bra.

Speaker 2 29:16

Og de deskriptive teknikkene. Det var en så teknologiradar som vi fortsatt har, men som viser seg å være ganske vanskelig å skalere, blant annet. Så vi sliter litt med det nå, men tanken er at det skal være en radar, sånn som en radar er. Det bare beskriver hva slags teknologi bruker de andre og hvilke teknologivalg har de andre tatt og hvem var bra eller dårlig. og du må oppdateres på en jevn vakt. Men det er bare fordi noe vises på radaren betyr ikke at du må gjøre det samme som de. Det er bare et informasjonspunkt at noen har valgt det de har valgt. Og så den andre tingen som er litt sånn dyp for teknologiradaren er veld og grunn, den sånn, litt sånn vitere ting.

Speaker 2 30:02

Vi hadde det som vi kalte teknisk demo, som egentlig er mer sånn strukturert læring, deling av læring. Man bruker en time på å fortelle hva som er. Vi prøvde dette her, vi fikk dette her og dette var alle læringene våre. Så du får en slags felles kunnskapsgrunnlag. Det kan altså være kursing og alt mulig, men at kompetansene er noenlunde like på ters. Så det var liksom de deskriptive tingene, og så de normative var.

Speaker 2 30:27

Den ene var egentlig den rollen som jeg og Truls hadde Truls har sluttet, det er derfor jeg sier hadde som da var teknologiprincipalene, som gikk rundt og prøvde å snakke med mange og ha mye kommunikasjon med team og så prøve å destillere noen sånne retningsgivende punkter. Dette her er den retningen vi mener Nalder går i teknologisk, vi vil bruke continuous delivery eller vi vil bruke, vi bør ja, automatisert testing. Egentlig Det føltes veldig åpenbart, men bare liksom det å si det fall, det var veldig bra. Men samtidig, når vi sa det, så var vi veldig opptatt av å si at dette her er ikke føringer og krav, dette her er det vi mener er lurt. Men er dere som bestemmer.

Speaker 2 31:09

Og så den siste tingen var jo da, fordi jeg tror jo altså man kan sikkert tenke seg at vi kunne tatt alle de tingene vi mente oss kunne vi lagt prinsipper, skrev det prinsippene for teknologiutviklingen av. Men det tror jeg ikke funker, rett og slett fordi for at prinsipper skal være tilgjengelige for mange, så må de være lysegrå og kjedelige. De blir gjennom, altså det blir hensiktsmessig og god balanse og alle de ordene som gjør at det egentlig ikke betyr noe. Så da er det viktigere at vi har meninger som er tydelige, men som sier vi dere velger selv hvilken av disse her dere skal bruke og hva dere mener om det. Men det siste trikset var jo å jobbe tett sammen med plattformen og operasjonalisere de meningene ned i plattformen sånn at det ble en sånn lett å gjøre rett.

Speaker 2 31:58

Det letteste valget for mange team ble å gjøre det vi mente var lort, fordi til valget for mange team ble å gjøre det vi mente var lurt, fordi det var det plattformen lagde til. Og da tenkte jeg helt fortsatt ikke å si nei til noen, det var bare, du kan gjøre det, så sa du det. Men jeg ser så lett det er å gjøre sånn her, og den kombinasjonen fungerte veldig bra, fordi det er jo veldig, det er jo skattformen. Det var ikke sånn, at jeg og Truls visste alt som var lurt. Overraskende lite. Vi visste om hva lurt og vi kunne ombestemme oss av feil. Så det var viktig at vi hadde et drett spekter av innovasjon.

Speaker 2 32:38

Da må man ha god dialog mellom teamet, ikke plattformen. Det må ikke bli sånn bestilleregime at noen sier ja, men dette trenger vi så, dette må dere lage. Det må typisk være. Da må plattformen si nei, dere får lage det selv, og hvis det fungerer å nå flere timer enn det selv, da kan vi gjøre det, fordi det må liksom være en stordryst for dere også, og den løser aldri alt for alle. Den løser kanskje 80% av behovene, som er det 80% av teamene trenger, og så har du en sånn edge case som du må løse selv, og det tror jeg. Det kan jeg ikke bevise meg, men det er en tilgjengeligning som jeg tror også fungerer i datavarven.

Speaker 1 33:14

Dette var en fantastisk bra gjennomgang og jeg har tusen spørsmål som jeg tenker kan være viktig. Du snakket om prinsipper og meninger. Disse prinsippbaserte strategier er noe jeg begynner å bli allergisk mot, fordi det er så mange lommer og rom man kan gjemme seg bak. Det er mange måter å interpretere prinsipper på. Det skal romme så mye. Så jeg snakker veldig mye om deliberate choices. Man tar bevisste valg som man har et godt informasjonsgrunnlag for, men bevisste valg som man kan stå bak Og det kan være feil valg også, men så må man ha mulighet nå å snu.

Speaker 1 34:01

Og der jeg alltid tenker er veldig viktig her er alignment skapes gjennom en felles målsetning, en felles retning som man går på, og den retningen må settes, og den retningen som da settes, den må så settes på en måte at teamene forstår sin rolle i dette. Hvis ikke, så så begynner man å lage sine egne mandater og gå litt utover og gå litt i andre retninger. Og det tror jeg er en veldig lur måte som dere har løst det på er å gi rom og plass for det, men ha en måte som er den middelveien man kan gå. men så er det muligheter der å utvikle seg igjen.

Speaker 2 34:45

Og så, etter at vi lagde denne artikkelen, så har vi også blitt veldig glad i noe som først var det en Martin Fowler-art eller at det kommer egentlig fra Redemency Organizations, en sånn der hippie-bok om hvordan moderne organisasjoner skal være. Men du gjør noe de kaller The Advice Process, etter en som heter Andrew Harmel Law har laget en Architecture Advice Process artikkel på martinfilercom, og nå har han kommet med en bok som heter Facilitating Software Architecture. Men den prosessen om hvordan ta beslutninger er veldig bra. Før vi hadde lest det, så pleide jeg å si hvis du jobber i teamen din, så alt er lov, bare du sier det høres jo litt sånn vilt ut. men når du leser artikkelen, så blir det beskrevet mye bedre, fordi det han sier der passer inn i hele den prosessen vi har snakket om, at enhver person i NAV kan ta en beslutning. kravene er jo, at han rådfører seg med eksperter og de som blir berørt, og så må han dokumentere beslutningen etterpå og publiserer den. Men da passer det med den modellen vi hadde tidligere, at alle ser, hva alle gjør.

Speaker 2 35:48

Det er teamet som ansvarer, men det er noen eksperter som sier hva som er lurt, og det er noen krav til deg for at du skal ta en beslutning. Men det sitter ikke noen i midten og er flaskehalser og skal bestemme alt, og det er litt. så må du innse at det som er viktig eller det eneste som fungerer er autonomet inn, og så må du bygge prosessen din rundt den her kjennelsen av at det er teamene som er best egnet til å ta beslutninger, og så må du få det til å skalere. Du kan ikke begynne med et system og håpe at det blir noe etanomi igjen. Etanomien må være kjernen, og så må du l prosessene rundt. Og da for eksempel tror ikke jeg, at prinsipper på Confluence har så mye effekt.

Speaker 1 36:26

Når man kommer inn i NAV som en ny utvikler eller dataekspert for å jobbe i NAV og møte kulturen i NAV, så er det jo kanskje litt annerledes enn det man er vant med. Og så tenker jeg, det er kanskje jeg vet ikke om det særlig norsk, men det er en veldig sånn konsenskultur man har i Norge, at man søker konsens, man inviterer flere inn i et møte enn det man kanskje trenger for å skape den der basisen, og så har jo særlig det offentlige i Norge hatt en veldig sånn rykte for at det er veldig vanskelig å ta beslut verdt i en konsens. Hvordan opplever du at nye folk som kommer inn i NAF jobber i eller opplever disse autonome teamene og klarer å tilpasse seg til denne tankesett?

Speaker 2 37:10

Jeg begynner med å si at jeg har en tendens til å overselle litt. Det er ikke alt som er like bra som jeg vil at det skal være hele tiden, men det er alltid steder hvor vi liksom fortsatt kjemper mot den byråkratiske måten å gjøre det på. Men jeg tror jo, og så tror jeg, vi har kommet lenger her på applikasjonssiden, på datasiden, fordi vi har jobbet mer med det. Så det er nok lettere å tenke at dette her, det du beskriver ikke, er nok mest fortsatt på applikasjonssiden. Så prøver vi å få det til å bli mer på datasiden. Men vi prøver jo å ha Jeg, for eksempel, jeg og en annen av andre teknologiprinsekene er en del av anbordningen, og jeg forteller om dette her til alle sammen som begynner.

Speaker 2 37:52

Vi står og sier at det er teamene som bestemmer, og her er det en artikkelvis process og dette er sirkelautonomia, det av det alle får høre når de begynner, og det gjelder både data. Jeg hadde en presentasjon tidligere og det var både jurister og andre med i den anbordingen. Så vi prøver å fortelle det til alle. Det tror jeg er en viktig del av det, bare at alle får høre det hvertfall. Og så er det igjen. Det er i timene, det må gjøres, det hjelper ikke og sier det, hvis ikke det går i timene. Og du holder ikke, at vi står og sier det for at det skal skje i timene, eller de må jo ville det og gjøre det selv. Jeg er ikke kapabelt å styre 150 team.

Speaker 1 38:30

Knappt et par er liksom innenfor det jeg får til tror jeg, ja, det er kanskje det som er realiteten, at de facto er det veldig mange team som tar autonome beslutninger, beslutninger, men så søker man en konsens før eller etter for å sikre seg inn i denne beslutningsprosessen.

Speaker 2 38:46

Og så er det jo ofte vanskeligere på tvers av fagdisciplinene. Den prosessen jeg beskriver er nok mer naturlig for en utvikler eller for en jurist, og den må man jo tilpasse også videre. Så det handler jo også om å lage eller å finne kompromisene og kanskje legge på mer dokumentasjon enn det som er naturlig for teknologene. For det juristene trenger det å bruke mer tid på å analysere altså en typisk sånn problem eller i hvert fall uenighet er jo, hvor teknologene de folk tenker, at jeg lærer å putte det i produksjon. Det trenger ikke å være helt riktig, men jeg får læring av å putte det i produksjon, mens juristene tenker da på ja, men da gjør jeg ting som ikke er riktig.

Speaker 2 39:33

Men så kan juristene gå for langt over på den siden, så de får nok og kanskje legge ut ting som er problemer. De kan kanskje bruke mer tid på å forandre og forstå lovverket før de er rundt av koda. Så det er begge veier, det kan gå for langt i begge retninger. Det er veldig vanskelig å si, at det er akkurat der vi skal være. Problem er litt annerledes og litt nytt, og det er forskjellig lovverk og forskjellig folk og alt mulig.

Speaker 1 40:04

Men det er vi jo tilbake til. De styrkene med å ha autonome team, at du i teamet kan velge det punktet som er rett for deg, om det skal ligge på 80% eller 95%, avhengig av den business case som du jobber med.

Speaker 2 40:18

Men da kan jo jeg bare si vi er et prinsipp på konflikt, og du skal ha en hensiktsmessig balanse mellom. Så har man alltid rikt.

Team Topologies

Speaker 1 40:25

Skal vi bruke noen få minutter for å snakke om Team Topologies før vi avslutter. Og jeg ser jo at ditt navn dukker opp på Team Topologies sin hjemmeside også. Kanskje du kan fortelle litt, for hva er egentlig Tinder-politisk, og hvorfor har det blitt så populært?

Speaker 2 40:44

Det er jo en bok egentlig, som Matt Skelton og Manuel Pei skrev nå er det fem-seks år siden som egentlig er en beskrivelse av mønstre for hvordan team kan eller hvordan team er og hvordan team fungerer. Og alle softwareutviklere liker veldig godt mønstre, de vil jo se mønstre, og det de hadde gjort var at de hadde sett hvilke type team som finnes og hvordan de interagerer med hverandre og klarte å kategorisere det. Så de kommer vel opp til skal vi se, om jeg husker alt i fortatt fire forskjellige team. Det var platform team, som da er sånn som NICE og sånn som lager platform. Så har du streamer line team, som er liksom de som jobber med strømmer av verdi, et vanlig applikasjonsteam, et vanlig datateam. Og så enabling teams, som er litt sånn hjelpeteam, som kanskje går inn et sted, hjelper de å komme i gang og sånn trekker seg ut igjen.

Speaker 2 41:45

Og så er det en litt mer spesial case som er complicated subsystem team, som jo på en måte er som pakker inn et veldig komplisert problem som ikke skal kroneres for andre, men ikke trenger å være en plattform eller en tjeneste. Og så er det as a service, som jo er liksom at de tilbyr en tjeneste, en plattform gjør det, og så er det. Hva er den siste da? Jeg kommer ikke på. Det er en måte til Team topologies knallkjapt googling her Key concepts. Nei, facilitating, som er, at man det er enabling-teamet, at man legger til det for andre type. Så det er det.

Speaker 2 42:27

Team-depotet er at man prøver å beskrive mønstre for hvordan team fungerer og interagerer, og så er det egentlig en god måte da å analysere sin egen organisasjon på og så bruke den kunnskapen både til å se hvordan man jobber og kanskje man skal gjøre noe, eller hvordan man skal designe organisasjonen sin til å være. Og så er det jo mye beskrivelse av hva som er lurt og dumt å gjøre i de forskjellige teamtypene og de forskjellige interaksjonsmodusene. Som er mye god læring Og med alt dette, så har jo NAV.

Speaker 1 42:57

Hvordan ser dere, at dette har fungert? Hva har fungert bra og hva har kanskje ikke fungert så bra?

Speaker 2 43:09

Det som ikke har fungert. Vi hadde en tanke om at du skulle prøve å gå veldig dypt inn i dette her, og vi hadde prøvd å sette i gang et team til å gjøre klassifiseringer og prøve å bruke språk og mønsterne veldig aktivt. Det fikk vi egentlig ikke helt til. Jeg vet ikke helt hvorfor, men det var litt vanskelig å få noe ut av tuten på det. Så det er det. Vi egentlig bruker det mest som en slags støtteverktøy for team, tror jeg. Man snakker litt om forskjellige typer team-modus nå, kanskje vi er litt sånn, eller nå kanskje vi er litt sånn, men det er ikke noe som er veldig formelt rundt det.

Speaker 1 43:45

Det er nok mer et sånn bakgrunnsmaterial eller et sånn super aktivt bruk vil jeg si Dere, det er en ting i Team Topologies som jeg disk til. det er kanskje litt overdrevet, men det er my mye snakk om Conway's Law, også i Team Topologies.

Speaker 2 44:02

At akkurat kjønn bygges etter kommunikasjonsutgjørene Nettopp.

Speaker 1 44:05

Også snakker Team Topologies om noe som heter Reverse Conway og Inverse Conway Manure. De sier noe om, at hvis vi strukturerer våre team på en måte, som vi ønsker å oppnå vår mål, så klarer vi å komme tettere til det vi ønsker å ha i arkitekturen, at man kan på en måte designe den kommunikasjonsregionen. Men jeg er litt skeptisk i hvor mye gyldighet et sånt prinsipp har på generelt nivå Altid litt skeptisk, når man kommer med laws innenfor vår bransje.

Speaker 2 44:45

Jeg tenker jo at jeg har sett flere ganger at en vanlig konveyslo har noe for seg, at der hvor det ikke er match mellom organisasjonen og arkitekturen, så blir det et trøbbel, og at over tid så ender man opp med at man ser igjen organisasjonen i arkitekturen. Det har jeg opplevd før i gang, og så har jeg i hvert fall sett en gang hvor Inverse Conway funket sånn passelig. Det var i Finn. Der hadde man et stund et team eller en avdeling som eide annonser, og det var santlig vanskelig, fordi annonser var to ting. Det var å ta imot annonser som har betaling og regler og konsistent og sånne ting, og så var det det å vise fram annonser, som var skalering, det var milliarder av sidevisninger, og så var det vanskelig. Og så endte man opp med å lage to team Add in og add-out.

Speaker 2 45:42

Det førte til noe ganske bra, hvor de lagde et system for å ta imot annonser, og så gjorde de det ferdig, og som er det du interagerer med når du lager en annonse? Så sendte de en ferdig annonse, en versjon av den ferdige annonsen på Kafka til add-out. Så puttet de den inn i en helt annen type arkitektur til. Da var det caching og skalering og alt mulig, og så ble det vist frem på en skalerbar måte. Men da begynte man på en måte med å lage to team, og så er det noe til å ta en. Jeg var ikke så tøpp på, så du kan en. Jeg ligger det litt, siden det passer så godt med det jeg har lyst på. Skal være sånn, men det var i hvert fall ikke helt usann.

Speaker 1 46:19

Det var spennende. Vi er allerede på slutten av samtalen. Ja, har du noen key takeaways eller noe, kanskje en call to action, noe du ønsker at folk tar med seg?

Speaker 2 46:29

Det jeg tror er jo, at det er mye å lære fra softwareveien til dataveien, og jeg tror man må tenke på det med den modenheten at det det tok lang tid i softwareveien også. Så man må være tålmodig og tenke at dette skal løses mange steder, for at verktøyene skal lages, og der er det verktøyene kommer å bli gode til å bli lett for alle oss andre. Så man må nok være litt tålmodig, ja.

Speaker 1 46:53

Kall til tålmodighet kjempebra, Og så kanskje et kall for å høre på Absolutt vi har en.

Speaker 2 47:00

Ikke så lenge siden kom en veldig god episode om sikkerhet og hva som skjer hvis krigen kommer til Norge, og det anbefaler jeg. Jeg var mest tørt på episoden noen gang.

Speaker 1 47:09

Kjempespennende. Tusen takk for samtalen, Det var hyggelig.