Mislykket skalerbarhet, økende teknisk gjeld og samsvarsrisiko – dette er tegn på at det eldre systemet ditt må erstattes. Eldre systemer kan føles som pålitelige arbeidshester – driftssikre og velkjente – men under overflaten kan de stille og rolig akkumulere teknisk gjeld, bli flaskehalser for innovasjon og medføre betydelig samsvarsrisiko.
Tegnene er tydelige, og risikoene øker, men likevel utsetter du beslutningen kvartal etter kvartal. Som Mohan Sitaram påpeker i Fortidens nettverksspøkelser, «eldre systemer kan virke harmløse helt til de begynner å skape kaos». Hvis denne situasjonen høres kjent ut, opplever du det jeg kaller «migreringslammelse» – og du er ikke alene.
I denne artikkelen skal vi se nærmere på de fire største hindringene for migrering – perfeksjonisme, frykt for å mislykkes, endeløse utsettelser og jakten på konsensus – og presentere praktiske strategier for å overvinne dem. Hvis du har utsatt en kritisk migrering, vil denne veiledningen hjelpe deg med å bryte gjennom handlingslammelsen og ta avgjørende grep før kostnadene blir uoverkommelige.
De fire fellene ved migreringslammelse
1. «Neste kvartal»-syndromet
Vi kjenner alle denne: «Vi tar tak i det etter høytiden, neste finansieringsrunde eller en større lansering.» Sannheten er at det aldri finnes et perfekt tidspunkt for migrering. Å vente på dette mytiske perfekte øyeblikket skaper større problemer enn dem vi prøver å unngå.
Jeg jobbet nylig med en teknologidirektør som hadde planlagt å migrere betalingsbehandlingssystemet sitt i seks kvartaler på rad. «Vi gjør det rett etter Black Friday» ble til «La oss vente til etter valentinsdagssalget», og deretter «Kanskje etter sommersesongen». I mellomtiden ble de «midlertidige» løsningene deres permanent arkitektur, og den tekniske gjelden deres hopet seg opp raskere enn en kredittkortregning etter jul.
Vendepunktet kom da de begynte å følge med på «kostnaden ved å utsette» – ikke bare i kroner, men også når det gjaldt teamets moral og tapte muligheter. Hver mandag gikk de gjennom et enkelt kontrollpanel som viste hvor mange timer som ble brukt på nødrettinger, måltall for ytelsesforringelse og tid som gikk tapt på nye funksjoner. Da de så at teamet brukte over 20 % av tiden sin bare på å holde hjulene i gang, ble myten om det «perfekte tidspunktet» endelig knust.
Dette er det som skjer mens vi venter på neste kvartal:
- Mindre problemer vokser sammen til systemiske problemer
- Hurtigløsninger blir permanent arkitektur
- Teknisk gjeld akkumulerer eksponentielle renter
- Det «perfekte tidspunktet» blir stadig vanskeligere å finne
Sett opp tydelige utløsende kriterier som ikke kan forhandles bort. Denne teknologidirektøren innførte en enkel regel: Hvis nødrettinger utgjorde mer enn 20 % av utviklingstiden i to måneder på rad, skulle migrering automatisk bli et tema på styrenivå. Ikke mer venting på det perfekte øyeblikket – bare tydelige, datadrevne beslutninger.
2. Perfeksjonsvillfarelsen
«Hvis vi først skal gjøre dette, må vi gjøre det ordentlig.» Det høres fornuftig ut, ikke sant? Dette er perfeksjonisme forkledd som profesjonalitet. Det er stemmen som overbeviser deg om å utsette handling til du har den perfekte planen, det perfekte teamet og de perfekte omstendighetene.
En gang veiledet jeg en teknologidirektør i et voksende fintech-selskap som hadde den mest detaljerte migreringsplanen jeg noen gang hadde sett. Den inneholdt omfattende arkitekturdiagrammer, uttømmende risikovurderinger, perfekte beredskapsplaner – alt du kan tenke deg. Det eneste problemet var at den hadde ligget i Confluence i 18 måneder, fått jevnlige oppdateringer, men aldri blitt satt ut i livet.
Gjennombruddet kom som følge av en uventet krise: Konkurrenten deres lanserte en funksjon som det burde ha tatt uker å kopiere, men teamet deres anslo at det ville ta flere måneder på grunn av begrensningene i det eldre systemet. Da innså hun at en god nok migrering som gjennomføres i dag, er bedre enn en perfekt migrering som aldri starter.
De forkastet den enorme planen og startet med ett enkelt spørsmål: «Hva er den minste delen vi kan migrere som ville gjort en reell forskjell?» De identifiserte varslingstjenesten sin – en håndterbar komponent med tydelige avgrensninger.
Var migreringsplanen perfekt? Nei. Møtte de på noen utfordringer? Ja. Men tre måneder senere hadde de sin første tjeneste kjørende på moderne infrastruktur, og enda viktigere: De hadde fått fremdrift.
3. Karrierebevaringsfellen
La oss være ærlige: Mislykkede migreringer har satt en stopper for karrierer. Denne frykten får mange teknologidirektører til å velge den djevelen de kjenner, fremfor den de ikke kjenner. Tross alt har ingen fått sparken for å opprettholde status quo … før det skjedde.
En kollega av meg fikk erfare dette på den harde måten. Han var teknologidirektør for en vellykket e-handelsplattform som kjørte på et system han selv hadde utformet flere år tidligere. «Det er stabilt», sa han under våre samtaler. «Hvorfor risikere å lage bølger?» Han var respektert i selskapet og fikk ros for å holde driften i gang uten problemer.
Så kom Black Friday. Ordrebehandlingssystemet deres, som hadde vært «stabilt» i årevis, klarte ikke å håndtere de nye belastningsmønstrene. Driftsavbruddet varte i seks timer – en evighet i e-handelssammenheng. Styrets første spørsmål handlet ikke om driftsavbruddet, men om hvorfor de ikke hadde blitt advart om systemets begrensninger.
Ironisk nok? Ved å unngå karriererisikoen ved en mislykket migrering sikrer vi ofte utfallet vi prøver å forhindre. Systemer eldes ikke som god vin.
4. Konsensuslammelsen
«Vi trenger alles støtte før vi går videre.» Selv om støtte fra interessentene er viktig, er det en oppskrift på handlingslammelse å vente på full enighet. Ulike team har ulike prioriteringer, og det vil alltid være noen som har en grunn til å vente.
Jeg husker teknologisjefen i et selskap som utviklet medisinsk programvare, og som var fast bestemt på å gjøre ting «på riktig måte» – ved å få støtte fra alle avdelingslederne før migreringen startet. Økonomiavdelingen var bekymret for kostnadene, salgsavdelingen trengte garantier for null nedetid, driftsavdelingen ønsket å vente til etter høysesongen, og juridisk avdeling hadde bekymringer rundt overholdelse av regelverket under overgangen.
Seks måneder med møter senere var de fortsatt tilbake ved utgangspunktet. Vendepunktet kom da han endret tilnærming fra å søke enstemmig godkjenning til å bygge en koalisjon av de villige. Han identifiserte teamene som var mest påvirket av begrensningene i det eldre systemet – i dette tilfellet avdelingene for pasienttimeavtaler og fakturering – og gjorde dem til pådrivere for migreringen.
I stedet for å forsøke å håndtere alles bekymringer på forhånd gjennomførte de en pilotmigrering med bare disse to avdelingene. Denne fokuserte innsatsen lyktes med det flere måneder med møter ikke hadde klart: Den viste konkrete fordeler som overbeviste andre interessenter om å bli med.
Bli fri: Beslutningsrammeverket
Det er her teorien møter praksis. Etter å ha sett utallige teknologisjefer navigere i disse utfordringene har jeg utviklet et rammeverk som bryter gjennom de psykologiske barrierene og fører deg mot handling. La oss gå gjennom hvert trinn med virkelige eksempler på hvordan vellykkede teknologiledere har brukt dem.
Have an account? Log In
Trinn 1: Erkjenn fordommene dine
Begynn med å identifisere hvilke av mønstrene ovenfor som påvirker beslutningene dine. Dette handler om en vellykket teknologisjef som en gang sa til meg: «Det vanskeligste var ikke å identifisere de tekniske utfordringene – det var å innrømme at frykten min var den største hindringen.» Hun hadde utsatt en kritisk migrering på grunn av en tidligere mislykket migrering i et annet selskap. Først da hun eksplisitt erkjente denne forutinntattheten, kunne hun vurdere den nåværende situasjonen objektivt.
Begynn med å stille deg selv disse spørsmålene:
- Unngår jeg denne migreringen på grunn av tidligere erfaringer?
- Har jeg solgt inn stabiliteten til det nåværende systemet vårt for sterkt til interessentene?
- Lar jeg det perfekte bli det godes fiende?
Dette handler ikke om å plassere skyld – det handler om å fjerne mentale hindringer.
Det vanskeligste ved en migrering er ikke den tekniske utfordringen – det er å bestemme seg for å begynne.
Trinn 2: Omformuler spørsmålet
«Bør vi migrere?» er feil spørsmål. Det plasserer deg i en ja-eller-nei-tankegang der innsatsen føles umulig høy. Jeg lærte dette av teknologisjefen i en handelsplattform, som strevde med beslutningen helt til de endret innfallsvinkelen fullstendig.
I stedet for det overveldende spørsmålet «Bør vi migrere?» begynte de å stille mer presise spørsmål som krevde konkrete svar:
«Hva er den reelle kostnaden ved å vente enda et kvartal?»
De beregnet ikke bare kostnadene for drift, men også utviklertimer brukt på midlertidige løsninger, funksjoner de ikke kunne lansere, og markedsmuligheter de gikk glipp av. Da de så at de betalte 50 000 dollar i måneden bare for å opprettholde status quo, kom beslutningsklarheten naturlig.
«Hvis jeg ble ansatt i dag, hva ville jeg gjort?»
Denne mentale øvelsen frigjorde dem fra tyngden av tidligere beslutninger. «Det var befriende», fortalte de meg. «Da jeg så på teknologistakken vår slik en nyansatt ville gjort, var veien videre åpenbar. Ingen ville valgt å bygge det vi vedlikeholdt.»
«Bevarer jeg stabilitet eller bevarer jeg problemer?»
Dette spørsmålet avslørte at det «stabile» systemet deres var et korthus som krevde stadig mer heroisk innsats. Det de kalte stabilitet, var bare velkjent kaos.
Steg 3: Metoden med to lister
En teknologidirektør i et finansteknologiselskap jeg jobbet med, satt fast i analyseparalyse helt til vi prøvde denne enkle, men kraftfulle øvelsen. Vi tok en tavle og delte den inn i to kolonner:
"Problemer som vil bli verre av å vente:"
- De mest erfarne utviklerne deres ble frustrerte og kom med antydninger om at de ville slutte
- Teknisk gjeld ble stadig større fra måned til måned
- Sikkerhetsoppdateringer ble stadig mer kompliserte å implementere
- Hver nye funksjon tok lengre tid å implementere enn den forrige
- Kundeklagene på systemets hastighet økte
"Problemer som vil bli enklere av å vente:"
- Migreringsverktøyene kunne bli ytterligere forbedret
- Teamet kunne få mer erfaring med ny teknologi
- Kunne spare mer av budsjettet til prosjektet
Da vi så på disse listene side om side, ble beslutningen plutselig klar. Kolonnen for «å vente» besto hovedsakelig av hypotetiske fordeler, mens kolonnen for «å handle nå» var fylt med konkrete problemer som stadig ble større.
Ta beslutningen: En virkelighetsbasert tilnærming
70 %-regelen
Du trenger ikke 100 % sikkerhet – det lærte jeg av en teknologidirektør i et helseteknologiselskap som ventet for lenge på «full klarhet». Etter deres tredje kvartal med forsinkelser lanserte en konkurrent tilsvarende funksjonalitet på halvparten av tiden fordi de forsto noe avgjørende: Du trenger ikke alle svarene; du trenger nok svar.
Slik ser «nok» ut:
70 % tillit til vurderingen din
«Jeg hadde et komplekst regneark som fulgte opp alle mulige risikoer», fortalte hun meg, «men mentoren min stilte meg et enkelt spørsmål: 'Hvis du måtte ta denne beslutningen basert på det du vet akkurat nå, ville du følt at du hadde mer rett enn feil?' Da innså jeg at jeg gjemte meg bak analysen.»
70 % av de viktigste interessentene er med
Legg merke til at det ikke betyr alle – det er den kritiske massen som trengs for å skape fremdrift. En teknologidirektør i detaljhandelen delte strategien sin: «Jeg kartla interessentenes bekymringer i en enkel matrise: høy påvirkning/lav påvirkning, støttende/motvillige. Da gruppen med høy påvirkning og en støttende holdning var samkjørt, var det nok til å starte. De andre ble med da de så de første resultatene.»
70 % av de kritiske spørsmålene er besvart
Spørsmålene du ikke kan svare på nå, blir tydeligere når du først beveger deg fremover. Ett team opprettet tre kategorier for spørsmål:
- Må besvares før oppstart
- Kan besvares underveis
- Fint å ha, men ikke avgjørende
Å komme opp i 100 % er ofte dyrere enn å håndtere de 30 % med usikkerhet under gjennomføringen. Jobben din er ikke å eliminere all risiko – den er å gjøre risikoen håndterbar.
Reversibilitetstesten
En teknologidirektør i et spillselskap lærte meg denne tilnærmingen. For hvert større beslutningspunkt stiller du tre spørsmål:
Kan denne beslutningen reverseres ved behov?
De opprettet «fluktveier» – tydelig dokumenterte veier tilbake til den tidligere tilstanden på hvert trinn i migreringen. «Det at vi hadde en vei tilbake, gjorde oss modigere når vi skulle gå videre», forklarte han.
Hva er reserveposisjonen vår?
De beholdt det gamle systemet i skrivebeskyttet modus dobbelt så lenge som de mente var nødvendig. Dyrt? Ja, men det gjorde at de kunne sove godt om natten.
Hva er den faktiske kostnaden ved å ta feil?
Ikke det katastrofale scenarioet der alt svikter, som angsten din forestiller seg, men det realistiske verst tenkelige utfallet. Vanligvis er det langt mer håndterbart enn du frykter.
De første 30 dagene
More Articles
Uke 1: Beslutningssprint
- Mandag: Samle inn kritiske nøkkeltall
- Tirsdag: Intervjuer med interessenter
- Onsdag: Risikovurdering
- Torsdag: Første utkast til plan
- Fredag: Beslutningspunkt
Uke 2-3: Bygge fremdrift
- Kunngjør beslutningen tydelig
- Opprett et kommandosenter for migreringen
- Begynn med små, konkrete tiltak
- Feir tidlige seire
Uke 4: Oppstart av gjennomføringen
- Start pilotprosjektet
- Etabler tilbakemeldingssløyfer
- Sett opp måleparametere for fremdriften
- Planlegg regelmessige statuskontroller
Konklusjonen
Den vanskeligste delen av migreringen er ikke den tekniske utfordringen – det er å bestemme seg for å begynne. De psykologiske hindringene for migrering veier ofte tyngre enn de tekniske. Frykt for å mislykkes, perfeksjonisme, ønsket om konsensus og fristelsen ved «neste kvartal» kan lamme selv de mest erfarne teknologilederne.
Men vi har også sett hvordan vellykkede CTO-er bryter gjennom disse hindringene. De gjør det ikke ved å eliminere all risiko eller oppnå perfekt konsensus, men ved å:
- Forvandle vage bekymringer til målbare måleparametere
- Bryte ned tilsynelatende monolittiske beslutninger i mindre, reversible trinn
- Bygge koalisjoner i stedet for å vente på enstemmighet
- Bruke 70 %-regelen til å gå videre med «nok» i stedet for «alt»
Kanskje viktigst av alt har vi lært at migreringsbeslutninger ikke tas i enkeltstående, dramatiske øyeblikk. De er resultatet av systematiske rammeverk, tydelige utløsere og en ærlig egenvurdering.
De mest vellykkede migreringene jeg har sett, var ikke de som hadde perfekte planer – det var de der lederne forsto og håndterte sin egen psykologi like nøye som systemene sine.
Abonner på nyhetsbrevet til The CTO Club for flere innsikter om programvaremigrering.
