# Een remote developer onboarden: de eerste twee weken URL: https://brainpowergroup.eu/nl/blog/remote-developer-onboarden-eerste-twee-weken Datum: 2025-05-20 (bijgewerkt 2026-07-22) Door: Aleksa, Brainpower Group Een remote developer draait na twee weken mee in je sprint als de toegang op dag 1 werkt en er in de eerste week een kleine, echte taak klaarligt. Een remote developer draait na twee weken mee in je sprint als de toegang op dag 1 werkt en er in de eerste week een kleine, echte taak klaarligt. Wat een start vertraagt, is bijna altijd wachten, bijvoorbeeld op een account of op een review die dagen blijft liggen. Het meeste daarvan los je op voordat de developer begint. ## Wat je klaarzet voor dag 1 Het meeste werk zit vóór de eerste dag, en een groot deel daarvan ligt bij de opdrachtgever. Wij regelen de laptop: beheerd en versleuteld, met een centraal beheerd account, SSO en tweestapsverificatie. Toegang tot jouw systemen kun alleen jij geven. Zet dit klaar voordat de developer begint: - toegang tot de repository, met rechten om branches te pushen en pull requests te openen - een account in je ticketsysteem en je chat, plus uitnodigingen voor de vaste overleggen - een ontwikkel- of testomgeving met bruikbare testdata, zonder persoonsgegevens uit productie - de secrets die nodig zijn om lokaal te draaien, gedeeld via je vault of secretmanager en niet via de chat - een README die beschrijft hoe je het project lokaal opstart Mijn advies is om iemand uit je eigen team die README een week van tevoren te laten volgen op een schone machine. Wat dan niet werkt, werkt op dag 1 ook niet, en dat ontdek je liever zelf dan dat een nieuwe collega er een dag mee bezig is. ## Dag 1: draaiend krijgen en kennismaken Het doel van dag 1 is bescheiden: aan het eind draait de applicatie lokaal en heeft de developer de mensen gesproken met wie hij gaat werken. Plan een videocall van een uur met de lead aan jouw kant. Vertel wat het product doet en waar het team nu mee bezig is. Laat de architectuur op hoofdlijnen zien, het liefst met een tekening die al bestaat. Een nieuwe tekening maken voor de onboarding kost tijd, en over een maand klopt die niet meer. Wijs ook één vast aanspreekpunt aan voor de eerste twee weken: iemand die vragen binnen een paar uur beantwoordt en het niet erg vindt om gestoord te worden. Servië zit in dezelfde tijdzone als Nederland, dus dat kan tijdens kantooruren. Een eerste commit op dag 1 is mooi meegenomen, en een kleine verbetering aan de README is daarvoor genoeg. Zo zie je meteen of de hele keten werkt, van branch tot review en CI. ## Week 1: een kleine taak die live gaat In de eerste week brengt de developer één wijziging naar productie. Kies een bug of een kleine feature die binnen een paar dagen af kan en die door meerdere lagen van de code loopt. Een label aanpassen in de frontend leert weinig. Een nieuw veld dat van de database tot het scherm loopt, laat het hele project zien, inclusief migraties, tests en deploy. Schrijf het ticket zoals je het voor een ervaren collega zou schrijven die het product nog niet kent: wat er moet gebeuren, waarom, en hoe je ziet dat het klaar is. Meer daarover staat in [tickets die een remote developer begrijpt](/nl/blog/tickets-die-een-remote-developer-begrijpt). Review de eerste pull requests snel, liefst dezelfde dag. Een eerste PR die drie dagen blijft liggen, leert een nieuwe developer dat wachten hier normaal is. Leg in de review ook de conventies uit die nergens zijn opgeschreven. Die vragen komen toch, en in een PR zijn ze goedkoper dan later in productie. Neem de developer vanaf dag 2 mee in de [dagelijkse stand-up](/nl/blog/stand-up-met-een-remote-team). In het begin valt er weinig te melden, maar zo hoort de developer wat er speelt en wie waarmee bezig is. ## Week 2: meedraaien in de sprint In week 2 pakt de developer gewone tickets uit de sprint op, van dezelfde grootte als de rest van het team. Laat de developer ook meeschatten in de planning. Na een paar tickets zie je waar het snel gaat en waar nog context ontbreekt. Plan aan het eind van de tweede week een half uur met de developer, de lead aan jouw kant en de tech lead aan onze kant. Bespreek wat goed loopt en wat nog in de weg zit, zoals toegang die nog ontbreekt of kennis die bij één persoon zit. Dat gesprek valt samen met het einde van onze proefperiode van twee weken: werkt het niet, dan betaal je niets. ## Wat je beter kunt laten Een paar gewoontes kosten in de eerste weken meer dan ze opleveren: - Een week documentatie laten lezen zonder taak. Lezen blijft pas hangen als je het nodig hebt voor iets concreets. - Een groot, vaag eerste project geven, zoals "kijk eens naar de performance". Daar zit geen eindpunt aan. - Alle kennis in één lange call op dag 1 proppen. Verdeel het over de eerste week en koppel het aan de taken. - Toegang in stukjes geven, steeds als er weer iets blijkt te ontbreken. Elke keer ligt het werk stil tot iemand het regelt. ## Wat je na twee weken mag verwachten Na twee weken heeft de developer een paar wijzigingen live gebracht en weet hij bij wie hij met welke vraag terechtkan. Zo snel als iemand die er al een jaar zit, is een nieuwe developer dan nog niet, en dat hoeft ook niet. Je moet wel zien dat tickets zonder veel heen en weer afkomen en dat de vragen steeds specifieker worden. Zie je dat niet, kijk dan eerst naar de eerste week. Ontbrak er toegang, misten de tickets context of bleven reviews liggen? Los dat op voordat je conclusies trekt over de developer. Hoe we de samenwerking verder inrichten, staat bij [onze werkwijze](/nl/werkwijze). ## Veelgestelde vragen **Hoe lang duurt het voordat een remote developer productief is?** Met goede voorbereiding brengt een remote developer in de eerste week een kleine wijziging live en pakt hij in week 2 gewone sprinttickets op. Een groot product helemaal kennen duurt langer, maar na twee weken moeten tickets zonder veel heen en weer afkomen. **Wat moet je als opdrachtgever regelen voordat een remote developer begint?** Toegang tot de repository, het ticketsysteem, de chat en een testomgeving, de secrets via een vault en een README waarmee je het project lokaal opstart. Wijs ook één vast aanspreekpunt aan voor de eerste twee weken. **Wat is een goede eerste taak voor een nieuwe developer?** Een kleine bug of feature die binnen een paar dagen af kan en door meerdere lagen van de code loopt, bijvoorbeeld een nieuw veld van database tot scherm. Zo ziet de developer de hele keten tot en met productie. --- Bron: https://brainpowergroup.eu/nl/blog/remote-developer-onboarden-eerste-twee-weken Brainpower Group, contact: https://brainpowergroup.eu/nl/contact, hello@brainpowergroup.eu