En teknisk stifter kan ikke give alt fra sig på én gang, og det er heller ikke nødvendigt. Rækkefølgen har betydning. Slip først det, der er akut og gentager sig, altså vagten og fejlrettelserne. Slip derefter kodegennemgangen og de daglige tekniske beslutninger. Behold de store arkitekturvalg længst. Tilbage står det, der kræver dig, nemlig retningen. Hver opgave får en ejer, en periode med overlap og en klar grænse for, hvornår du skal inddrages. Det er langsommere i starten end at gøre det selv, og det er meningen.
Hvorfor netop den rækkefølge
Rækkefølgen følger to spørgsmål. Hvor meget af din tid tager opgaven? Og hvor galt går det, hvis en anden laver en fejl?
Fejlrettelser og vagt tager din tid i stykker, fordi de kommer uden varsel, og en fejl rammer sjældent mere end én rettelse. De er også gode at lære af, for den, der retter fejl, lærer produktet at kende. De store arkitekturvalg ligger i den anden ende. Du bruger sjældent tid på dem, og et forkert valg kan vare i årevis. Derfor kommer de sidst.
Trin 1: Vagt og fejlrettelser
Vagt betyder, at nogen er klar, hvis produktet går ned uden for arbejdstid. Så længe den ligger hos dig alene, kan du ikke holde fri, og ingen andre lærer driften.
Sæt en plan med to eller flere personer, der skiftes. Skriv de ti almindeligste problemer ned med, hvad man gør. Lad den første på vagten være med til at skrive det næste punkt. I den første periode er du reserve, og du må gerne tage telefonen, når vagten ringer til dig. Du skal lade være med at åbne computeren, før du er blevet spurgt.
Det samme gælder fejl i hverdagen. Hver gang en fejl kommer ind, spørg: Hvem kan tage den med min hjælp? Den første gang tager det tre gange så lang tid. Tiende gang er du ude af det.
Trin 2: Kodegennemgang
Kodegennemgang er den rutine, hvor en kollega læser en ændring, før den kommer i produktet. Hos mange stiftere ligger den stadig hos dem, fordi de er bange for, at kvaliteten falder.
Skriv ned, hvad du kigger efter. Det kan fylde en side. Lad to andre gennemgå hinandens kode med dig som den, der ser med på udvalgte ændringer. Herefter trækker du dig til det, der rører de følsomme dele, fx betaling, adgangskontrol og datamodel. Du vil se kode, der er anderledes, end du ville have skrevet den. Ret kun det, der giver et reelt problem.
Trin 3: De daglige tekniske beslutninger
Her er det gode at sætte en grænse. Beslutninger, der kan laves om på en uge, træffer teamet selv. Beslutninger, der påvirker andre dele af produktet, skrives ned og drøftes. Beslutninger, der binder virksomheden i årevis, tager du.
Bed udviklerne komme med en anbefaling, når de spørger. “Hvad ville du gøre?” er det mest nyttige spørgsmål, du kan stille som leder, og svaret er ofte rigtigt. Har I en lead developer, er det her, vedkommende vokser, men pas på, at flaskehalsen ikke blot flytter sig, som lead developeren er blevet flaskehalsen beskriver.
Trin 4: Kontakten til kunder og salg
Tekniske spørgsmål fra kunder og sælgere kommer ofte direkte til dig. Saml dem ét sted, og lad en anden svare, gerne med dig som læser i starten. Lav et lille dokument med svarene på det, kunderne altid spørger om. Dit navn skal stadig være med ved de største kunder, men du behøver ikke deltage i alle møder.
Trin 5: De store valg
Valg af arkitektur, teknologi og leverandører er det sidste, og du bliver måske ved med at have det sidste ord i lang tid. Til forskel fra de andre trin handler det her om at lade andre forberede beslutningen og begrunde den skriftligt. Stifteren er med til at afgøre. Det gør, at du efterlader noget, en anden kan arbejde videre med. Sådan et notat er beskrevet i skriv de tekniske beslutninger ned.
Sådan holder du fast, når det gør ondt
Beslutningen om at slippe er den lette del. Den tunge del kommer, når du sidder stille, mens en anden gør det langsommere. Tre vaner hjælper. Sig højt, hvad du har givet fra dig, så teamet ikke bliver i tvivl. Lad være med at rette i smug om aftenen. Og mål dig på, hvad teamet leverer uden dig.
Det kan være svært at se, hvad der skal gives videre, hvis man selv står midt i det. Har du brug for en at tale med, er der mere om det i artiklen til stiftere, der selv er udviklere. Giver det mening at se det større valg om din rolle først, så start med den tekniske stifter er blevet flaskehalsen.
Det skal I lade være med
- At starte med de store valg, fordi det lyder som ledelse · dagligdagen fylder stadig din kalender.
- At give en opgave fra dig uden at sige det til nogen · så kommer alle stadig til dig.
- At overtage igen, første gang noget går galt · en fejl er en del af at lære opgaven.
- At overlade vagten til én person · så har I flyttet problemet.
Det skal I kræve af den eksterne
- ☐ Et overblik over, hvad stifteren laver i dag, og hvad der kan flyttes.
- ☐ En rækkefølge med navngivne ejere for hver opgave.
- ☐ Faste grænser for, hvad teamet selv beslutter.
- ☐ Opfølgning på, om opgaverne faktisk er flyttet efter en måned.
- ☐ Respekt for de valg, stifteren vil beholde.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Teknisk stifter: skal du være direktør eller CTO? · Overvågning, vagt og driftshændelser i produktet
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
