Introductie
Een developer kan snel bouwen. Dat betekent niet dat een developer kan beslissen wát er gebouwd moet worden.
De meeste startups nemen developers aan voordat er genoeg helderheid is. Aannemen lost zelden onzekerheid op, meestal versterkt het juist. Hoe scherper het probleem, hoe waardevoller de developer wordt.
Dit kader helpt je beslissen of de volgende stap een developer is, een scherpere briefing, of iets heel anders.
Wat het oplost
Wat een goed getimede hire levert
-
Uitvoeringssnelheid op een gedefinieerd probleem
Wanneer het probleem helder is en de briefing scherp, verandert een developer weken plannen in geleverd product. Dat is het geval waarvoor aannemen ontworpen is.
-
Capaciteit om continu te shippen
Eén developer levert meer dan een reeks freelancers, omdat iedere freelancer de context opnieuw moet leren. Een hire betaalt zich terug wanneer continuïteit zwaarder weegt dan piek-uren.
-
Operationele veerkracht
Wanneer er om 23 uur iets stuk gaat en klanten bellen, verandert het rekensommetje rond uptime als iemand het als taak heeft. Een hire maakt operationele ownership echt.
-
Beslissingen in context
Een developer die in het product woont, neemt per week honderd kleine beslissingen. Bij een heldere briefing stapelen die beslissingen positief op. Bij een onheldere briefing stapelen ze anders op.
-
Kennis die blijft
Leveranciers vertrekken mét de kennis. Een hire bouwt het binnen het bedrijf op, waar het bruikbaar blijft voor de volgende beslissing.
Wat het niet oplost
Wat een developer aannemen niet oplost
-
Gebrek aan helderheid
Een developer kan niet beslissen wat er gebouwd moet worden. Als de founder onzeker is, gaat de developer gokken (vaak fout) of om duidelijkheid vragen (en het team vertragen). Geen van beide is een hire-probleem.
-
Ontbrekende vraag
Een developer aannemen om een product te bouwen waar niemand om heeft gevraagd, verdubbelt de inzet op een ongeteste hypothese. Valideer eerst vraag; bemens daarna.
-
Verkeerde prioriteiten
Als de roadmap overvol staat, maakt méér developers de verkeerde dingen sneller. Prioriteiten zijn een productprobleem, geen staffing-probleem.
-
Een ongezond product
Een vroeg product zonder monitoring, tests of documentatie wordt slechter met meer handen erop, niet beter. Neem aan als het product 'aanneembaar' is.
-
Beschikbaarheid van de founder
Zelfs een senior developer heeft beslissingen, reviews en feedback nodig. Een hire die de founder niet kan bereiken, drijft weg.
Beslisboom
Zes vragen voor je iemand aanneemt
Run de hire-overweging door deze vragen. Bij een nee: dat eerst oplossen, de hire is nog niet de volgende stap.
- Vraag 01
Weet je precies welk probleem je oplost?
Nee → Scherp eerst het probleem. Een developer aangenomen in onzekerheid bouwt onzekerheid in de code.Ja → Bevestig dat je het probleem in twee zinnen kunt opschrijven zonder interne jargon. - Vraag 02
Weet je wie de klant is?
Nee → Besteed twee extra weken aan klantgesprekken, niet aan aannemen. Een developer die voor een onbekende klant bouwt, ship voor niemand.Ja → Toets of je de klant concreet kunt beschrijven, segment, rol, pijnlijk moment. - Vraag 03
Weet je hoe versie één eruitziet?
Nee → Definieer eerst v1. Zonder gedefinieerde v1 brengt iedere vrijdag nieuwe prioriteiten, en de hire maakt nooit iets af.Ja → Toets of v1 binnen acht tot twaalf weken live kan. Anders is v1 te groot en wordt de hire opgezet om te falen. - Vraag 04
Is succes te meten?
Nee → Definieer de metric voor je aanneemt. Als je niet kunt zien of de hire succes heeft, kun je ook niet zien of het product dat heeft.Ja → Bevestig dat de metric in dagen of weken waarneembaar is, niet in kwartalen. - Vraag 05
Is er meer dan drie maanden concreet werk?
Nee → Huur een freelancer of bureau in voor het gedefinieerde werk. Een vaste hire op drie maanden werk creëert druk om hem of haar bezig te houden met de verkeerde dingen.Ja → Bevestig dat het werk concreet is, niet alleen 'veel te bouwen product'. - Vraag 06
Heb je uitvoering of helderheid nodig?
Nee → Als je helderheid nodig hebt, helpt een ervaren adviseur of co-founder meer dan een hire. Uitvoering kopen op een onheldere briefing is dure verwarring kopen.Ja → Je bent klaar. Neem aan, en bescherm de tijd van de hire zodat uitvoering is wat ze ook echt doen.
Veelgemaakte fouten
Vijf veelgemaakte fouten
- 01
Aannemen voor scope is gedefinieerd
Een vage briefing plus een developer levert vrijwel altijd dure verwarring op. De developer bouwt iets; de founder wijst het af; de cyclus herhaalt. Definieer de briefing eerst; neem daarna aan.
- 02
Aannemen omdat concurrenten aannemen
Headcount is een vanity metric, geen strategie. De hires van een concurrent lossen hun problemen op, niet die van jou. Neem aan om een concreet eigen probleem op te lossen, niet om iemands org chart te matchen.
- 03
Senior talent aannemen voor junior problemen
Een ervaren senior in een simpele omgeving met weinig beslissingsruimte verveelt zich en vertrekt. Match het niveau aan het werk, en aan de autonomie die je werkelijk kunt bieden.
- 04
Aannemen voordat validatie er is
Opstaffen om een product te bouwen waar niemand om heeft gevraagd, is de duurste vorm van gokken. Valideer eerst; bemens daarna.
- 05
Aannemen voor prioriteiten helder zijn
Als de roadmap iedere twee weken verandert, besteedt een hire het grootste deel van zijn tijd aan context-switching. Stabiliseer eerst prioriteiten; laat de hire daarna iets shippen.
Alternatieven
Praktische alternatieven voor een vaste hire
Vier opties die vaak beter passen dan aannemen voordat er helderheid is.
-
Freelancer of contractor
Brengt gedefinieerde vaardigheden naar een gedefinieerd probleem voor een gedefinieerde tijd. Goedkoop om te starten, goedkoop om te stoppen. De juiste default zolang de briefing nog stevig wordt.
-
Specialistisch bureau
Nuttig voor werk dat smal en goed gedefinieerd is, een integratie, een betaalflow, een redesign. Minder nuttig voor doorlopende product-ownership.
-
Fractional CTO of technisch adviseur
Wanneer de vraag is wát er gebouwd moet worden (niet wíe het bouwt), bespaart een ervaren adviseur meer tijd dan een hire. Betaal voor oordeel, niet voor throughput.
-
Proefopdracht voor je aanneemt
Run een betaalde proef, twee tot vier weken op een echt, scoped probleem, met de kandidaat. Je leert er meer over samenwerken dan welk interview ook oplevert.
Vuistregel van Ronald
Een vage roadmap plus een developer levert meestal dure verwarring op.
Aannemen voelt als vooruitgang omdat het capaciteit toevoegt. Maar capaciteit zonder richting vermenigvuldigt het verkeerde werk. De goedkoopste, snelste oplossing voor de meeste pre-hire-situaties is geen hire, het zijn twee extra weken klantgesprekken en een scherpere briefing.
, Ronald · YourStartup.Expert
Samenvatting
Samenvatting
Een developer aannemen is de juiste zet wanneer het probleem helder is, de klant bekend, v1 gedefinieerd, succes meetbaar, en er minstens twaalf maanden werk ligt om de hire shippend te houden. Wanneer die voorwaarden ontbreken, versterkt aannemen meestal onzekerheid in plaats van die op te lossen.
De meeste founders worden niet geblokkeerd door capaciteit. Ze worden geblokkeerd door helderheid. Helderheid is goedkoper te repareren dan headcount, en de reparatie ontgrendelt meestal de komende maand werk zonder een nieuw salaris eronder.
Veelgestelde vragen
Je eerste developer aannemen, beantwoord.
De vragen die founders stellen voordat ze het aanbod doen.
- Wanneer neemt een startup zijn eerste developer aan?
- Wanneer het probleem duidelijk is gedefinieerd, de klant bekend, v1 een gescopte vorm heeft, succes een meetbare metric heeft, en er minstens twaalf maanden concreet werk ligt. Als die voorwaarden ontbreken, moet de founder meestal eerst helderheid kopen, via klantgesprekken, een fractional CTO of een scherpere briefing, en daarna aannemen. Aannemen tegen een onhelder probleem vermenigvuldigt de prijs van fout zitten.
- Freelance of vast aannemen?
- Freelance is de juiste default zolang de briefing nog stevig wordt of het werk echt tijdelijk is. Vast wordt de juiste keuze wanneer continuïteit, operationele ownership en opgebouwde productkennis zwaarder wegen dan piek-throughput. Een handige toets: als je geen twaalf maanden concreet werk kunt beschrijven dat de hire bezit, is een contractor waarschijnlijk passender.
- Senior of junior aannemen?
- Senior wanneer het werk oordeel onder onzekerheid vraagt, architectuurkeuzes, scope-discussies, trade-off-gesprekken. Junior wanneer het werk goed gescopt is en het team senior mensen beschikbaar heeft om te begeleiden. Een veel voorkomende fout is een senior aannemen voor junior-werk; de senior verveelt zich en vertrekt. Match het niveau aan het werk, niet aan het budget.
- Wat moet er bestaan voor je aanneemt?
- Een geschreven probleemstelling, een gedefinieerde klant, een gescopte v1 die in acht tot twaalf weken past, een meetbare succesmetric, een eerlijke inschatting van hoeveel founder-tijd beschikbaar is om de hire te ondersteunen, en een backlog van concreet werk die minstens negen maanden voorbij de startdatum loopt. Als er twee of meer ontbreken: eerst aanscherpen, dan aannemen.
- Kan AI developers vervangen?
- AI verandert de doorvoersnelheid van een developer; het vervangt het oordeel niet. AI is uitstekend in code schrijven tegen een heldere specificatie, en matig in het bepalen wát de specificatie zou moeten zijn. Voor een vroeg product met schuivende requirements en weinig vastgelegde patronen zit het knelpunt meestal in beslissingen, niet in regels code. AI helpt; het vervangt het oordeel waarvoor je een hire zoekt niet.