Ik ben Erik de Roos. Ik bouw software sinds 2010 en werk sinds 2016 als consultant — op de plek waar techniek, product en geld elkaar raken — bij de Nederlandse Spoorwegen, Topicus, Thinkwise en nu TransportPlan. Ik werk vanuit Kampen, run daarnaast mijn eigen productbedrijf, en ben vader van twee. Dat laatste noem ik omdat het bepaalt hoe ik werk: gerichte dagen, duidelijke afspraken, geen half aanwezige consultant.
Binnen twee weken weet ik waar de structurele risico's zitten — niet alleen de symptomen die iedereen al voelt. Dat komt niet uit documentatie. Het komt uit rondlopen en veel mensen spreken, en dan zien waar hun verhalen elkaar tegenspreken.
Adviseren vanaf een afstand werkt bij mij niet. Ik zie pas wat ertoe doet door met jouw vraag te worstelen — in de code, in het proces, in de gesprekken met je mensen. Daarom stel ik vanaf dag één scherpe vragen: hoe sneller ik er echt in zit, hoe sneller ik iets waard ben.
Sleutelrollen vallen weg, prioriteiten kantelen, iemand wordt langdurig ziek. Dat is het moment waarop ik meestal nuttiger word in plaats van minder nuttig.
In elk bedrijf zijn er dingen die iedereen is gaan aannemen zonder ze nog te toetsen. Daar zit meestal het echte probleem. Ik stel de vraag die niemand meer stelt — niet om lastig te doen, maar omdat het antwoord ertoe doet.
Bijna elk bedrijf meet iets. De vraag is niet óf er cijfers zijn, maar naar wiens beslissingen ze wijzen. Gaat alles wat gemeten wordt over de uitvoering, en niets over de keuzes daarboven, dan weet je binnen een dag welk gesprek er niet gevoerd wordt. Daar lekt meestal ook het geld weg.
Geen anonieme cases. Dit zijn de bedrijven, en dit is de beslissing die er is veranderd — niet de lijst met wat ik gebouwd heb.
Technisch eindverantwoordelijke — SaaS in de transportsector
De grootste klant draaide op een eigen versie. Die was ooit als noodgreep gemaakt omdat de applicatie bij hen vastliep. Iedereen behandelde het als een klantprobleem; ik ging op zoek naar de oorzaak en vond hem in de manier waarop schermen werden opgeruimd — een fout die álle klanten raakte, alleen bij hen het hardst. Na de fix heb ik die klant zelf benaderd om terug te gaan naar de standaardversie. Eén onderhoudslijn minder, en een kritische klant die weer op hetzelfde product draait als de rest.
Sneller leveren. De vraag was hoe er meer uit het team kon komen. Het knelpunt bleek niet de bouwsnelheid maar het uitrollen: dat ging handmatig, zonder terugweg, dus het gebeurde zo min mogelijk. 59 releases in 13 maanden, nul mislukkingen — en releasen is geen beslissing meer maar een handeling.
Senior engineer — low-codeplatform, enterprise klanten
Een migratie stond al een jaar stil. De vraag was niet hoe je hem afmaakt maar waaróm hij vastliep — en dat bleek in de aanpak te zitten, niet in de capaciteit. Met die diagnose kwam hij alsnog in productie, bij enterprise klanten die ondertussen gewoon doordraaiden. De oorspronkelijke architect van het platform behandelde me als technisch gelijke, en ze vroegen me terug voor de eindfase.
Ik zat daar bewust niet alleen bij mijn eigen team. Het hele bedrijf gebruikte intern de tool waaraan we werkten, dus ik ging met mijn laptop bij andere afdelingen zitten om te zien waar mensen in de praktijk op vastliepen. Niet iedereen vond dat vanzelfsprekend — het gangbare idee was dat je met een onduidelijkheid naar je manager gaat. Maar ik moet voelen voor wie ik het doe en waar ze mee zitten. Anders bouw ik het verkeerde goed.
Senior engineer — financieel adviesplatform, ~15 engineers
Er was een breed gevoel dat er te weinig uit het team kwam, zonder dat iemand kon zeggen waarom. Ik haalde in de eerste weken data uit Jira en Bitbucket en maakte zichtbaar hoeveel capaciteit er naar onderhoud ging in plaats van naar nieuwe waarde. Daarmee werd het een besluit in plaats van een onderbuikgevoel. In dezelfde periode haalde ik pentestbevindingen boven tafel die waren weggeschreven door de scope te verkleinen in plaats van ze op te lossen. Drie keer teruggevraagd, en vanaf de tweede periode aangeschoven bij de productmeetings.
Lead developer via Luminis — afdeling Customer Contact Management
Het team was agile, de organisatie eromheen niet. Elke koppeling liep via een centrale schakel waar we maanden op konden wachten. In plaats van dat te accepteren als gegeven heb ik die schakel gesimuleerd, zodat het team weer op eigen tempo kon werken. De conducteurs-betaalapp werd genomineerd voor NS IT-innovatie van het jaar en werd tweede — in anderhalf jaar waarin de lead developer, de scrum master en de product owner allemaal wegvielen en ik die gaten opving.
Freelance backendspecialist — reizigersinformatie
Ik werd gevraagd om te bouwen wat er gespecificeerd was. De specificaties waren helder, maar de manier waarop het gebouwd zou worden hield geen stand bij 15.000 gelijktijdige gebruikers. Dat is voor de bouw begon gemeld en anders opgezet. Korte inzet, en het probleem dat de klant zou hebben gehad is er nooit geweest.
Eigenaar — eigen gamestudio, zelf gefinancierd
Mijn eigen bedrijf naast het werk: een commercieel spel op Steam, zes freelancers aangestuurd, en daarna marketingcampagnes waarin ik met eigen geld moest kiezen wat het wél en niet waard was. Niet elke keuze pakte goed uit, en dat merkte ik op mijn eigen rekening. Daarom weet ik hoe het voelt als de rekening van een technische beslissing bij jou ligt.
Niet door minder te bouwen, maar door iets neer te zetten dat een klasse hoger zit dan wat er stond. Als dat lukt, verdwijnt een hele categorie werk — de handmatige stappen, de losse fixes, de vragen die telkens terugkwamen. Wat overblijft is een systeem waar je team zelf mee vooruit kan, zonder mij.
Dat lukt alleen als je tegelijk op vier niveaus kijkt. Een goede zet op één van deze borden is vaak een slechte op een ander, en dat zie je pas als je ze alle vier voor je hebt.
Praktisch betekent het ook dat ik niet alles zelf hoef te doen. Ik kan de richting uitschrijven — wat er moet komen, waarom, en in welke volgorde — zodat jij, je eigen developer of een junior het uitwerkt. Als dat de goedkoopste route is naar hetzelfde resultaat, is dat de route.
Wat ik daarvoor van jou nodig heb: toegang tot meer dan alleen het team waarvoor ik ben ingehuurd. Ik wil bij de mensen kunnen zitten die met het resultaat moeten werken — support, sales, de werkvloer, en waar het kan je klanten zelf. Zonder dat zie ik één bord in plaats van vier, en dan ben ik een dure developer.
Dat is bij mij geen methode die ik mezelf heb aangeleerd. Ik maak graag een praatje, ook met mensen die ik niet nodig heb voor iets. Zo hoor je waar het echt schuurt — meestal niet in een overleg, maar bij het koffieapparaat van een afdeling waar je formeel niets te zoeken hebt.
Er was geen technische koers die verder keek dan het lopende kwartaal. Daardoor was elk voorstel even urgent en kon je er alleen op onderbuik ruzie over maken. Ik heb die koers uitgeschreven: per project wat er moet komen, wat het commercieel oplevert, en welke alternatieven zijn afgevallen en waarom. Dat laatste is het punt — een keuze die is vastgelegd inclusief wat er níet gekozen is, kan iemand anders over twee jaar herzien. Een keuze die alleen in mijn hoofd zat, niet.
Het zijn kaders, geen contracten. Je kunt een project maar tot een bepaalde diepte uitwerken voordat je gaat gissen, en verder gissen kost meer dan het oplevert. Onder elk kader ligt steeds dezelfde vraag: wat moeten we vandaag doen zodat we volgend jaar nog werk hebben dat de moeite waard is?
Het scherpst werd het bij het overzicht over projecten heen. Niet alleen welke afhankelijkheden er lagen, maar ook welke drie gesprekken het tempo bepaalden terwijl ze nergens op een agenda stonden. Dat is geen technische bevinding.
En daarna heb ik het gebouwd. Dat is het verschil met een adviestraject: het licentiesysteem, de API en de MCP-connector stonden eerst op die kaart. Een plan dat je zelf moet uitvoeren, schrijf je anders.
Zo kies ik ook uit wát er gebeurt. Niet op een businesscase op papier, maar op de vraag welk project je in fasen kunt knippen waarbij elke fase iemand concreet verder helpt — een collega, een afdeling, een klant die erop zit te wachten. Wie die mensen zijn, zoek ik zelf uit; dat krijg ik niet aangereikt. Dat is waar de vier borden voor dienen: ze laten zien wie er aan de andere kant van een technische keuze staat. Werk dat op één plek vooruitgang geeft is duur. Werk dat op drie plekken tegelijk landt, is wat je zoekt.
Daarom leveren twee dagen bij mij meer op dan je zou rekenen. Niet omdat ik harder werk, maar omdat ik het werk anders uitkies.
Twee ondernemers hadden samen een cloudtool gebouwd en waren vastgelopen. Ze vroegen me om één sessie te begeleiden, met de vraag die ze allebei beantwoord wilden zien: wie heeft er recht op wat?
Dat oordeel heb ik niet gegeven. Wat ik wél deed, was laten zien dat er nauwelijks afspraken lagen om op terug te vallen — en dat de waarde van het product helemaal nog niet bewezen was. Ze presenteerden de tool als generiek, maar hij was gebouwd rond één specifieke manier van werken bij één type klant. De echte drempel was niet technisch maar commercieel: er was niemand die hen bij bedrijven naar binnen kon loodsen. Zolang dat zo bleef, zat de waarde niet in de software.
Alles wat ik naar boven haalde, was wat ze allebei vanzelfsprekend waren gaan vinden. Het gesprek eindigde niet met een winnaar, maar met twee mensen die zagen dat ze er allebei een aandeel in hadden gehad — ook in hoe slecht ze onderweg met elkaar waren gaan communiceren.
Beiden waren achteraf uitgesproken tevreden. Niet over mijn oordeel, maar over hoe het gesprek was voorbereid en gevoerd. Eén sessie was de vraag. Eén sessie was genoeg.
Op een vrije dag in een lang weekend kwam er een bericht binnen: of een bepaalde functie op een specifieke dag beschikbaar was geweest. Er was die dag een grote storing bij een externe partij en een klant had daarom op papier gewerkt. De toezichthouder wilde weten of dat terecht was.
Technisch was het te beantwoorden. Ik heb het uitgezocht en kon reconstrueren hoe het gelopen was. Maar bij het opschrijven van dat antwoord zag ik wat er werkelijk gebeurde: ze vroegen niet om inzicht, ze vroegen om bewijs. Onze meetgegevens waren nooit bedoeld of goedgekeurd als bewijsmateriaal. Door toch te antwoorden, zouden we onszelf tot scheidsrechter maken over de vraag of een klant terecht papier had gebruikt — met een boete als inzet.
Dus heb ik de vraag niet beantwoord maar doorgegeven aan de directeur, met het feitenonderzoek erbij, drie mogelijke antwoordroutes, en één grens expliciet benoemd: wij moeten hier niet tussen willen zitten.
Dit is wat ik bedoel met werk op beslissingsniveau. De technische vraag was makkelijk. Zien dat het de verkeerde vraag was, gebeurde voordat er iemand op verzenden had gedrukt.
Ik programmeer sinds mijn tiende, uit eigen beweging. Toen ik moest kiezen wat ik ging studeren, koos ik bewust de hbo-variant van technische informatica en niet de universitaire: ik wilde bouwen, niet beschouwen. Ing. achter mijn naam, en dat is precies de goede letter.
Sindsdien heb ik geleerd om het bedrijf van een klant te behandelen alsof het van mij is — wat er speelt, waar het geld vandaan komt, wat je klanten dwarszit. Niet omdat het hoort, maar omdat ik er anders niets zinnigs over te melden heb. Die betrokkenheid krijg je binnen twee dagen per week; dat is geen tegenstelling, dat is focus.
Ik ben 38 en heb de meeste dingen al een keer gedaan: jong getrouwd omdat ik dacht die verantwoordelijkheid wel aan te kunnen, twee kinderen, een eigen bedrijf, jaren in loondienst, en daarna opnieuw beginnen. Dat heeft me vooral geleerd waar ik mijn tijd aan wil besteden, en waaraan niet.
Waar ik enthousiast van word is het moment dat ergens anders in het bedrijf een vraag blijkt te liggen die met hetzelfde werk beantwoord wordt. Dan is er voor iedereen meer. Ik geloof niet in samenwerkingen waarin de winst van de één het verlies van de ander is — als het zo voelt, zijn we met de verkeerde dingen bezig.
Ik werk vanuit Kampen. Zwolle, Deventer, Apeldoorn, Dronten, Emmeloord, Harderwijk en Lelystad liggen allemaal binnen een klein uur. Dat betekent dat ik niet iemand ben die invliegt, een rapport achterlaat en verdwijnt. Ik kom langs, ik kom terug, en je komt me nog eens tegen — waarschijnlijk met de hond, want ik loop graag een rondje en spreek onderweg mensen aan.
Verder rijden doe ik ook. Alleen gaat reistijd van de werkdag af, dus hoe verder weg je zit, hoe minder vaak zo'n kantoordag eruit kan — eens per twee weken bijvoorbeeld, met de rest op afstand. Dat werkt prima, zolang we die ruil aan het begin afspreken in plaats van hem gaandeweg te laten verwateren.
Voorspelbaarheid is belangrijker dan aanwezigheid. Daarom zeg ik vooraf wat je krijgt.
Vaste dagen
Twee dagen per week, op dagen die we vastleggen. Je team weet wanneer ik er ben en hoeft niet te gokken.
Eén dag op locatie
Minimaal één van die dagen bij jou op kantoor. Bij elkaar zitten doet iets wat een videocall niet doet — zeker in het begin.
De eerste weken vaker
In de eerste twee tot vier weken ben ik meer op locatie. Je bedrijf leren kennen doe je niet via een scherm.
Bereikbaar op de andere dagen
Loopt er iets vast, dan ben ik te bereiken. Niet aanwezig, wel benaderbaar — en dat verschil spreken we vooraf af.
En eerlijk: fulltime doe ik niet. Ik run mijn eigen bedrijf ernaast en ik heb twee kinderen. Wat je krijgt zijn twee dagen waarop ik er echt ben, in plaats van vijf waarop ik half meedraai bij vier bedrijven tegelijk.
Eén gesprek is genoeg om te weten of ik iets voor je kan betekenen. Zo niet, dan zeg ik dat ook — dat scheelt ons allebei tijd.