Et mønster som ikke er sunt
I større IT- og transformasjonsprosjekter ser jeg et mønster som bekymrer meg.
De mest kompliserte tekniske beslutningene tas ofte uten at de mest erfarne utviklerne sitter ved bordet.
Ikke fordi de ikke finnes.
Ikke fordi de ikke vil bidra.
Men fordi de rett og slett ikke er invitert.
Arkitektur uten håndverk
Vi trenger arkitekter.
Vi trenger løsningsdesignere.
Vi trenger prosjektledere.
Men vi trenger også tung teknisk forankring i disse prosessene.
For ofte ser jeg:
- Arkitekter som ikke har skrevet kode på mange år – eller aldri har vært utviklere
- Løsningsdesignere som mangler praktisk erfaring med det som skal bygges
- Prosjektledere som styrer teknologivalg uten teknologiforståelse
Resultatet er det jeg kaller flytende arkitektur.
Arkitektur som ser riktig ut i presentasjoner.
Som inneholder alle buzzwords.
Som krysser av på alle rammeverk.
Men som ikke er forankret i teknisk gjennomførbarhet.
Når teori overstyrer realitet
Det er et sykdomstegn når komplekse tekniske systemer primært designes og styres av mennesker som ikke selv kunne implementert dem.
Ikke fordi alle må kode.
Men fordi noen i rommet bør forstå konsekvensene av de tekniske valgene som blir tatt.
Når tung teknisk erfaring ikke er representert, ser vi alt for ofte:
Overkompleksitet
Systemer designes for hypotetiske behov.
Manglende realisme
Estimater og roadmaps bygges uten forståelse for teknisk friksjon – fordi man aldri har kjent belastningen på kroppen. Vi som har implementert disse tingene over mange år, vet gjerne hvor skoen trykker og kan dytte prosessen i riktig retning.
Demotiverte utviklere
De som faktisk skal bygge systemet opplever at beslutninger tas over hodet på dem. Tidligere produksjonserfaring og lærdom blir ikke lyttet til. Og det finnes sjelden reelle arenaer hvor disse bekymringene blir tatt på alvor.
Hvorfor skjer dette?
Delvis fordi ledelse og arkitektur ofte sees på som et karrieresteg bort fra koding.
Men teknisk ledelse bør ikke være en flukt fra håndverket. Det bør være en videreføring av det.
Delvis fordi organisasjoner ønsker struktur, governance og “enterprise alignment”, og tror at avstand til detaljene gir bedre oversikt.
Delvis også fordi teknologer selv ikke alltid trener på å ta plass i beslutningsrom. Her må vi være ærlige: det er enklere å diskutere frustrasjon internt enn å løfte den konstruktivt. Teknologer må nok også se seg selv litt i speilet.
Men summen av dette er et gap.
De som forstår detaljene mister påvirkning.
De som styrer mister detaljforståelse.
Det gapet koster, det viser feilede IT prosjekter gang på gang.
En enkel analogi
Hvis du skal bygge et hus, forventer du at formannen vet hvordan man bygger ett hus.
Du ville reagert hvis alle som styrte hus-prosjektet aldri hadde slått inn en spiker – og heller ikke ønsket å høre på dem som faktisk kan det.
Likevel aksepterer vi i IT at styringen av komplekse tekniske systemer kan skje uten reell teknisk forankring.
Det burde vi ikke.
Dette handler ikke om roller – men om balanse
Dette er ikke et angrep på arkitekter, prosjektledere eller ledere. Alle disse rollene er nødvendige.
Men balansen har forskjøvet seg.
Når tunge tekniske arkitekter og erfarne utviklere ikke er en naturlig del av styrende fora, mister vi noe viktig:
Realismen.
Gjennomførbarheten.
Håndverket.
Teknisk ledelse er et håndverk – ikke bare en tittel.
De beste beslutningene jeg har vært med på, har blitt tatt i rom hvor minst én person kunne åpne en IDE og bevise poenget sitt. Var i ett intervju for ikke så lenge siden hvor det faktisk ble tatt negativt at jeg fremdeles er tungt involvert med utvikling.
Min påstand
Store tekniske prosjekter bør ledes av mennesker som faktisk forstår teknologien – på ordentlig.
Ikke nødvendigvis fordi de skal implementere alt selv.
Men fordi de vet hva det innebærer.
Mitt håp er at vi beveger oss mot en bransje hvor:
- Teknologer får plass i beslutningsrommet
- Teknisk erfaring verdsettes i strategiske roller
- Arkitektur forankres i faktisk gjennomføring
- Og hvor tung utviklerkompetanse ikke sees på som noe man “vokser fra”, men noe man bygger videre på
For når de som styrer teknologien ikke forstår den på håndverksnivå, får vi arkitektur som ser imponerende ut – men som ikke holder i praksis.
Og det er en kostnad vi ikke burde akseptere.
Litt om meg
Jeg har jobbet med programvareutvikling siden tidlig 90-tall. Fra 3D-motor i assembler på 68000-prosessorer, til moderne mikrotjenestearkitektur i .NET og skyplattformer.
Gjennom snart tre tiår har jeg hatt roller som utvikler, arkitekt, tech lead, CTO og prosjektleder. Jeg har migrert telekom-systemer under høyt tidspress, ledet utvikling av API-er med millioner av kall, satt opp systemarkitektur for retail-løsninger, og vært ansvarlig for produksjonsdrift der feil faktisk betyr noe.
Felles for det meste jeg har gjort er én ting:
Jeg har vært tett på koden.
Og har veldig ofte å vært med å rydde opp i komplekse tekniske prosjekter med dårlig styring.
Det er med det bakteppet jeg skriver dette.