Når alt går gennem én person, er det sjældent personens skyld. En lead developer er den erfarne udvikler, der leder det tekniske arbejde i teamet, og i mange softwarevirksomheder er rollen vokset, uden at nogen har besluttet det. Personen skal både kode, gennemgå de andres kode, træffe de tekniske valg, hjælpe support og svare kunderne. Årsagen er organisatorisk, og derfor er det ledelsens opgave at rette den. Her er tegnene, en måde at måle det på, og de opgaver, der kan flyttes.
Sådan ser det ud i hverdagen
Tegnene ligner hinanden fra virksomhed til virksomhed:
- Ændringer ligger og venter på den samme persons godkendelse.
- Udviklerne spørger, før de beslutter noget, også i små sager.
- Sælgeren ringer direkte til lead developeren, når en kunde stiller et svært spørgsmål.
- Nedbrud og alvorlige fejl ender hos samme person, også om aftenen.
- Lead developerens egne opgaver er dem, der oftest bliver forsinket.
- Ferien bliver planlagt ud fra, hvad der kan vente, og den holdes med telefonen tændt.
- Dygtige udviklere begynder at klage over, at de ikke får lov at tage ansvar.
To af tegnene kan man leve med i en periode. Fire eller flere betyder, at virksomheden har bygget sig ind i en afhængighed.
Hvorfor det sker
Lead developeren blev typisk den, alle gik til, fordi vedkommende var dygtigst og kendte koden bedst. Det var en god løsning, da teamet var lille. Når teamet vokser, stiger antallet af spørgsmål, og den enkelte kan ikke længere nå dem.
Samtidig mangler der ofte en anden person til de opgaver, der ikke handler om kode. Ingen ejer køreplanen, altså planen for, hvad der skal bygges og i hvilken rækkefølge. Ingen ejer leverandørerne, ansættelserne eller samtalen med salg. Så falder de opgaver ned hos den, der i forvejen svarer på alt. Forskellen på at lede koden og at lede teknologien for forretningen er beskrevet i artiklen om CTO eller lead developer.
Flaskehalsen er også sværere at se indefra, end man tror. En lead developer, der er stolt af sit arbejde, siger sjældent fra, og direktøren oplever, at tingene bliver løst. Prisen viser sig andre steder: i forsinkelser, i et team, der ikke vokser fagligt, og i en risiko, som ingen har skrevet ned.
Tæl en almindelig uge
Før I ændrer noget, så få et billede af, hvor tiden går. Bed lead developeren skrive ned i en almindelig uge, hvad tiden bliver brugt på, fordelt på fem bunker:
- Egen kode. Det, personen selv bygger.
- Gennemgang og hjælp. Andres kode, spørgsmål fra kollegaer.
- Tekniske beslutninger. Arkitektur, teknologivalg, prioritering af gæld.
- Kunder og salg. Møder, spørgeskemaer, tilbud og supportsager.
- Ledelse. Personalesamtaler, ansættelser, leverandører, planlægning.
Gør det som en fælles undersøgelse, så det ikke opleves som kontrol. Resultatet er næsten altid en overraskelse, også for lead developeren selv. Tallene giver jer et grundlag for samtalen. Spørg derefter personen, hvilke bunker vedkommende helst vil beholde. Svaret afgør meget af det videre arbejde.
Hvad der kan flyttes
Gennemgang af kode kan fordeles, så flere må godkende inden for hver sit område. Det kræver, at I accepterer, at nogle beslutninger bliver lidt anderledes, end lead developeren ville have truffet dem. Hvordan aftalerne kan se ud, står i artiklen om udviklingsproces.
Vagt og fejlrettelser kan gå på omgang, når der er skrevet ned, hvad man gør. Det rammer også den viden, kun én har, se når én udvikler kender hele koden.
Personaleopgaver kan flyttes til en teamleder, når teamet er stort nok til det. Læs hvornår I skal have den første teamleder.
Kundesager kan samles et fast sted, så sælgeren ikke ringer direkte. En enkel regel om, hvem der modtager spørgsmålene, og hvornår de bliver besvaret, flytter mere, end man skulle tro.
Nogle opgaver kan ikke flyttes internt, fordi ingen andre har erfaringen. Det gælder typisk planen for produktets teknik, leverandørerne, de store teknologivalg og samtalen med ledelsen. Her er der tre veje. Lead developeren kan vokse ind i opgaven, I kan ansætte, eller I kan hente en ekstern ind.
Hvad en ekstern kan tage
En fractional CTO, som er teknisk leder hos jer nogle dage om måneden, kan overtage den del, der handler om ledelse: teknisk køreplan, leverandører, kundemøder, ansættelser og rapportering til direktionen. Lead developeren beholder koden og det daglige tekniske ansvar, og får bedre tid til begge dele. Det forudsætter en klar aftale om, hvem der beslutter hvad, se ekstern CTO og lead developer. Hvis lead developeren selv vil videre, er der en anden samtale at tage, se kan vores lead developer blive CTO?.
Vil I have flaskehalsen undersøgt af nogen udefra, starter et forløb hos Nielco IT med en gennemgang af produktet, der dækker ledelse, leverandører, teknologivalg og team. Derefter kan samarbejdet fortsætte fast fra måned til måned inden for en timeramme, I aftaler på forhånd. Selve kodearbejdet bliver hos teamet. 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 sende personen på et kursus i uddelegering · problemet er opgavernes placering, og kurset flytter ingen opgaver.
- At bede lead developeren holde sig fra kunderne fra den ene dag til den anden · lav først stedet, hvor sagerne skal lande.
- At vente på, at personen siger fra · de fleste gør det først med en opsigelse.
Det skal I kræve af den eksterne
- ☐ En skriftlig aftale om, hvem der beslutter hvad.
- ☐ En liste over de opgaver, der flyttes væk fra lead developeren, og hvornår.
- ☐ Løbende opfølgning sammen med lead developeren, så ændringen faktisk kan mærkes.
- ☐ En plan for, hvordan afhængigheden af én person bliver mindre.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Syv tegn på, at produktet mangler teknisk ledelse · Den tekniske stifter er blevet flaskehalsen
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
