Generalist of specialist?

· 15-07-2019
Voor het starten van een tech-bedrijf als Moneybird heb je een brede skill-set nodig. Als founder ben je vaak een manusje van alles; kennis van boekhouden, interface design, software ontwikkeling, server hosting, marketing, support, etc. Naarmate je organisatie groeit komen er mensen bij die werk van je overnemen en ga je nadenken over de functies die er zijn binnen je bedrijf.

De meeste organisaties kiezen er voor om verschillende functies strikt te scheiden. Zo zie je vaak binnen een IT-organisatie een aaneenschakeling van functies zoals UI, UX, front-end development, back-end development en devops. Iedereen voert binnen zijn of haar “specialisme” een taak uit en geeft het werk door aan de volgende persoon die er mee aan de slag gaat.

Het opdelen van een ontwikkelteam in verschillende functies brengt voor- en nadelen met zich mee. Een specialist kan zich met zijn collega’s in dezelfde functie volledig in het domein storten, leert zijn eigen werkwijze en kan vaak ongestoord zijn gang gaan. De diepgang zorgt er voor dat cruciale steunpilaren ontstaan, mensen die écht van de hoed en de rand weten. Deze mensen worden vaak een vraagbaak voor collega’s en vormen een sleutelrol bij belangrijke beslissingen.

Wanneer binnen een klein ontwikkelteam slechts enkele medewerkers per functie zijn, kan het ook bij-effecten hebben die van grote invloed kunnen zijn. Het vormt een voortgangsrisico als een medewerker met een schaars bezet specialisme tijdelijk niet beschikbaar is (door verlof of vakantie) of zelfs vertrekt. Er kan een onnatuurlijke druk op één persoon komen te staan, wat niet wenselijk is.

Onlangs vertelde een bevriende ondernemer me over een medewerker die bijzondere privileges heeft verworven: “Jan is de enige in ons team met kennis van een stuk code dat cruciaal is, hij heeft daarom belangrijke privileges, want als hij vertrekt hebben we een probleem.” Bij mij doet dat de wenkbrauwen fronsen.

En stel, jij bent Jan en je wilt een keer iets nieuws leren? In hoeverre word jij in staat gesteld dat te mogen doen omdat je de enige persoon bent die dat stuk cruciale code snapt en altijd paraat moet staan?

Voor grote organisaties, waar per specialisme tenminste een bezetting is van vier a vijf FTE snap ik het splitsen van functies. Maar voor een relatief kleine organisatie zoals Moneybird bestaat er ook een ander model.

Van specialist naar generalist #

Ongeveer 5 jaar geleden ontstond bij ons de wens om de infrastructuur van managed hosting naar cloud hosting (AWS) te migreren. We liepen steeds vaker tegen de beperkingen aan en voelden de behoefte om in de toekomst eenvoudiger te kunnen opschalen. Om dat te realiseren hadden we alleen wel kennis nodig. We stelden ons daarom de vraag: Gaan we een extern bedrijf inhuren dat voor ons de cloud hosting gaat beheren? Gaan we een nieuwe functie “devops” binnen de organisatie creëren of gaan we als ontwikkelteam de stoute schoenen aantrekken en het beheer van cloud hosting laten doen door de mensen die ook dagelijks aan Moneybird programmeren. Kortom: Durven we onze kennis te verbreden en gezamenlijk een verantwoordelijkheid te nemen?

Als je de tijd neemt om te leren dan lukt veel. En zo geschiedde, na enkele maanden pionieren kregen we dit onderdeel onder de knie. Er ontstond binnen ons team veel kennis over cloud hosting waardoor we ook beter in staat waren optimalisaties te maken in onze applicatie. Vanaf dat moment zijn we steeds meer een strategie gaan voeren waarin we voor vrijwel alles een gedeelde verantwoordelijkheid nemen.

Bij Moneybird hebben we daarom het “ontwikkelteam” waarin mensen zitten die generalistisch denken. Misschien ben je dat niet op dag één als je bij ons binnenkomt, maar we moedigen mensen aan om te ontdekken. Ben je gewend als UI specialist om alleen mock-ups te maken? Dan moedigen we je aan om werkzaamheden aan de frontend te verkennen door HTML, CSS en Javascript te leren. Ben je goed in het beheren van een Kubernetes? Ga dan ook gerust de uitdaging aan om optimalisaties in de database door te voeren. Blijf vooral niet met je vingers overal vanaf!

schematische weergave

We stimuleren mensen omliggende functies te verkennen. Dat betekent niet direct dat iedereen overal kennis van heeft, want interesses en skills verschillen nu eenmaal. Maar door te ontdekken en te verbinden ontstaat veel begrip voor elkaars werk. Mensen delen nieuwe inzichten en houden elkaar scherp, waardoor onderdelen beter op elkaar aansluiten. Samen zijn we verantwoordelijk om mooie dingen te maken.

Het belangrijkste resultaat van deze aanpak is dat de gezamenlijke verantwoordelijkheid ervoor zorgt dat er vrijwel geen onderdelen zijn in Moneybird waar slechts een enkeling kennis van heeft. Als het even kan is niemand onmisbaar en kan iedere Moneybirder met een gerust gevoel op vakantie of verlof, zonder dat je wordt gestoord.

Comfortabel van je eilandje af #

Ik hoor je denken: Maar hoe zorg je er voor dat een backend-programmeur gaat meewerken aan het beheren van de infrastructuur? Natuurlijk gaat dat niet vanzelf. Mensen kunnen, geheel terecht, tegen dit soort uitdagingen opzien. Maar met de juiste mensen om je heen gaat leren vaak makkelijker dan je denkt.

Iedere kwartaal bepalen we opnieuw waar we aan gaan werken. Op de eerste dag van het nieuwe kwartaal staan er drie projecten klaar die we verdelen over het ontwikkelteam. We proberen een zo goed mogelijke inschatting te maken van de benodigde kennis per projectteam om een project tot een succes te maken.

collega's vullen competentielijsten in

Op een groot wit vel papier vullen de kolommen met de skills die nodig zijn voor het project, zo kan voor een project veel kennis van databases nodig zijn, of juist veel boekhoudkennis, of misschien wel diepgaande kennis van devops. Iedere Moneybirder wordt gevraagd om een score aan te geven in hoeverre hij of zij kennis over een onderwerp heeft:

  1. Ik weet bijna niets over dit onderwerp
  2. Mijn kennis is gemiddeld, ik ken de basis
  3. Ik heb veel kennis over dit onderwerp en kan ook anderen op weg helpen

Nadat de matrix volledig is ingevuld vragen we Moneybirders een voorkeur aan te geven voor hun favoriete project. Daarbij is de gedachte: Duik zo af en toe eens in het diepe, durf tenminste eens per jaar een project te kiezen waar je meerdere keren 1 hebt ingevuld! Bij de teamindeling zorgen we ervoor dat er bij iedere kolom tenminste één persoon met een 3 score is. Zo helpen de “3-tjes” de “1-tjes” om op niveau te komen.

Blijven leren en verbinden heeft er bij ons voor gezorgd dat Moneybirders alle onderdelen van de applicatie steeds beter begrijpen en effectiever kunnen werken. In plaats van werk door te geven aan een collega, proberen we het zelf af te maken (en roep je de hulp in van een collega waar nodig). Zo ontwikkelen we met elkaar aan een sterk team!

Misschien vind je dit ook interessant ...