En ledelse uden teknisk baggrund kan sjældent afgøre, om en kandidats arkitekturvalg er rigtige. Det kan den til gengæld undvære. I kan selv bedømme, om personen forklarer klart, spørger, før der svares, taler ærligt om egne fejl og kan oversætte teknik til tid, risiko og kunder. Det er de evner, I skal bruge hver uge, og de kan afprøves ved en samtale på et par timer. Fem prøver giver et godt grundlag, og den sidste prøve kommer efter valget, når I ser, hvad der ligger på bordet efter de første uger.
Prøve 1: Få teknisk gæld forklaret som en forretningsbeslutning
Teknisk gæld er kompromiser i koden, som gav fart dengang og nu bremser hver ændring. Bed kandidaten forklare begrebet, som om du skulle gengive det for bestyrelsen, og spørg derefter, hvornår det er fornuftigt at optage gælden med vilje.
Lyt efter tre ting. Bruger personen eksempler fra forretningen, fx en funktion, salget venter på? Kan vedkommende nævne en situation, hvor gæld var det rigtige valg? Og forklarer personen, hvem der skal træffe beslutningen? En god kandidat får emnet til at lyde som en prioritering, I selv kan tage stilling til. Får I en forelæsning om kodekvalitet, får I det samme på ledelsesmøderne. Vil I have noget at holde svaret op imod, står der mere i teknisk gæld forklaret for ledelsen.
Prøve 2: Giv kandidaten en tænkt case
Beskriv en situation, der ligner jeres. Et tænkt eksempel kan være dette: En stor kunde vil have en ny integration inden for tre måneder, udviklerne siger seks, og salgschefen har allerede sagt ja. Bed kandidaten sige højt, hvad der nu sker.
Det gode svar begynder med spørgsmål. Hvad består de seks måneder af? Hvad er kunden reelt ude efter? Hvad kan leveres først? Hvem talte med kunden? Derefter følger en vej frem med flere muligheder og en anbefaling. Vær opmærksom på, om kandidaten nævner udviklernes vurdering med respekt, og om løsningen også tager højde for dagen efter leverancen. Det svage svar er en hurtig dom over enten salgschefen eller udviklerne.
Prøve 3: Spørg, hvad der gik galt sidst
Bed om et konkret forløb, hvor kandidaten tog en beslutning, der viste sig at være forkert. Spørg, hvornår det blev tydeligt, hvem der fik det at vide, og hvad personen gør anderledes nu.
Kandidaten må gerne holde kundernes navne ude af det. Du skal høre en fortælling, hvor personen selv optræder, med en fejl, der koster noget. Den, der kun kan fortælle om andres fejl, vil gøre det samme hos jer, når noget går skævt i produktet.
Prøve 4: Spørg, hvad personen vil have at vide om jer
Afslut den første del af samtalen med at spørge: “Hvad vil du vide om os, før du anbefaler noget?” Spørgsmålene fortæller, hvad kandidaten tillægger vægt. Gode emner er forretningsmodellen, de vigtigste kunder, hvem der kender hvilke dele af koden, hvor det sidst gik galt, hvad I lovede sidst, og hvad I har lyst til at ændre.
Kommer der i stedet en bestemt teknologi eller en færdig metode, har kandidaten taget stilling, før vedkommende kender jer. Det samme gælder et tilbud om at bygge det hele om. Andre tegn af samme slags er samlet under advarselstegn hos en ekstern CTO.
Prøve 5: Lån et par tekniske øjne
Prøverne ovenfor viser, hvordan kandidaten leder og kommunikerer. Det faglige niveau kræver en anden fagperson. Har I en lead developer, altså den udvikler, teamet læner sig mest op ad, så lad vedkommende tale med kandidaten en times tid. Lead developeren skal være med på, at det er en samtale mellem kolleger, og at beslutningen ligger hos ledelsen.
Bed bagefter om svar på to spørgsmål. Lærte du noget? Ville du gå til denne person med et problem, du ikke kunne løse? Har I ingen udviklere, kan en betroet person fra jeres bestyrelse eller en bekendt i faget gøre det samme.
Tag også referencer, og spørg dem om noget konkret. Hvilke beslutninger stod personen for? Hvad skete der, da noget var svært? Hvordan sluttede samarbejdet?
Det, I skal have i hånden efter de første uger
Den endelige prøve er det skriftlige. Aftal på forhånd, hvad der skal foreligge, fx en liste over risici, et overblik over arkitekturen og en prioriteret plan. Læs det hele. Forstår du det uden tolk, og kan du se, hvad der skal besluttes? Hvad der er rimeligt at forvente, står i leverancerne efter 30 dage.
De generelle krav til en ekstern leder, fx uafhængighed og aftalen om afslutning, står under krav til den eksterne. Samtalen her lægger det oven på, som er særligt for et produkt.
Når valget står mellem få kandidater, kan I lægge prøverne ved siden af hinanden og tage beslutningen på det, I har hørt og læst. Overvejer I Nielco IT, omfatter opgaven ledelse, leverandører, teknologivalg og team, mens kodearbejdet ligger hos jeres egne udviklere eller leverandør. Hvad der påvirker prisen, og hvordan I får et tilbud, står under pris og tilbud.
Det skal I lade være med
- At vælge den, der lyder klogest · bedøm i stedet, om du forstod svaret og kan gengive det.
- At teste kandidaten med tekniske gåder · de siger meget lidt om ledelse af et produkt.
- At lade lead developeren træffe valget alene · den tekniske samtale er ét af flere bidrag.
- At springe referencerne over, fordi kemien var god · de ser det forløb, kandidaten selv har fortalt om, fra en anden stol.
Det skal I kræve af den eksterne
- ☐ En forklaring af teknisk gæld, som I selv kan gentage over for bestyrelsen.
- ☐ Spørgsmål om jeres forretning, før der kommer anbefalinger.
- ☐ Et ærligt eksempel på en egen fejl.
- ☐ En samtale med jeres udviklere, før aftalen indgås.
- ☐ Referencer, der kan fortælle om konkrete beslutninger.
- ☐ En skriftlig aftale om, hvad der foreligger efter de første uger.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Skriver en fractional CTO kode? · Når samarbejdet med en fractional CTO ikke virker
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
