Efter den første måned bør I have noget, I kan læse, og noget, I kan beslutte ud fra. Fire leverancer dækker det: en risikoliste, et overblik over arkitekturen, en vurdering af team og leverandører med en plan for ansættelser og en kort prioriteret plan for det næste kvartal. Hver af dem kan fylde få sider. De skal være skrevet, så en direktør uden teknisk baggrund kan følge med. Får I kun mundtlige indtryk, står I med lige så lidt, den dag personen er væk. Forudsætningen er, at den eksterne fik de nødvendige adgange i første uge, og den liste følger her først.
Første uge: de adgange, rollen skal bruge
En fractional CTO kan ikke danne sig et billede af produktet ud fra samtaler alene. Hav dette klar, gerne før første dag:
- Læseadgang til repository, altså det sted, hvor koden og dens historik ligger.
- Læseadgang til cloudkontoen, så drift og opsætning kan ses.
- Sagsstyring og den liste over fejl og opgaver, teamet arbejder efter.
- Overvågning og logning, hvis I har det.
- Aftaler med udviklingsleverandører, hostingfirma og de tjenester, produktet bygger på.
- Køreplanen, som den ser ud nu, og de løfter, der er givet til kunder.
- En liste over de personer, der skal tales med, og en besked til dem om hvorfor.
Læseadgang er nok i den første tid og holder risikoen nede. Hver person bør have sin egen bruger, så delte logins undgås. Skal der mere til, tages det op, når opgaverne er aftalt. Hvor langt mandatet rækker, afgøres særskilt, se mandatet til den eksterne CTO.
Bliver adgangene forsinket, er det i sig selv en oplysning. Ingen ved måske, hvem der har administratorrettighederne, eller de ligger på en konto i en tidligere medarbejders navn. Den slags hører på risikolisten.
Risikolisten
Risikolisten samler de forhold, der kan ramme produktet, kunderne eller planen. Den bør være kort nok til at blive læst. Hver linje svarer på fire spørgsmål: Hvad kan ske? Hvad ville det betyde for forretningen? Hvor sandsynligt er det? Hvad foreslås, og hvem ejer det?
Typiske punkter er en del af koden, som kun én person kender, en backup, ingen har prøvet at gendanne, en leverandør uden aftale om overdragelse eller en teknologi, der er ved at miste support. Listen skal rangordnes. Står alle punkter som lige vigtige, har forfatteren overladt prioriteringen til jer.
Sikkerhed indgår på listen, for så vidt det handler om produktet. Dybere sikkerhedsledelse er en anden opgave.
Overblikket over arkitekturen
Arkitektur betyder her, hvordan produktet er sat sammen af dele, hvor data ligger, og hvilke tjenester det er afhængigt af. Én tegning og en side tekst er ofte nok på dette tidspunkt. Du skal kunne pege på tegningen og spørge: Hvad sker der, hvis denne del står stille? Hvem kan rette den?
Overblikket skal også nævne de dele, der er svære at ændre, og hvad der er besluttet om dem. Dokumentet får hurtigt et liv efter måneden. Det bliver grundlag for samtaler med nye udviklere og med kunder, der spørger til løsningen.
Team, leverandører og plan for ansættelser
Den tredje leverance beskriver, hvem der bygger produktet, og om holdet passer til opgaven. Den skal svare på, hvor produktet er sårbart, hvis en person stopper, hvad I mangler de næste seks til tolv måneder, og om noget bør løses med en ansættelse, en leverandør eller ændrede opgaver.
Planen for ansættelser må gerne sige, at der ikke skal ansættes nogen endnu. Den er god, når den begrunder rækkefølgen og beskriver, hvad den næste person skal kunne. Omtal af enkeltpersoner hører til i en samtale med direktøren frem for i et dokument, der deles bredt.
Den prioriterede plan
Fjerde del binder det sammen. Planen for det næste kvartal skal nævne få ting, gerne med hvad der må vente. Spørg, hvad den eksterne vil anbefale jer at lade være med. Hvis alt skal gøres nu, er der ikke prioriteret.
Bed også om en liste over de beslutninger, ledelsen skal træffe. En leverance uden beslutninger tilføjer viden, men ændrer ikke noget. Planen kan senere vokse til en teknisk køreplan ved siden af produktkøreplanen.
Sådan læser I måneden
Sæt en time af til en gennemgang af leverancerne. Sammenlign med det, I selv troede ved starten. Er der noget nyt? Er der noget, I er uenige i? Lad lead developeren eller den, der kender koden bedst, læse med og sige, om billedet er retvisende.
De første tre måneder set bredere, uanset rolle, er beskrevet under de første 90 dage. Her gælder det alene det, et softwareprodukt kræver.
Vil I vide, hvad I konkret får ud af et forløb med Nielco IT, begynder det med en gennemgang, der kan købes alene som første skridt, og fortsætter, hvis I vil, som et fast månedligt samarbejde, hvor timerammen er aftalt på forhånd. Det får I af en fractional CTO beskriver leverancerne.
Det skal I lade være med
- At aftale leverancerne efter opstarten · så bliver de målt på noget, der først blev formuleret bagefter.
- At give fuld adgang til alt fra første dag · læseadgang dækker behovet, indtil opgaverne er klare.
- At lægge dokumenterne i en mappe og gå videre · brug dem som dagsorden for det næste ledelsesmøde.
Det skal I kræve af den eksterne
- ☐ En liste over nødvendige adgange inden første arbejdsdag.
- ☐ En rangordnet risikoliste med ejer og forslag på hver linje.
- ☐ Et overblik over arkitekturen, som en ikke-teknisk leder kan følge.
- ☐ En vurdering af team og leverandører med en begrundet plan for ansættelser.
- ☐ En kort plan for kvartalet med det, der må vente.
- ☐ En liste over beslutninger, som ledelsen skal tage.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Sådan foregår et forløb · Arkitekturbeskrivelsen: tre sider, som en kunde kan læse
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
