Når man arbejder med teknologi, bliver man ofte belønnet for at kende svaret. Som specialist er det en væsentlig del af ens værdi at kunne forstå et problem, gennemskue årsagen og finde den løsning, som andre måske ikke kan se. Det kan være alt fra en fejl i infrastrukturen til et arkitekturvalg, et sikkerhedsproblem eller spørgsmålet om, hvilken teknologisk platform der passer bedst til en bestemt opgave.
Det er en vigtig kompetence, og jeg tror ikke på ideen om, at teknisk forståelse pludselig bliver irrelevant, bare fordi man får mere ansvar. Tværtimod. Men jo længere man bevæger sig fra specialistrollen og ind i arkitektur, strategi og ledelse, desto færre problemer har ét entydigt teknisk korrekt svar. Konsekvenserne bliver større, perspektiverne flere, og antallet af mennesker, der ved mere end én selv på hvert enkelt fagområde, vokser.
På et tidspunkt ændrer ens vigtigste bidrag derfor karakter. Det bliver mindre afgørende at være den person, der hurtigst kan komme med svaret, og mere værdifuldt at kunne stille det spørgsmål, som får resten af rummet til at tænke bedre.
Fra ekspert til leder
Mange IT-ledere kommer naturligt fra specialistverdenen, og det giver god mening. Teknisk erfaring skaber troværdighed, gør det lettere at forstå konsekvenserne af beslutninger og hjælper en leder med at skelne mellem reelle problemer og teknisk teater. Men specialistrollen og lederrollen belønner ikke nødvendigvis den samme adfærd.
Som specialist kan det være en styrke hurtigt at genkende et mønster og forklare løsningen. Som leder kan præcis den samme refleks blive et problem, hvis den bliver brugt for tidligt og for ofte. Hvis lederen konsekvent er den første til at fortælle, hvordan et problem skal løses, lærer organisationen hurtigt, at der ikke er nogen grund til at tænke alt for længe selv. Svaret kommer alligevel fra toppen.
Det behøver ikke være klassisk micromanagement. Ofte kommer det fra de bedste intentioner. Lederen har erfaring, kan se en løsning og vil gerne hjælpe teamet videre. Men hjælp kan også skabe afhængighed, og en leder, der altid redder situationen, kan langsomt ende som organisationens foretrukne problemløser. Det lyder måske flatterende, indtil alle de vanskelige beslutninger begynder at stå i kø foran den samme person.
Så har man ikke skabt stærk ledelse. Man har skabt en meget erfaren flaskehals.
Hvilket problem prøver vi egentlig at løse?
Et af de spørgsmål, jeg finder mest værdifuldt i teknologi, er samtidig et af de mest enkle: Hvilket problem prøver vi egentlig at løse?
Det lyder banalt, men mange teknologiske diskussioner begynder langt senere i processen. Vi diskuterer Azure eller AWS, produkt A eller produkt B, Kubernetes eller noget simplere, build versus buy, cloud migration eller AI, før vi har sikret os, at vi faktisk er enige om problemet.
Det er risikabelt, fordi tekniske løsninger har en tendens til at få momentum. Når først organisationen er begyndt at tale om en bestemt platform eller teknologi, kan løsningen næsten blive problemet. Vi ender med at spørge, hvordan vi implementerer den, i stedet for hvorfor vi overhovedet har brug for den.
Nogle gange viser det sig ovenikøbet, at problemet slet ikke primært er teknisk. Vi forsøger måske at automatisere en proces, der burde fjernes, implementere et nyt system for at kompensere for uklare ansvarsområder eller købe endnu en platform, fordi den eksisterende bliver brugt dårligt. En stærk IT-leder behøver ikke nødvendigvis kende den bedste tekniske løsning, når diskussionen begynder, men vedkommende bør kunne få organisationen til at stoppe længe nok til at sikre, at den faktisk forsøger at løse det rigtige problem.
Hvad sker der, hvis vi ikke gør noget?
Teknologiverdenen er fuld af ting, vi kunne forbedre. Vi kan modernisere platformen, migrere til cloud, udskifte en applikation, automatisere en proces, opgradere infrastrukturen eller implementere endnu et værktøj. Der findes næsten altid en teknisk forbedring, der kan forsvares, hvis man ser isoleret på problemet.
Men ressourcer er begrænsede, og derfor synes jeg, spørgsmålet “Hvad sker der, hvis vi ikke gør noget?” er mindst lige så vigtigt som spørgsmålet om, hvad vi kunne gøre.
Nogle problemer bliver meget dyrere med tiden. Sikkerhedsrisici vokser, teknisk gæld akkumuleres, kompetencer forsvinder, og gamle platforme kan begynde at begrænse virksomhedens handlemuligheder. Andre problemer viser sig primært at være irritationer, som godt kan leve lidt længere uden store konsekvenser.
Den forskel betyder noget, fordi IT hverken har brug for ledere, der automatisk siger ja til enhver teknisk forbedring, eller ledere, der automatisk siger nej, fordi noget koster penge. Det har brug for ledere, der kan hjælpe organisationen med at forstå konsekvensen af både at handle og lade være. Det er i høj grad dér, teknologi begynder at blive strategi.
Hvad gør beslutningen ved vores handlefrihed?
En løsning kan være glimrende i dag og stadig blive dyr i morgen. Det er en af grundene til, at arkitektur interesserer mig så meget. Når vi træffer en teknologisk beslutning, køber vi ikke kun de muligheder, løsningen giver os her og nu. Vi accepterer samtidig de afhængigheder, kompetencebehov, integrationsmønstre og begrænsninger, der følger med.
Derfor synes jeg, at spørgsmålet “Hvad gør den her beslutning ved vores handlefrihed om tre eller fem år?” burde dukke op langt oftere i teknologiske diskussioner. Ikke fordi alt skal designes til en hypotetisk fremtid — overengineering kan være lige så skadeligt som kortsigtet tænkning — men fordi der er forskel på at vælge en pragmatisk løsning med åbne øjne og på at bygge sig ind i et hjørne uden at opdage det.
Den interessante arkitekturdiskussion handler derfor ikke kun om, hvorvidt løsningen virker. Den handler også om, hvilke fremtidige beslutninger vi samtidig gør lettere eller vanskeligere. Det er et perspektiv, som en IT-leder ikke behøver at eje alene, men vedkommende bør sikre, at nogen stiller spørgsmålet.
Hvad antager vi egentlig er sandt?
Mange dårlige beslutninger starter ikke med dårlige intentioner eller inkompetence. De starter med antagelser, som ingen fik udfordret.
Kunderne vil have denne funktion. Medarbejderne vil bruge systemet på denne måde. Leverandøren vil fortsat være konkurrencedygtig. Dataene er gode nok. Integrationen bliver forholdsvis simpel. Organisationen kan lære den nye teknologi. Projektet kan være færdigt på seks måneder.
Alt sammen kan være rigtigt. Men spørgsmålet er, hvad beslutningen bygger på, og hvad der skal være sandt, for at den fortsat giver mening.
Når man stiller det spørgsmål, bliver antagelserne synlige, og når de bliver synlige, kan de undersøges. Det gælder ikke kun teknologi. Hvis en leder mener, at et team ikke er klar til mere autonomi, hvad bygger den vurdering så på? Hvis organisationen mener, at medarbejderne har brug for tættere kontrol, er det så dokumenteret performance, eller er det lederens egen usikkerhed, der er blevet ophøjet til organisationsprincip?
Gode spørgsmål kan være ubehagelige, fordi de nogle gange afslører, at noget, vi behandlede som fakta, i virkeligheden bare var noget, vi alle havde vænnet os til at tro. Det er netop derfor, de er værdifulde.
Hvad ville få os til at ændre mening?
Jeg kan godt lide beslutninger, der kan udfordres. Ikke fordi organisationen skal genåbne enhver diskussion hver uge, men fordi beslutninger bliver farlige, når de langsomt udvikler sig fra valg til identitet.
Vi er en Microsoft-virksomhed. Vi er cloud-first. Vi bygger selv. Vi outsourcer altid den slags. Vi standardiserer på denne platform. Sådan gør vi her.
På et tidspunkt kan en beslutning, der oprindeligt var helt rationel, blive til en sandhed, som ingen længere undersøger. Derfor synes jeg, spørgsmålet “Hvad ville få os til at ændre mening?” er et stærkt værktøj. Hvis svaret reelt er “ingenting”, har vi måske ikke længere en strategi. Så har vi fået en trosretning.
En god beslutning bør kunne forklares ud fra de forudsætninger, den blev truffet på. Hvis de forudsætninger ændrer sig væsentligt, bør organisationen også kunne ændre beslutningen uden at opleve det som et nederlag. Det er ikke inkonsistens. Det er evnen til at lære.
“Det ved jeg ikke” kan være et stærkt svar
Der eksisterer stadig en forventning om, at lederen bør kunne svare, fordi ansvar og viden let bliver blandet sammen. Hvis man er ansvarlig for området, burde man vel også vide mest om det?
Det synes jeg er en farlig forventning, især i IT. Teknologilandskabet er simpelthen blevet for omfattende til, at én person realistisk kan være den dygtigste inden for cloud, security, data, AI, softwareudvikling, netværk, integration, enterprise architecture, compliance og resten af paletten samtidig.
En IT-leder, der forsøger at fremstå som ekspert på det hele, risikerer derfor enten at blive overfladisk eller begynde at bluffe. Ingen af delene skaber særlig stor tillid hos de specialister, der faktisk ved noget om områderne.
Jeg har langt mere respekt for en leder, der kan sige: “Det ved jeg ikke nok om. Hvem ved mest om det her, og hvad har I brug for fra mig for at kunne træffe en god beslutning?” Det er ikke et fravær af ledelse. Det kan tværtimod være meget præcis ledelse, fordi lederens opgave ikke nødvendigvis er selv at producere svaret. Opgaven er at sikre, at de rigtige mennesker, perspektiver og informationer bliver bragt sammen, så organisationen kan træffe den bedst mulige beslutning.
Teknisk troværdighed betyder stadig noget
Alt dette betyder ikke, at teknisk forståelse er ligegyldig. Tværtimod mener jeg, at teknisk troværdighed er en stor fordel for en IT-leder, fordi den gør det muligt at stille bedre spørgsmål.
Man behøver ikke være den dybeste specialist i rummet, men man skal forstå nok til at kunne se konsekvenserne, opdage når noget ikke hænger sammen og udfordre argumenter, der lyder mere overbevisende, end de faktisk er. Det er også forskellen på relevante spørgsmål og de mere generiske managementspørgsmål, som specialister hurtigt gennemskuer.
En leder med forståelse for arkitektur kan spørge til afhængigheder og handlefrihed. En leder med driftserfaring kan spørge til operational complexity og supportability. Forståelse for security gør det lettere at diskutere risiko, og forretningsforståelse gør det muligt at forbinde teknologi med økonomi og værdiskabelse. Dertil kommer den måske mest undervurderede dimension: Har organisationen overhovedet kompetencerne og kapaciteten til at drive det, vi er ved at bygge?
Det er dér, den tekniske baggrund bliver værdifuld på et andet niveau. Erfaringen bruges ikke nødvendigvis til selv at konfigurere løsningen. Den bruges til at gøre beslutningen bedre.
Spørgsmål kan også blive til micromanagement
Der findes naturligvis også en dårlig måde at stille spørgsmål på. Nogle ledere beskriver sig selv som nysgerrige, mens teamet oplever noget, der minder mere om et forhør. Hvorfor gjorde I sådan? Har I tænkt på det her? Hvad med dette? Hvorfor valgte I ikke den løsning, jeg selv havde i tankerne?
Spørgsmål kan sagtens være kontrol forklædt som coaching.
Forskellen ligger i, om spørgsmålet faktisk er åbent. Er lederen oprigtigt interesseret i teamets ræsonnement, eller bliver spørgsmålene bare brugt til gradvist at styre medarbejderne frem mod den beslutning, lederen allerede har truffet?
Medarbejdere opdager forskellen forholdsvis hurtigt. Hvis alle åbne spørgsmål ender med det samme forudbestemte svar, har man ikke skabt refleksion. Man har blot opfundet micromanagement med spørgsmålstegn.
God IT-ledelse kræver derfor også, at lederen kan acceptere et svar, som vedkommende ikke selv ville være kommet frem til, så længe beslutningen er velbegrundet og ligger inden for de rammer, teamet har fået. Ellers findes autonomien kun på PowerPoint.
De rigtige spørgsmål afhænger af situationen
Der findes selvfølgelig ikke en magisk liste med ti spørgsmål, som enhver IT-leder kan lære udenad og derefter betragte opgaven som løst. Det ville næsten være ironisk.
Pointen er ikke de præcise formuleringer, men måden at tænke på. I én situation kan det vigtigste spørgsmål være teknisk: Hvilken failure mode overser vi? I en anden er det strategisk: Hvilken forretningsmæssig evne forsøger vi egentlig at skabe? Det kan være organisatorisk: Har vi kompetencerne til at drive den løsning, vi er ved at vælge? Eller økonomisk: Hvilken omkostning har vi blot flyttet et andet sted hen?
Og nogle gange er det vigtigste spørgsmål langt mere menneskeligt: Hvem i rummet ser noget, vi andre ikke ser, men endnu ikke har sagt noget?
Det er derfor, god IT-ledelse ikke kan reduceres til hverken teknisk ekspertise eller en bestemt managementmetode. Den handler i høj grad om dømmekraft og om evnen til at opdage, hvilket perspektiv der mangler i samtalen.
Lederen behøver ikke være den klogeste i rummet
Når jeg tænker på stærk IT-ledelse, vender jeg derfor tilbage til en ret simpel idé: En leder behøver ikke være den person i rummet, der ved mest om alting, men vedkommende bør være med til at gøre rummet klogere.
Det kan ske ved at forbinde perspektiver, som normalt ikke mødes, ved at oversætte tekniske konsekvenser til forretningsmæssige konsekvenser eller ved at invitere den stille specialist ind i diskussionen, før alle andre har besluttet sig. Det kan ske ved at udfordre antagelser, der er blevet så etablerede, at ingen længere ser dem, eller ved at holde teamet fast på problemet, når diskussionen bliver forelsket i en bestemt løsning.
Det kræver teknisk forståelse, nysgerrighed og en vis ydmyghed. Nogle gange er det mest professionelle svar faktisk, at man ikke ved det endnu, men ved, hvem der skal involveres for at finde ud af det.
Bedre spørgsmål giver bedre beslutninger
Teknologi bevæger sig hurtigt, og det skaber et naturligt pres for også at træffe hurtige beslutninger. Men hastighed er kun værdifuld, hvis organisationen bevæger sig i en nogenlunde rigtig retning. Nogle af de mest værdifulde øjeblikke i IT-ledelse kan derfor være de situationer, hvor nogen stopper diskussionen længe nok til at stille et spørgsmål, som ændrer den.
Spørgsmålet gør ikke nødvendigvis beslutningen lettere. Måske gør det den tværtimod mere kompleks, fordi det afslører en risiko, en antagelse eller en konsekvens, som ingen havde tænkt på. Men hvis resultatet er en bedre beslutning, har spørgsmålet gjort sit arbejde.
For mig er det dér, forskellen mellem ekspertise og ledelse bliver interessant. Eksperten bliver ofte målt på kvaliteten af sine egne svar. Lederen bør i mindst lige så høj grad vurderes på kvaliteten af de beslutninger, organisationen er i stand til at træffe.
En god IT-leder behøver ikke have alle svarene. Men vedkommende skal være god til at stille de spørgsmål, der hjælper andre med at finde bedre svar.