De eerste 90 dagen met een fractional CTO

Een nieuwe technische leider kan indruk maken door meteen alles te benoemen wat moet veranderen. Dat is niet hetzelfde als begrijpen wat het bedrijf nodig heeft. Het eerste deel van een samenwerking moet de situatie duidelijker maken voor het plan groter wordt.

Onderstaande opbouw helpt om over de eerste maanden na te denken. Het is geen vast opleverpakket. Beschikbare capaciteit, toegang en de toestand van het team bepalen het tempo. Bij een incident moet bepaald werk meteen gebeuren. Bij een stabiel product kan eerst luisteren de nuttigste bijdrage zijn.

Eerst: begrijp het echte werk

Praat met de directie, ontwikkelaars en de mensen die het product ondersteunen of gebruiken. Volg een recente wijziging van vraag tot productie. Bekijk een echt incident en een echt klantenprobleem. Documentatie helpt, maar hoe het werk loopt verklaart vaak meer dan het architectuurschema.

Regel veilige toegang en breng het huidige eigenaarschap van systemen, toegangen en leveranciers in kaart. Benoem dringende risico's en bestaande beloftes. Het eerste resultaat moet een kort gedeeld beeld zijn van wat aandacht vraagt, wat kan wachten en wat nog onbekend is.

Daarna: kies een kleine werkagenda

Spreek af welke beslissingen de rol opneemt en welke bij jou blijven. Kies enkele prioriteiten die bij het bedrijf aansluiten: een kwetsbare release veiliger maken, een leveranciersafhankelijkheid verhelderen of een overvolle backlog tot een haalbare volgende stap terugbrengen.

• Schrijf het probleem en de bedoelde verbetering op.
• Benoem wie beslist en wie uitvoert.
• Bepaal waaraan je zult merken dat de ingreep helpt.
• Spreek beschikbaarheid, escalatie en de volgende evaluatie af.

Start niet verschillende structurele projecten alleen omdat ze in de review naar boven kwamen. Een lange lijst zinvolle verbeteringen kan de volgende bron van onzekerheid worden. Maak de afweging zichtbaar en werk iets nuttigs af voor je de agenda uitbreidt.

Vervolgens: volg keuzes tot in de uitvoering

Blijf dicht genoeg bij de implementatie om foute aannames te ontdekken. Beoordeel het aangepaste systeemdeel, het releasepad en de gevolgen voor ondersteuning. Houd beslissingen toegankelijk voor team en directie. Een logboek moet uitleggen waarom een keuze gemaakt is, niet alleen dat er een vergadering was.

Vraag bij de evaluatie wat eenvoudiger werd

Kan het team zijn prioriteiten uitleggen? Begrijpt de directie de technische risico's? Is een vroeger kwetsbare wijziging nu veiliger te releasen? Kan iemand anders dan de vaste expert de taak opnemen? Dat zijn nuttigere vragen dan aanbevelingen of vergaderingen tellen.

De evaluatie kan wijzen op verderzetten, betrokkenheid verminderen, ontwikkelcapaciteit toevoegen of een interne aanstelling voorbereiden. Een samenwerking die ontdekt dat ze niet meer nodig is, is niet mislukt. Het doel was een sterkere organisatie, geen blijvende afhankelijkheid.

De fractional CTO-dienst beschrijft hoe we die betrokkenheid afspreken. Je kunt ook Levi's professionele ervaring bekijken voor je een kennismaking plant.