CTO er én titel for tre meget forskellige job. I den første fase er CTO’en en bygger, der selv skriver det meste af koden. Når teamet vokser, bliver det en teamleder, der får andre til at levere. I et større softwarehus er rollen en strateg, der forbinder teknologi og forretning. Den samme person kan sjældent det hele, og en stærk CTO fra den ene fase kan være et dårligt valg i den anden. Derfor skal I først beskrive jeres fase og derefter søge den profil, der passer. Her er de tre profiler og en skabelon til stillingsbeskrivelsen.
Bygger: produktet skal findes
Der er få eller ingen udviklere, og det vigtigste er at få noget i hænderne på brugerne. Bygger-CTO’en koder det meste selv, vælger enkel teknologi og kan leve med, at noget skal laves om igen. Spørgsmålet er, om personen arbejder godt med stor usikkerhed.
Styrker: fart, bred teknisk erfaring, evnen til at skære fra.
Risiko: bygger alt selv, deler sjældent viden og får svært ved at slippe, når teamet vokser. Det forløb er beskrevet i stifteren som flaskehals.
Teamleder: produktet virker, og teamet vokser
Der er betalende kunder og et hold af udviklere. Nu handler det om at ansætte, indføre faste rutiner, fordele ansvar og levere stabilt. CTO’en koder lidt eller slet ikke og bruger tiden på mennesker og beslutninger.
Styrker: rekruttering, tydelige processer, evnen til at sige nej til salg og direktion med argumenter.
Risiko: en, der savner koden og griber ind i teamets arbejde, eller en, der indfører tunge processer fra en større virksomhed. Hvad skiftet kræver, står i fra fem til tyve udviklere.
Strateg: teknologi som del af forretningen
Virksomheden har flere teams, måske en VP Engineering (en leder, der har det daglige ansvar for udviklingsorganisationen) og et produkt med mange kunder. CTO’en deltager i ledelsens drøftelser, arbejder med store valg om platform, partnere og kundekrav og repræsenterer teknologien over for bestyrelse og større kunder.
Styrker: forretningsforståelse, forklaringsevne, langsigtede valg.
Risiko: en, der er for langt fra produktet til at se, hvad der faktisk foregår, eller som bruges til at repræsentere uden at beslutte. Rollefordelingen er beskrevet i CTO, VP Engineering og tech lead.
To særlige situationer
Der er to faser, som ikke passer ind i rækken.
Oprydningsfasen. Produktet er gammelt, og noget skal moderniseres, uden at kunderne mærker det. Her skal I bruge en med erfaring fra at forbedre noget eksisterende. En ren nybygger bliver utålmodig, og omskrivningen kommer til at ligne den eneste vej. Se skal produktet skrives om?.
Forløb med store kunder. Virksomheden skal op i en anden kundeliga, og spørgsmål om arkitektur, logning og oppetid fylder. Her tæller erfaringen med at svare kunderne meget højt. Se kravene fra store kunder.
Tre spørgsmål, der afgør profilen
Ledelsen bør kunne svare på disse, før stillingsopslaget skrives:
- Hvad er det største tekniske problem om et år, og er det at bygge, at organisere eller at vælge?
- Hvor mange mennesker skal personen lede, og skal der kodes?
- Hvor længe skal personen blive, før næste fase kræver noget andet?
Det tredje spørgsmål er ubehageligt og nyttigt. En CTO, der trives med at bygge fra bunden, kan være det rigtige valg i tre år og bagefter ønske sig noget andet. Tal åbent om det, før ansættelsen falder på plads. Det kan også vise, at en fractional CTO passer bedre i en periode, indtil I kender næste fase. Det spørgsmål er behandlet i fra fractional til fastansat CTO.
Skabelon til stillingsbeskrivelsen
En god stillingsbeskrivelse er kort og konkret. Brug felterne herunder, og lad ledelsen udfylde dem, før en rekrutteringspartner bliver involveret. Lønforhold er bevidst udeladt her.
- Formål: Hvorfor findes stillingen? Et par linjer om, hvad virksomheden skal kunne, når opgaven er løst.
- Fase: Bygger, teamleder eller strateg, og hvad der kendetegner produktet i dag.
- Ansvar: Tre til seks områder, fx arkitektur, udviklingsteam, leverandører, sikkerhed i produktet, kundekrav.
- Beslutningsret: Hvad afgør personen selv, hvad afgør ledelsen, og hvad afgøres i fællesskab?
- Mål for det første år: Tre mål, der kan ses udefra, fx hyppigere udgivelser eller en plan for teknisk gæld, som ledelsen har godkendt.
- Ledelse: Hvor mange refererer til personen, og hvem refererer personen selv til?
- Kodearbejde: Skal der kodes, og hvor meget?
- Rapportering: Hvad skal ledelsen se, og hvor ofte?
- Det, vi ikke forventer: Skriv fx, at driften ligger hos en leverandør, eller at sikkerhedsledelsen ligger et andet sted.
Det sidste felt er overset og nyttigt. Det viser en erfaren kandidat, at I har tænkt rollen igennem. Sikkerhedsledelse på virksomhedsniveau er en selvstændig opgave, og den skal ikke gemmes i en CTO’s stillingsbeskrivelse af vane.
Det skal I lade være med
- At kopiere en stillingsbeskrivelse fra en stor virksomhed · den beskriver en fase, I ikke er i.
- At søge en CTO, der både skal kode alt og lede alle · de to opgaver kan sjældent passes af én.
- At vælge efter navnet på tidligere arbejdspladser · spørg i stedet, hvad personen selv byggede eller ændrede dér.
Det skal I kræve af den eksterne
- ☐ En vurdering af jeres fase, begrundet ud fra produkt og team.
- ☐ Et udkast til stillingsbeskrivelsen med beslutningsret og mål.
- ☐ Et bud på, hvad der adskiller rigtige og forkerte kandidater hos jer.
- ☐ En klar anbefaling om, hvornår rollen bør gentænkes.
Senest gennemgået: november 2026.
Næste skridt
- Når rollen skal over til en fastansat CTO
- CTO-kandidaterne: sådan vurderer en ledelse uden teknisk baggrund
Læs også: Den nye CTO’s første 90 dage · Har vi brug for en CTO, eller er en lead developer nok?
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT