CTO as a Service

Ansættelse af de første udviklere

En hånd løfter en ny bærbar med lukket låg op af kassen på et tomt bord i et lille softwarehus, med mus og oplader i emballagen ved siden af

De første udviklere former mere end koden. De sætter vanerne for, hvordan der arbejdes, dokumenteres og bliver sagt fra, og de vaner lever videre, længe efter teamet er vokset. Kan ingen i ledelsen vurdere kode, må vurderingen tilrettelægges anderledes. Beskriv opgaven før personen, lån en fagperson til den tekniske del af samtalen, og brug en prøveopgave, der ligner det rigtige arbejde. Resten kan en stifter eller direktør godt selv vurdere, for meget af det, der afgør en første ansættelse, handler om dømmekraft og samarbejde.

Beskriv opgaven, før I beskriver personen

Et jobopslag med en lang liste af teknologier siger meget lidt om, hvad personen skal lave. Skriv i stedet tre afsnit til jer selv, inden opslaget formuleres:

  • Hvad skal personen have fået i drift efter det første halve år?
  • Overtager personen noget eksisterende, eller bygges der fra bunden?
  • Hvem skal personen arbejde sammen med, og hvem tager beslutningerne om produktet?

Svarene ændrer profilen. Skal en leverandørs kode overtages, er evnen til at læse og forstå andres arbejde vigtigere end lysten til at bygge nyt. Skal der bygges fra bunden, tæller evnen til at træffe enkle valg og skære fra. Står I foran netop det valg, kan freelancer, bureau eller eget team hjælpe med at afgøre, om en ansættelse overhovedet er næste skridt.

Den profil, der bærer en første ansættelse

Den første udvikler arbejder uden kolleger, der fanger fejlene. Derfor giver det sjældent mening at begynde med en nyuddannet, uanset hvor dygtig personen er. En ung udvikler lærer af at sidde ved siden af en erfaren, og den erfarne findes ikke endnu.

Søg efter en, der har prøvet at leve med sine egne valg. Det ser I på disse tegn:

  • Personen har haft ansvar for noget, der kørte hos rigtige brugere, og har rettet det, da det gik galt.
  • Personen kan forklare et teknisk valg i almindeligt sprog og nævne, hvad der blev fravalgt.
  • Personen spørger til jeres brugere, før personen spørger til jeres teknologi.
  • Personen kan fortælle om noget, der mislykkedes, uden at give andre skylden.

En stærk specialist inden for ét snævert område kan være det forkerte valg på dette tidspunkt. I har brug for en, der kan tage det hele et stykke af vejen.

Den tekniske samtale, når ingen af jer kan kode

Lån en fagperson. En ekstern CTO, en erfaren udvikler, I har tillid til, eller en bekendt i faget kan løse opgaven, så længe personen er uden interesse i udfaldet. Personen deltager i den tekniske del og giver bagefter en vurdering med begrundelse. Bed om begrundelsen, for en dom uden argumenter kan I ikke bruge til noget.

Ledelsen kan selv stille de spørgsmål, der siger noget om arbejdsform:

  1. Fortæl om noget, du har bygget, som stadig kører. Hvad ville du gøre anderledes i dag?
  2. Hvad er den alvorligste fejl, du har sendt i drift, og hvad skete der derefter?
  3. Forklar for mig, som ikke koder, hvad du ville bygge først hos os, og hvorfor.
  4. Hvordan siger du til din leder, at en opgave bliver forsinket?

Lyt efter, om svarene er konkrete. Generelle vendinger om bedste praksis uden et eksempel fra personens eget arbejde er et svagt tegn.

Prøveopgaven skal ligne arbejdet

En god prøveopgave er kort, afgrænset og tæt på det, personen faktisk skal lave. Den må aldrig være et stykke af jeres rigtige produkt, som I får lavet uden at betale for det. Aftal en tidsramme på forhånd, og betal gerne for tiden, så dygtige folk med et job i forvejen også har lyst til at deltage.

Gennemgangen bagefter er det vigtigste. Lad kandidaten vise løsningen til fagpersonen og forklare, hvad der blev udeladt, og hvorfor. Bed om en lille ændring undervejs. Så ser I, om personen forstår det, der er afleveret.

Spørg også til AI-værktøjer. De fleste udviklere bruger dem, og et forbud i prøveopgaven tester noget, I ikke skal bruge. Lad kandidaten bruge dem og forklare, hvad værktøjet foreslog, og hvad der blev rettet. Hvilke rammer teamet skal arbejde under, står i AI-kodeassistenter i udviklingsteamet.

Det, kandidaten vurderer hos jer

Dygtige udviklere ser også på jer. De spørger, hvem der bestemmer over produktet, hvor pengene kommer fra, og om de får indflydelse på de tekniske valg. Har I klare svar, og kan I vise en kunde, der venter på produktet, står I stærkt. En uklar retning og en stifter, der vil godkende hver detalje, skræmmer de bedste væk.

Fortæl også ærligt om det uløste. En kandidat, der opdager gælden i første uge, mister tilliden hurtigere end en, der hørte om den til samtalen.

Det skal være klart før første arbejdsdag

Kode, cloudkonti og domæner skal stå i virksomhedens navn, før den første linje skrives. Lad aldrig en ny medarbejder oprette kodearkivet på sin private konto, heller ikke for at komme hurtigt i gang. Kontrollisten finder I under teknisk ejerskab af kode og konti. Er der freelancere ved siden af den ansatte, er rettighederne et særskilt spørgsmål, se hvem ejer koden.

Aftal også, hvordan I følger arbejdet. Allerede fra første måned bør der være en kørende version, I selv kan prøve hver uge. Fremgangsmåden står i sådan følger I fremdriften, og når den næste udvikler kommer til, er det tid til en udviklingsproces for et lille team.

Det skal I lade være med

  • At ansætte efter en liste af teknologier · opgaven afgør profilen, og teknologi kan læres af den rigtige person.
  • At lade den første medarbejder vurdere sine egne kommende kolleger alene · en fagperson udefra giver et andet blik i de første ansættelser.
  • At bruge prøveopgaven til at få løst rigtige opgaver · det koster jer de bedste kandidater og et godt ry i faget.
  • At vente med ejerskabet · konti, der først oprettes privat, er besværlige at flytte senere.

Det skal I kræve af den eksterne

  • ☐ En kort beskrivelse af opgaven, skrevet før jobopslaget.
  • ☐ En profil, der siger, hvad der er nødvendigt, og hvad der kan læres.
  • ☐ En prøveopgave med tidsramme, som ligner det rigtige arbejde.
  • ☐ Deltagelse i den tekniske samtale og en skriftlig begrundelse for vurderingen.
  • ☐ En plan for de første uger med klare forventninger til begge parter.
  • ☐ Forklaringer, som ledelsen kan forstå uden fagord.

Senest gennemgået: november 2026.

Næste skridt

Læs også: Hvornår skal I have den første teamleder? · Hvilken CTO passer til jeres fase?

→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Mangler I en CTO?

Fortæl kort, hvad der fylder: produktet, teamet, leverandøren eller en kunde, der stiller krav. Rådgivningen er uvildig og uden bindinger til leverandører, så svaret tager udgangspunkt i jeres situation.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.