Waarom een carrièrestap lang niet altijd over technologie gaat

Wanneer ik met een IT'er in gesprek raak, ben ik eigenlijk niet alleen geïnteresseerd in de technologie waarmee iemand werkt.

Natuurlijk wil ik weten wat iemand technisch doet. Maar voor een volgende stap vind ik een andere vraag vaak veel interessanter:

In wat voor omgeving kom jij het beste tot je recht?

Je kunt bij twee organisaties exact dezelfde functietitel hebben en met grotendeels dezelfde technologie werken, terwijl je dagelijkse werk totaal anders is.

De één bouwt jarenlang aan hetzelfde product. De ander sluit als externe aan bij verschillende organisaties. En weer iemand anders werkt met vaste collega's aan complete projecten voor verschillende klanten.

Voor mij zijn er grofweg drie werelden.

Inhouse

Inhouse werk je aan het eigen product, platform of IT-landschap van een organisatie.

Dat kan een SaaS-platform zijn dat door duizenden klanten wordt gebruikt, maar net zo goed het IT-landschap van een bank, energiebedrijf of verzekeraar.

Wat deze omgeving interessant maakt, is vooral de continuïteit.

Je leert het landschap steeds beter kennen, bouwt domeinkennis op en ziet hoe technische keuzes zich over een langere periode ontwikkelen. Na een aantal jaar weet je niet alleen hoe iets technisch werkt, maar vaak ook waarom het ooit zo gebouwd is en wat de business ermee probeert te bereiken.

Dat kan veel ownership geven.

Tegelijkertijd betekent inhouse niet automatisch dat je iedere dag met de nieuwste technologie werkt. Je krijgt ook te maken met onderhoud, technische schuld, bestaande architectuur en keuzes uit het verleden.

Voor de één is dat juist de uitdaging. De ander wil regelmatig een compleet nieuwe omgeving zien.

Detachering / Freelance

Bij detachering of freelance sluit je meestal als externe specialist aan bij het team van een klant.

Dat kan voor zes maanden zijn, maar net zo goed twee of drie jaar.

Je kunt daardoor binnen één opdracht behoorlijk veel ownership krijgen en direct zien wat jouw werk oplevert. Het is dus zeker niet zo dat je als externe alleen even iets bouwt en daarna weer vertrekt.

Het verschil zit vooral in de mogelijkheid om daarna bewust weer een andere omgeving op te zoeken.

Een nieuwe organisatie betekent vaak een ander IT-landschap, andere collega's, een ander domein en nieuwe technische problemen.

Daarnaast worden externen regelmatig juist voor specifieke expertise of een concreet vraagstuk binnengehaald. Een migratie, het opzetten van een nieuw platform of kennis die intern niet voldoende aanwezig is.

Dat kan technisch ontzettend interessant zijn.

De keerzijde is dat je volgende opdracht niet altijd volledig voorspelbaar is. Zeker binnen detachering hangt veel af van het netwerk van je werkgever en de opdrachten die op dat moment beschikbaar zijn.

Daarom zou ik niet alleen kijken naar het salaris of verdienmodel, maar ook naar het klantennetwerk en hoeveel invloed je daadwerkelijk hebt op je volgende opdracht.

Consultancy / Agency

Consultancy is een breed begrip, maar voor mij zit het belangrijkste verschil in de manier waarop een project wordt uitgevoerd.

Je sluit niet alleen als extra capaciteit aan bij het bestaande team van een klant. Je werkt met je eigen collega's aan een oplossing waarvoor je als team verantwoordelijkheid draagt.

Denk aan het ontwerpen en realiseren van een nieuw dataplatform, het moderniseren van een applicatielandschap, een integratieproject of het vanaf scratch bouwen van een nieuwe applicatie.

Je hebt daardoor wel de afwisseling van verschillende klanten, maar werkt vaker met een vast team van collega's.

Ook kom je regelmatig eerder aan de voorkant van een vraagstuk terecht.

Wat probeert de klant eigenlijk op te lossen? Welke architectuur past daarbij? Welke technische keuzes maken we? En hoe gaan we ervoor zorgen dat het uiteindelijk ook daadwerkelijk werkt?

Dat vraagt soms andere vaardigheden dan alleen technisch sterk zijn. Je moet je denkwijze kunnen uitleggen, met stakeholders kunnen schakelen en begrijpen waarom een organisatie iets wil bouwen.

Dezelfde Developer, een compleet andere werkdag

Neem drie ervaren Software Developers die technisch ongeveer hetzelfde niveau hebben.

De eerste werkt bij een SaaS-bedrijf en kent na vijf jaar bijna ieder onderdeel van het platform. Hij denkt mee over architectuur en weet welke gevolgen technische keuzes op de lange termijn hebben.

De tweede werkt via een detacheerder en heeft in diezelfde vijf jaar bij drie grote organisaties gewerkt. Hij heeft daardoor verschillende architecturen, sectoren en manieren van werken gezien.

De derde werkt bij een consultancy en heeft met vaste collega's verschillende softwareoplossingen voor klanten ontworpen en gebouwd. Hij is gewend om samen verantwoordelijkheid te dragen voor het hele traject: van technische keuzes en architectuur tot de uiteindelijke oplevering.

Waar krijg jij eigenlijk energie van?

Daarom probeer ik tijdens gesprekken veel meer te begrijpen dan alleen welke technologie iemand interessant vindt.

Wil je jarenlang aan één product bouwen en steeds meer ownership krijgen?

Of vind je het juist leuk om iedere paar jaar een compleet nieuwe organisatie te leren kennen?

Wil je vooral technisch de diepte in of vind je het interessant om steeds meer met architectuur en stakeholders bezig te zijn?

Vind je het prettig om onderdeel te zijn van een vast intern team? Wil je met je eigen collega's projecten uitvoeren? Of vind je het juist prima om zelfstandig binnen het team van een klant terecht te komen?

En misschien nog wel belangrijker:

Waar loop je nu op leeg?

Want een volgende stap hoeft niet altijd te betekenen dat je van Java naar Kotlin gaat, van Azure naar AWS of ineens met een compleet nieuwe stack wilt werken.

Soms vindt iemand de technologie nog steeds hartstikke interessant, maar past de omgeving gewoon niet meer.

Technologie blijft natuurlijk belangrijk

Dat betekent niet dat technologie er niet toe doet.

Als jij je technisch wilt ontwikkelen richting bijvoorbeeld distributed systems, security, architectuur of grote hoeveelheden data, moet je natuurlijk wel terechtkomen in een omgeving waar die uitdagingen bestaan.

Maar zelfs dan zou ik verder kijken dan de lijst met technologieën in een vacature.

Hoe complex is het landschap daadwerkelijk? Hoe worden technische keuzes gemaakt? Welke verantwoordelijkheid krijg je? Met wie werk je samen? Wat probeert het bedrijf met technologie op te lossen?

Een moderne tech stack maakt een omgeving niet automatisch interessant.

Welke omgeving past bij jou?

Geen van deze werelden is beter dan de andere.

De één haalt voldoening uit jarenlang bouwen aan hetzelfde product en steeds meer kennis en ownership opbouwen.

De ander krijgt energie van nieuwe organisaties, technische omgevingen en opdrachten.

En weer iemand anders zoekt diezelfde afwisseling, maar wil juist met vaste collega's als team verantwoordelijk zijn voor een concreet eindresultaat.

Daarom is de belangrijkste vraag bij een volgende stap misschien niet alleen:

“Met welke technologie wil ik werken?”

Maar vooral:

“In welke omgeving kom ik het beste tot mijn recht?”

Als je daar eerst antwoord op hebt, wordt het vaak een stuk makkelijker om te bepalen welke bedrijven en rollen daadwerkelijk interessant voor je zijn.