Kvalitet og eierskap: You Build It, You Run It

I del 1 (Rammeverket) og del 2 (Kommunikasjon) etablerte vi at ledelse handler om støtte, tillit og åpne tilbakemeldingssløyfer. Den tredje pilar i min ledelsesfilosofi handler om hvordan vi bygger programvare: Ved å gi ingeniørteam helhetlig eierskap til løsningene de skaper.

Det klassiske mottoet fra Amazon-grunnlegger Werner Vogels oppsummerer dette best: «You build it, you run it.»

🚫 Problemet med tradisjonelle avleveringer

I eldre organisasjonsmodeller var utviklingsløpet oppstykket i vanntette skott:

Utvikler-team        QA / Test-team         Drift / Ops-team
[ Skriver kode ]  ──> [ Manuell test ]  ──> [ Produksjonssett ] ──> 💥 Produksjonsfeil

Når utviklere vet at et annet team skal teste koden, og et tredje team har ansvaret når systemet krasjer klokken 02:00 om natten, oppstår et utilsiktet incitamentsproblem:

• Utviklere mister følelsen av konsekvens og eierskap for koden de leverer.
• Kvalitet blir sett på som noe man “legger til på slutten” i stedet for en integrert del av utviklingen.
• Avlevering mellom team skaper lange ventetider, misforståelser og økt risiko ved produksjonssetting.

🛠️ Hva “You Build It, You Run It” betyr i praksis

Helhetlig eierskap betyr at det samme tverrfaglige teamet som designer og koder en tjeneste, også har ansvaret for å:

1. Automatisere testing: Skrive automatiske enhetstester, integrasjonstester og ende-til-ende tester som kjøres ved hver Pull Request.
2. Definere infrastruktur: Deklarere sin egen infrastruktur via Infrastructure as Code (f.eks. Terraform eller Bicep).
3. Overvåke ytelse og tilgjengelighet: Sette opp metrikker, dashboard og alarmer i overvåkningsverktøy (f.eks. Datadog eller Prometheus).
4. Håndtere produksjonshendelser: Være en del av roterende vaktordninger (on-call) for å løse hendelser i produksjon.

Når en utvikler vet at en bugs i koden kan føre til et varsel på egen telefon nattetid, endres kvalitetstenkningen umiddelbart. Kode skrives mer robust, feilhåndtering blir bedre, og testdekningen øker naturlig.

🚀 Plattformteknologi som muliggjører (Platform Engineering)

En vanlig innvending mot helhetlig eierskap er: «Kan vi forvente at alle applikasjonsutviklere også skal være eksperter på Kubernetes, sky-nettverk og krypto-nøkler?»

Svaret er et tydelig nei.

Det er her Platform Engineering og Internal Developer Platforms (IDP) kommer inn:

+-------------------------------------------------------------------+
|                  Produkt- og applikasjonsteam                     |
|            (Eier forretningslogikk & YBIYRI-ansvar)              |
+-------------------------------------------------------------------+
                                   │
              Bruker selvbetjente "Golden Paths" (APIer, maler)
                                   │
                                   ▼
+-------------------------------------------------------------------+
|                     Plattform-ingeniørteam                        |
|   (Leverer trygge kjerne-komponenter, CI/CD-maler, K8s-kluster)    |
+-------------------------------------------------------------------+

Plattformteamet bygger «Golden Paths» – ferdige, trygge maler og selvbetjente verktøy for CI/CD, klyngeoppsett og overvåkning. Utviklerne får friheten til å bygge og drifte, uten å måtte finne opp hjulet på nytt hver gang.

📈 Hvordan måle kvalitet og eierskap?

For å sikre at helhetlig eierskap gir ønsket effekt, måles fremdrift på faktiske utfall:

• Deployment Frequency (Utrullingshyppighet): Hvor ofte leverer teamet trygge endringer til produksjon?
• Lead Time for Changes: Hvor lang tid tar det fra kode er committed til den kjører i produksjon?
• Mean Time to Restore (MTTR): Hvor raskt kan teamet gjenopprette normal drift ved en produksjonsfeil?
• Change Failure Rate: Hvor stor andel av produksjonssettinger fører til feil som krever utbedring?

🚀 Oppsummering

Når ingeniører gis tillit og verktøy til å eie hele livssyklusen til sine applikasjoner, stiger både kodekvaliteten og jobbtrivselen. Kvalitet er ikke en fase; det er en kontinuerlig vane.

Neste artikkel i serien tar for seg Balansen mellom teknisk dybde og forretningsverdi.