Fractional CTO en remote team: wie doet wat?

Een fractional CTO bepaalt de technische richting en neemt de beslissingen die duur zijn om terug te draaien. De tech lead zet die richting elke dag om in werk. Remote developers bouwen en beslissen zelf over alles wat binnen hun ticket valt. Leg die verdeling vast, dan weet iedereen waar hij terechtkan op de dagen dat de CTO er niet is.

Ik werk zelf als fractional CTO. Deze opzet loopt vooral op twee plekken vast: iemand neemt een beslissing die bij een ander hoort, of een beslissing blijft liggen tot de CTO weer een dag binnen is. Met een paar afspraken voorkom je allebei.

Wie beslist over wat

Een fractional CTO werkt een vast aantal dagen per maand, de tech lead en de developers zijn er elke werkdag. Verdeel de beslissingen daarom naar hun soort, en niet naar wie de meeste ervaring heeft.

Twijfel je bij wie een beslissing hoort, vraag dan wat het kost om hem over een halfjaar terug te draaien. Is dat een middag werk, dan beslist de developer of de tech lead. Gaat het om weken werk of om een datamigratie, dan is het aan de CTO.

Wat de fractional CTO doet

De CTO schrijft de kaders op waarbinnen het team werkt: de stack, hoe services met elkaar praten, waar data staat, welke dependencies erin mogen en hoe toegang tot systemen geregeld is. Bij elke grote keuze hoort een korte notitie met wat er besloten is, waarom, en welk alternatief afviel. Een architecture decision record van een halve pagina is genoeg.

Daarnaast praat de CTO met de directie of de founder over wat er dit kwartaal af moet en wat het mag kosten. Komen er mensen bij, dan voert hij het technische gesprek met kandidaten of beoordeelt hij de screening die er al ligt.

Mijn advies is om de CTO-dagen vast in te plannen, bijvoorbeeld elke dinsdag. Het team weet dan wanneer een grote vraag beantwoord wordt en plant het werk daaromheen.

Een fractional CTO hoeft niet elke pull request te reviewen. Wie dat wel doet, legt het werk stil op elke dag dat hij er niet is. Kijk steekproefsgewijs mee, en altijd bij wijzigingen aan authenticatie, betalingen of het datamodel.

Wat de tech lead doet

De tech lead is het dagelijkse aanspreekpunt van de developers. Hij knipt werk op in tickets, reviewt code, beantwoordt vragen en haalt blokkades weg. Ook bewaakt hij de afspraken van de CTO, en hij weet wanneer een vraag te groot is om zelf te beslissen.

Die rol kan bij jou in huis zitten of in het remote team. Dat werkt allebei, als de tech lead bereikbaar is op de uren dat de developers werken. Onze developers zitten in Servië, in dezelfde tijdzone als Nederland, dus daar zit geen verschuiving in.

Heb je één of twee developers, dan kan de fractional CTO de rol van tech lead tijdelijk zelf vullen, mits hij daar meer uren voor heeft. Vanaf drie developers zou ik een vaste tech lead aanwijzen. Wanneer je welke stap zet, lees je in van één naar vijf developers.

Wat de remote developers doen

Een developer is eigenaar van zijn ticket, van de eerste vraag tot de merge. Vragen stelt hij vroeg en op schrift, in het ticket of in de pull request, zodat de tech lead en de CTO de context later terugvinden. Hij schrijft de tests, houdt pull requests klein en meldt het als een ticket niet klopt.

Over de uitwerking beslist de developer zelf: naamgeving, de structuur binnen een module, welke tests erbij horen. Moet de tech lead zich daar steeds mee bemoeien, dan staan de standaarden niet duidelijk genoeg op papier. Hoe een ticket eruitziet waarmee een remote developer verder kan, staat in tickets die een remote developer begrijpt.

Waar het misgaat

Klopt de verdeling niet, dan zie je meestal een of meer van deze patronen:

• Alleen de CTO mag mergen, dus op zijn vrije dagen ligt alles stil.
• Developers wachten op de CTO voor een keuze die de tech lead had mogen maken.
• De founder stuurt developers rechtstreeks nieuwe wensen, buiten de prioriteiten van de tech lead om.
• Niemand voelt zich verantwoordelijk voor accounts en toegang, waardoor oud-medewerkers hun rechten houden.
• Beslissingen vallen in een call en komen niet op papier, dus een maand later bespreekt het team ze opnieuw.

In al deze gevallen helpt het om vast te leggen wie erover gaat en te zorgen dat die persoon bereikbaar is.

De afspraken op één pagina

Zet de verdeling op één pagina in de repository of de wiki en loop hem door met iedereen die erbij komt. Dit hoort er minstens op:

1. Welke beslissingen bij de CTO liggen, met een paar voorbeelden.
2. Hoe een vraag de CTO bereikt. Ik werk het liefst met een kort schriftelijk voorstel van de tech lead: de opties en zijn voorkeur.
3. Hoe snel de CTO antwoordt, ook buiten zijn vaste dagen. Binnen één werkdag is een redelijke afspraak.
4. Een vast overleg tussen CTO en tech lead, bijvoorbeeld een halfuur per week.
5. Wie accounts aanmaakt en weer intrekt.

Wij leveren developers en ook een fractional CTO, maar je hoeft ze niet samen af te nemen. Werk je al met een eigen fractional CTO, dan werken onze developers volgens diens afspraken. Bij Zibber lichtten we de bestaande techniek door, ontwierpen we de architectuur en dachten we mee over de teamopzet, zodat het team de richting daarna zelf kan dragen. Hoe we developers in een team plaatsen, lees je bij onze werkwijze.