Eén lead developer, twee agencies, en geen CTO.

Wat je waarschijnlijk al gemerkt hebt

Elke gemiste datum heeft twee verklaringen, één per agency, en ze wijzen naar elkaar. Het werk tussen de twee systemen, het stuk waar de output van de ene agency de input van de andere wordt, is laat op een manier die niemand echt kan vastpinnen. Je lead developer is de enige die beide kanten begrijpt, dus hij besteedt zijn week aan werk beoordelen dat hij niet mag weigeren, integratievragen beantwoorden voor beide leveranciers, en de stukken bouwen die geen van beide agencies aanraakt. De roadmap, als je het zo mag noemen, is twee backlogs die samen geen plan vormen. En de ene vergadering waar beide agencies in de kamer zitten eindigt met acties voor je lead en geen voor hen.

Het teken is de schuldvraag. Als er iets breekt op de koppeling tussen de twee systemen, heeft elke leverancier een helder, eerlijk verhaal over waarom het de schuld van de andere is. Beide verhalen kloppen meestal. Dat is het signaal dat je niet naar een kwaliteitsprobleem kijkt. Je kijkt naar een rol die niet bestaat.

Wat het echt betekent

Je vraagt één persoon om drie jobs te doen met de autoriteit om er geen enkele van te doen. Hij is de bouwer, de beoordelaar van twee leveranciers, en het integratiepunt ertussen, en geen van die mandaten staat op papier. Ondertussen is wat echt ontbreekt het eigenaarschap van de naad: het contract tussen de twee systemen, de volgorde waarin de twee agencies leveren, en de ene roadmap die beide overspant. Elke agency kan perfect capabel zijn binnen zijn eigen scope en het geheel kan nog altijd falen, want de koppeling is niemands scope.

Die ontbrekende rol is die van een CTO. Niet het deel dat mensen zich voorstellen, de architectuurschema's en het aanwerven. Het weinig glamoureuze deel: beslissen wie wat bouwt, waar de systemen elkaar raken, en wiens datum schuift als er twee botsen. Niemand doet dat, dus valt het terug op de lead developer, die een agency niet kan zeggen dat zijn scope fout zat omdat hij het contract niet bezit, of op jou, die het werk niet goed genoeg kan lezen om te oordelen. Het is hetzelfde gat waar de kmo die per ongeluk een softwarebedrijf werd op botst, maar van de andere kant bereikt: niet één systeem dat te groot werd om te bezitten, maar twee leveranciers die te ver uit elkaar groeiden om te coördineren.

Wat je eraan doet, zonder je leveranciers te ontslaan

De reflex is terugvallen op één agency zodat er één keel is om dicht te knijpen. Soms is dat juist. Vaker ruil je een coördinatieprobleem voor een lock-inprobleem en kost het een herbouw om er te geraken. Probeer eerst deze volgorde.

1. Benoem één technische eigenaar met een echte mandaat. Eén persoon bezit de roadmap over beide agencies en heeft de autoriteit om het werk van beide leveranciers te aanvaarden of te weigeren. Vaak zit die persoon al binnen: de lead developer die beide systemen begrijpt. Promoveer hem, geef hem de titel en de loonstap, en haal het bouwen van zijn bord zodat hij kan bezitten in plaats van coderen. Kan of wil hij het niet, dan houdt een fractional CTO de stoel een paar dagen per maand bezet terwijl je beslist, in plaats van ze leeg te laten.
2. Maak de naad iemands expliciete job. Eén roadmap, geen twee backlogs: een korte lijst van wat het gecombineerde systeem de komende twee kwartalen moet doen en in welke volgorde de twee agencies leveren om er te geraken. Eén architectuurautoriteit die de koppeling tussen de twee systemen beslist en uitmaakt wiens datum schuift als ze botsen. De eigenaar hierboven doet dat, of tekent ervoor af. De naad stopt met de plek te zijn waar werk verdwijnt zodra hij als iemands verantwoordelijkheid op papier staat.
3. Beoordeel beide agencies tegen resultaten, en beslis dan. Iemand moet beide contracten en beide codebases in dezelfde twee weken lezen en zeggen welke leverancier echt levert. Herschrijf de scopes zodat je voor resultaten betaalt in plaats van voor benoemde profielen en gefactureerde uren. Meestal is één agency het probleem en is één in orde. Je houdt degene die levert, houdt de andere aan een herschreven scope, en vervangt alleen de leverancier die blijft missen zodra de naad bezeten is en de scope helder. Dat is een scalpel, geen rip-and-replace waar de eerste reflex naar grijpt. In een geval dat ik beschreef was de oplossing één promotie en één heronderhandeld contract, geen nieuwe set leveranciers.

Niets hiervan vraagt een voltijdse aanwerving of een nieuw platformteam. Het vraagt een paar dagen per maand toezicht van iemand die al software bezeten heeft, wat net de vorm van werk is waar de kmo-praktijk voor gemaakt is. De meeste bedrijven in deze positie zitten één promotie en één herschreven scope van een roadmap die ze echt kunnen lezen.

Wanneer dit prima is, en wanneer je niet moet overcorrigeren

Twee agencies is niet vanzelf een probleem. Als één leverancier duidelijk de hele stack bezit, levert tegen resultaten, en je lead developer de autoriteit en de tijd heeft om het werk te beoordelen, dan heb je een structuur, geen gat. Twee leveranciers met een heldere koppeling en één eigenaar erboven is een normale, gezonde opzet. Het probleem is het eigenaarschapsvacuüm, niet het aantal leveranciers.

De overcorrectie gaat de andere kant op, en ze is duur. Een eigenaar die deze pijn net gevoeld heeft, werft soms een voltijdse CTO aan, zet een intern team op, en trekt werk terug in huis voor een probleem dat één eigenaar en twee herschreven contracten nodig had. Een voltijdse interim CTO is de juiste keuze voor een smaller geval: de levering is al stilgevallen, de interne lead vertrekt, of een herstructurering komt eraan en je wil ze laten leiden door iemand zonder geschiedenis in huis. Voor alles daaronder stem je het leiderschap af op het gat. Het gat hier is eigenaarschap van de naad, en dat is een paar dagen per maand, geen nieuwe aanwerving en een herbouw.

Veelgestelde vragen

Geschreven vanuit patronen uit eerdere opdrachten. Als iets te specifiek klinkt om algemeen te zijn, is dat de reden.