En ekstern CTO og en lead developer kan være et stærkt makkerpar, når lead developeren beholder det daglige tekniske ansvar, og den eksterne tager ledelsen rundt om det. Det fungerer, hvis tre ting er aftalt fra begyndelsen: præsentationen for teamet, fordelingen af beslutninger og de opgaver, der bliver hos lead developeren. Springer I det over, får I to personer, der trækker hver sin vej, og et team, der ikke ved, hvem de skal spørge.
Tal med lead developeren først
Den første samtale skal ligge hos direktøren, længe før den eksterne møder teamet. En lead developer, der hører om en fractional CTO på et fællesmøde, vil med rimelighed opfatte det som mistillid. Fortæl åbent, hvorfor I gør det, hvad det skal løse, og hvad det betyder for personens job. Spørg, hvilke opgaver personen gerne vil af med, og hvilke vedkommende vil beholde.
Lad gerne lead developeren møde kandidaterne og have en stemme i valget. Det giver opbakning, og I får samtidig en faglig vurdering af, om den eksterne ved, hvad vedkommende taler om.
Vær forberedt på de spørgsmål, der kommer. Er jeg blevet degraderet? Skal jeg nu forklare mig for en anden? Får jeg stadig lov at bestemme over koden? Svarene skal være klare, og de skal stemme overens med det, I faktisk har aftalt.
Hvordan rollen præsenteres for teamet
Direktøren præsenterer den eksterne, helst sammen med lead developeren. Sig, hvad personen er her for, hvor meget vedkommende er i huset, hvad der ændrer sig, og hvad der forbliver det samme. Teamet vil også gerne vide, hvor længe det varer, og om deres job er i fare.
Den eksterne bør bruge de første uger på at lytte. Tal med hver udvikler. Spørg, hvad der virker, og hvad der ikke gør. Gode eksterne viser, at de har forstået produktet, før de foreslår noget. Hvad medarbejderne typisk spørger om, når en ekstern kommer ind, står der mere om på ekstern-it-ledelse.dk under medarbejdernes spørgsmål om den eksterne.
Hvem beslutter hvad
Skriv fordelingen ned på en side, og del den med teamet. Her er et eksempel, som I kan tilpasse:
Lead developeren beslutter: hvordan koden skrives, hvordan en opgave løses teknisk, hvem i teamet der tager hvad, og hvad der kræves ved kodegennemgang.
Den eksterne CTO beslutter eller indstiller: teknisk køreplan, valg af platforme og leverandører, prioritering af teknisk gæld mod nye funktioner, og hvilke kompetencer teamet skal have.
Direktøren beslutter: budget, ansættelser, hvad der lægges først af hensyn til forretningen, og hvad der siges til kunderne.
I fællesskab: større ændringer i arkitekturen, dvs. produktets grundlæggende opbygning. Lead developeren foreslår, den eksterne udfordrer, og hvis de to ikke bliver enige, afgør direktøren det ud fra forretningens behov.
Resten af mandatet, herunder adgange og plads i ledelsesmøder, står i mandat til den eksterne CTO.
Hvad den eksterne overlader til lead developeren
En ekstern, der er i huset nogle dage om måneden, kan ikke følge den daglige kode, og bør heller ikke prøve. Lead developeren er den, der kender detaljerne. Den eksterne skal derfor stille spørgsmål, frem for at give svar, i de sager, der ligger i teamet. Hvor meget en ekstern selv rører ved koden, er beskrevet i skriver en fractional CTO kode?.
Den eksterne kan til gengæld tage det, der fylder hos lead developeren uden at høre til i rollen: mødet med kunden, spørgeskemaerne, samtalen med leverandøren, indstillingen til ledelsen. Det frigør tid, og det er ofte den første gevinst, lead developeren mærker.
Lad også lead developeren stå forrest, når der er noget at vise. Præsenterer den eksterne teamets arbejde som sit eget på et ledelsesmøde, er tilliden væk. Inviter hellere lead developeren med og lad vedkommende fremlægge.
Faste møder
Makkerparret har brug for en fast rytme. Et ugentligt møde, også kort, om hvad der er på vej, hvad der bekymrer, og hvad der skal op i ledelsen. Tag uenighederne på det møde, så teamet ikke oplever dem først. Over for teamet skal de to stå sammen om beslutningen, når den er truffet.
Mange lead developere, der står foran mere ledelse, har glæde af en mentor, altså en erfaren person uden for det daglige arbejde, som de kan tale fortroligt med. Det er generel viden om rollen, og den rigtige mentor er ofte en, personen selv finder. Hvad der ellers skal til, står i artiklen om vejen til CTO.
Når der er modstand
Modstand er naturlig, og den er tit fornuftig. Lead developeren har set konsulenter komme og gå, og har måske erfaring for, at de efterlader flere dokumenter end resultater. Lad modstanden komme frem. Spørg, hvad der er bekymringen. Giv den eksterne en lille opgave, der løser et reelt problem for teamet, inden der ændres på noget.
Vedvarende modstand er et ledelsesspørgsmål. Direktøren må tage samtalen, enten med lead developeren eller med den eksterne. Hvad I gør, hvis samarbejdet ikke fungerer, står i artiklen om samarbejde, der går i stå.
Vil I have hjælp til at lægge samarbejdet til rette, kan et forløb hos Nielco IT starte med en gennemgang af produktet. Bagefter arbejder I fast sammen fra måned til måned med et aftalt antal timer, og kodearbejdet bliver hos jeres egne udviklere. 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 introducere den eksterne som “den, der skal rydde op” · I fornærmer det team, der har bygget produktet.
- At lade uenigheder gå gennem direktøren som ambassadør · de to skal først tale med hinanden.
- At holde fordelingen mundtlig · den bliver husket forskelligt.
Det skal I kræve af den eksterne
- ☐ En samtale med lead developeren, før noget bliver foreslået.
- ☐ En skriftlig fordeling af beslutningerne, som begge parter står ved.
- ☐ Respekt for teamets viden og åbenhed om, hvad vedkommende ikke ved.
- ☐ Synlig kredit til teamet, når noget lykkes.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Lead developeren er blevet flaskehalsen · Hvad laver en fractional CTO?
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
