Consultancy is een vaag begrip. Wat betekent het eigenlijk in IT?

Consultancy is eigenlijk een best vaag begrip. Oorspronkelijk betekent het simpelweg: advies geven. Als je het heel letterlijk neemt, zou bijna iedereen in de zakelijke dienstverlening zichzelf consultant kunnen noemen.

In de IT is dat niet anders.

Van internationale organisaties met duizenden medewerkers tot een specialistische club met 25 engineers: allemaal kunnen ze zichzelf consultancy noemen. En soms zit iemand met de functietitel consultant uiteindelijk gewoon vijf dagen per week als externe developer in het team van een klant.

Daarom kijk ik zelf liever naar hoe een organisatie werkt dan naar het label dat erop geplakt wordt.

In mijn ervaring ligt het accent bij detachering vaker op het toevoegen van extra capaciteit aan een bestaand team. Bij consultancy draait het vaker om het oplossen van een vraagstuk of het realiseren van een complete oplossing.

Dat verschil lijkt klein, maar kan voor je dagelijkse werk behoorlijk groot zijn.

Niet alleen capaciteit, maar een oplossing

Stel een organisatie wil een nieuw dataplatform neerzetten.

Bij detachering kan een Data Engineer worden toegevoegd aan het bestaande datateam van de klant. Je werkt vervolgens samen met de medewerkers van die organisatie aan het platform.

Een consultancybedrijf kan het vraagstuk juist als geheel oppakken.

Welk platform past het beste? Hoe moet de architectuur eruitzien? Hoe krijgen we de data uit verschillende systemen op de juiste plek? Hoe richten we security en governance in? En uiteindelijk: hoe zorgen we dat het daadwerkelijk werkt en wordt opgeleverd?

Daarvoor wordt een team samengesteld met bijvoorbeeld engineers, architecten en consultants.

Je bent dan niet alleen verantwoordelijk voor jouw stukje van het project. Het team is samen verantwoordelijk voor de oplossing.

Hetzelfde zie je binnen software development en integratie. Een klant kan één Java Developer nodig hebben om een bestaand team te versterken. Maar een organisatie kan ook een consultancy inschakelen om met een compleet team een nieuw platform te ontwerpen, een bestaand landschap te moderniseren of een complexe migratie uit te voeren.

Dat zijn behoorlijk verschillende manieren van werken.

Samen iets neerzetten

Dat teamaspect is voor veel IT'ers juist een reden om bewust voor consultancy te kiezen.

Je hebt wel de afwisseling van verschillende klanten en projecten, maar werkt niet iedere keer in je eentje binnen een nieuw team.

Je werkt vaker samen met collega's die je al kent.

De ene collega is misschien sterk in architectuur, een ander juist technisch ontzettend goed en weer iemand anders schakelt makkelijk met de klant. Je leert daardoor niet alleen van de technische omgeving van de klant, maar ook continu van je eigen collega's.

En na een project ga je mogelijk met een deel van hetzelfde team door naar het volgende vraagstuk.

Dat kan een interessante middenweg zijn tussen een productorganisatie en detachering: wel verschillende klanten en technische omgevingen, maar toch bouwen met je eigen collega's.

Je komt eerder aan de voorkant van een vraagstuk

Wat ik ook interessant vind aan consultancy is dat je vaak eerder betrokken wordt bij een technisch vraagstuk.

Een klant weet niet altijd precies wat de oplossing moet zijn.

Misschien weten ze dat hun huidige dataplatform niet meer voldoet. Dat verschillende systemen slecht met elkaar communiceren. Of dat een bestaand softwareplatform gemoderniseerd moet worden.

Dan begint het werk niet direct met bouwen.

Eerst moet je begrijpen: wat is eigenlijk het probleem? Wat probeert de organisatie te bereiken? Welke oplossing past daarbij? Welke technische keuzes moeten worden gemaakt?

Dat betekent ook dat andere vaardigheden belangrijker worden naarmate je binnen consultancy groeit.

Je kunt technisch ontzettend sterk zijn, maar je moet je keuzes ook kunnen uitleggen. Je moet met stakeholders kunnen schakelen, begrijpen wat er binnen de business speelt en soms ook durven zeggen dat de oplossing die een klant zelf in gedachten heeft misschien niet de beste is.

Voor iemand die uiteindelijk richting Lead Engineer, Architect of een meer adviserende rol wil groeien, kan dat juist interessant zijn.

Niet elke consultancy is hetzelfde

Daar zit tegelijkertijd een belangrijke nuance.

Bij consultancy denken veel mensen meteen aan de grote internationale organisaties. Die zijn er natuurlijk ook. Vaak met honderden of duizenden consultants, grote enterprise-klanten en internationale projectteams.

Daar kun je aan enorm complexe projecten werken en krijg je toegang tot veel verschillende expertisegebieden.

Maar er zijn ook steeds meer specialistische consultancybedrijven met bijvoorbeeld 20 tot 50 collega's.

Sommige richten zich volledig op Data & AI. Andere op Cloud, Integratie of Software Development.

Vaak zijn dit bedrijven die ontzettend veel kennis hebben binnen één specifieke hoek. Een aantal ervaren engineers of architecten begint samen, krijgt vanuit het eigen netwerk steeds grotere vraagstukken en groeit vervolgens van losse consultancy naar complete projectteams.

De cultuur kan daar totaal anders zijn dan bij een grote internationale consultancy.

Je kent vrijwel iedereen, zit misschien rechtstreeks met de oprichters aan tafel en hebt vaak veel invloed op technische keuzes en de manier waarop projecten worden aangepakt.

Geen van beide is automatisch beter.

Hoe technisch wil je blijven?

Dit zou ik ook altijd proberen uit te vragen.

Want consultant betekent niet automatisch dat je de hele dag technisch bezig bent.

Bij sommige organisaties blijft iemand met tien jaar ervaring nog steeds grotendeels zelf bouwen. Klantcontact en advies komen erbij, maar de technische inhoud blijft de basis.

Bij andere consultancybedrijven verschuift je rol naarmate je seniorer wordt steeds meer richting meetings, stakeholders, architectuur, offertes en het begeleiden van teams.

Voor de één is dat precies de gewenste ontwikkeling.

De ander denkt na drie jaar: ik ben ooit developer geworden omdat ik bouwen juist zo leuk vind.

Daarom zou ik bij een consultancy altijd vragen hoe een senior rol er daadwerkelijk uitziet. Hoeveel tijd ben je technisch bezig? Hoeveel klantcontact heb je? En wat wordt er van je verwacht als je richting Lead of Architect groeit?

En hoe commercieel is je rol?

Ook daarin zitten grote verschillen.

Bij sommige consultancybedrijven hoef je als engineer eigenlijk helemaal niet bezig te zijn met sales. Er is een commercieel team dat projecten binnenhaalt en jij richt je op de inhoud.

Bij andere clubs wordt juist verwacht dat senior consultants kansen herkennen bij klanten.

Niet per se door letterlijk te verkopen, maar wel door mee te denken. Als jij tijdens een project ziet dat er ergens anders binnen de organisatie een probleem speelt, wordt er misschien verwacht dat je dat gesprek aangaat.

Sommige IT'ers vinden dat leuk. Je krijgt meer invloed, bouwt zelf klantrelaties op en bent veel breder betrokken bij de organisatie.

Anderen willen vooral technisch complexe problemen oplossen.

Ook dat is dus iets om vooraf te begrijpen.

Past consultancy bij jou?

Consultancy kan interessant zijn als je energie krijgt van afwisseling, maar niet per se iedere keer als losse externe ergens wilt aansluiten.

Je vindt het leuk om met andere specialisten aan een concreet eindresultaat te werken. Je wilt verschillende organisaties en technische omgevingen zien. En misschien vind je het juist interessant om steeds meer te begrijpen van architectuur, stakeholders en de business achter een technische oplossing.

Maar zoek je vooral volledige ownership over één product? Wil je jarenlang dezelfde omgeving steeds beter leren kennen en de gevolgen van je technische keuzes op lange termijn zien?

Dan kan een productorganisatie juist beter passen.

En wil je vooral maximale vrijheid in het kiezen van opdrachten en vind je het prima om individueel bij een klant aan te sluiten? Dan kan detachering, midlance of freelance weer interessanter zijn.

Daarom zou ik niet te veel waarde hechten aan het woord consultancy op een website of LinkedIn-profiel.

Vraag vooral hoe projecten daadwerkelijk worden uitgevoerd.

Wie is verantwoordelijk voor het eindresultaat? Met wie werk ik dagelijks samen? En wat wordt mijn rol binnen zo'n project?

Dan weet je veel sneller wat voor consultancy je daadwerkelijk voor je hebt.