3 leugens die je techteam je vertelt (en zichzelf)

Elk van deze uitspraken is een leugen die je techteam jou — en zichzelf — vertelt. Deze zeer gangbare misvattingen komen voort uit een fundamentele fout die onder engineers endemisch is: het geloof in ‘beter’.

Beter is niet voor iedereen beter

Binnenin een computer is het een wereld van enen en nullen. Er is geen twijfel of onzekerheid over rekenkundige bewerkingen en logische poorten, en afgezien van een enkele kosmische straling is de machine volledig deterministisch: telkens wanneer je dezelfde invoer geeft, volgt hij steeds opnieuw exact hetzelfde pad. 

Zelfs de schijnbare willekeur in games of simulaties is in werkelijkheid een illusie. Als je bijvoorbeeld een bepaalde ‘pseudotoevalszaadwaarde’ aan Minecraft meegeeft, krijg je bij elke speelsessie precies hetzelfde gedrag. Het is goed om te onthouden dat elk lid van je IT-team een beroep heeft gekozen waarin dit niveau van zekerheid en voorspelbaarheid centraal staat; het is letterlijk onmogelijk om hun werk te doen zonder strikt vanuit eerste principes te redeneren.

Maar buiten het computationele domein komen we onvoorspelbare mensen tegen, en is niets meer zeker. Geen enkel verkoopteam zou er zelfs maar aan denken om bij elke potentiële klant dezelfde presentatie of verkooppitch te gebruiken, en elk gesprek met de klantenservice is anders en verrassend. Scripts en trainingen helpen je medewerkers om consistentie te bereiken, zeker, maar het is cruciaal om de aanpak aan elke situatie aan te passen. Dat ontdekten ook veel organisaties toen ze holocratie of leanmethoden probeerden over te nemen om het succes van Zappos en Toyota na te bootsen, maar daar volledig in faalden.

Dit geldt net zo goed voor het bouwen van software als voor bedrijfsvoering, financiën of strategie: er is niet één juiste manier om een inlogscherm te ontwerpen, een rapport te bouwen of te ontdekken voor welke functies klanten willen betalen. Daarom hebben engineers zo’n duizelingwekkende reeks softwaremethodologieën ontwikkeld, zoals Scrum, Kanban, ShapeUp, het Spotify-model, SAfE en honderd andere, die in sommige gevallen succesvol zijn en in andere gevallen rampzalig uitpakken.

Nu zie je waarom wij techneuten ten prooi vallen aan de beterismeval. Ieder van ons zou het aantrekkelijk vinden om te geloven dat ergens een stenen tablet bestaat met het antwoord op al onze problemen erin gebeiteld, maar zekerheid is gevaarlijk verleidelijk wanneer je elke dag werkt met hulpmiddelen en machines waarvan de werking volledig afhankelijk is van absolute consistentie. Maar hoe doorbreek je de gewoonte van binair denken?

Stel eerst onophoudelijk vragen

Voor zo velen van ons is technologie gewoon zwarte magie. De engineers mompelen vreemde bezweringen over Kubernetes en zettabytes, waarna websites, e-mails en creditcardbetalingen uit het niets verschijnen. Dus als de tovenaars ons met gezag vertellen dat ze ‘beste praktijken’ volgen, wie zijn wij dan om daaraan te twijfelen?

Het antwoord ben JIJ! Net als alle andere teamleden hebben softwareontwikkelaars feedback nodig over de vraag of hun plannen en opleveringen op koers liggen voor de bedrijfsstrategie. Je hoeft geen vakjargon te gebruiken om je reacties en aanwijzingen te geven; het is hun taak om genoeg te leren over jouw markt en doelstellingen om tegenover jou verantwoording te kunnen afleggen in standaard-Nederlands. Wees niet bang om alle mogelijke vragen te stellen over wat ze prioriteren, waarom ze voor deze of gene technologie kiezen en vooral hoe ze verwachten dat de rest van het bedrijf daarvan zal profiteren. 

Ik geloof zo sterk in het stellen van vragen dat ik fraaie certificaten met bladgoud heb laten drukken die officieel toestemming geven om engineers over welk onderwerp dan ook vragen te stellen, en ik deel ze uit wanneer ik maar kan. Hieronder zie je een voorbeeld. Als je er een aan je muur wilt, stuur me dan een e-mail en ik stuur er een naar je toe (gratis!) 

Speel vervolgens het waarom-spel

Als je de angst om vragen te stellen hebt overwonnen en meer hebt geleerd over de aanpak van je techteam, is het tijd om het ‘waarom’-spel te spelen. De regels zijn eenvoudig en bekend bij elke vijfjarige: eerst vraag je wat een ontwikkelaar aan het doen is, daarna vraag je herhaaldelijk ‘waarom’. 

“Ik vervang onze betaalpagina.”

“Waarom?”

"Omdat die inefficiënt is.”

“Waarom is die inefficiënt?”

“We voeren overbodige controles uit die onze reactietijden vertragen.”

“Waarom is snelheid belangrijk?”

"Omdat gebruikers afhaken wanneer ze te lang moeten wachten om te betalen.”

Het signaal om te stoppen is wanneer je bij geld uitkomt. Zodra je hoort: “omdat het conversies zal verhogen”, “omdat meer klanten zullen upgraden” of “omdat we de onderzoekskosten drastisch zullen verlagen”, heb je gewonnen. Als je nooit daar komt en eindigt met “Ik weet het niet” of “omdat Jane dat zei,” dan heb jij (niet de ingenieur) het 'waaromspel' verloren. Zoek naar manieren om je technologieteam veel nauwer te verbinden met bedrijfsresultaten, zodat iedereen de volgende keer dat je dit speelt een winnaar is.

Na een paar rondes van waaromvragen begin je patronen en hiaten te zien. Zo werkte ik met een team dat zich volledig richtte op het verhogen van het conversiepercentage, maar de kosten volledig negeerde. Het is dan ook geen verrassing dat ze hun budget ver overschreden met hypergeoptimaliseerde strategieën voor socialemediareclame die veel te ingewikkeld waren voor een eenvoudige kerstcampagne.

Zeker, hun ingewikkelde algoritmen waren “beter” in het behalen van een klein prijsvoordeel op bepaalde zoekwoorden, maar de Facebook-factuur was een harde realitycheck toen die binnenkwam (inclusief kosten voor het daadwerkelijk laten crashen van enkele facebook.com advertentieservers door te veel verzoeken!). Wanneer je zulke blinde vlekken ziet, corrigeer je de prioriteiten, annuleer je wat niet nodig is en benadruk je opnieuw dat de technologie nauw moet aansluiten op je bedrijfsdoelen.

Zorg tot slot voor verantwoording

Nu je de “betere” technologische oplossingen hebt gevonden en verwijderd die in werkelijkheid niet voor je werken, kun je eenvoudige manieren bieden waarop ingenieurs kunnen laten zien dat ze afgestemd en op koers blijven. Merk op dat ik niets zei over “het technologieteam ter verantwoording roepen”, een beschuldigende aanpak waarbij ik me altijd onder het dichtstbijzijnde bureau wil verstoppen. Stel je ontwikkelaars in plaats daarvan in staat om tegenover jou verantwoording af te leggen. Bijvoorbeeld:

• Plan wekelijks een demonstratie van IT-verbeteringen, waarbij teamleiders de zakelijke voordelen beschrijven en feedback van jou en anderen ontvangen.
• Stel een dashboard in met belangrijke meetwaarden, zoals systeembeschikbaarheid of beantwoorde oproepen, en vraag ontwikkelaars regelmatig uit te leggen hoe hun acties de resultaten verbeteren.
• Maak een geleidelijke route om de voortgang van belangrijke projecten te volgen en snel te herstellen wanneer belangrijke onderdelen vertraging oplopen.

Een duidelijke strategie voor regelmatige feedback en een focus op echte, tastbare bedrijfsvoordelen zorgen ervoor dat je IT-uitgaven niet worden verspild aan slimme maar nutteloze “betere” projecten. En als je, net als de meeste bedrijven waarmee ik werk, miljoenen uitgeeft aan technologie met op zijn best onduidelijke resultaten, is het dan niet de moeite waard om het rendement op die enorme investering te meten?

Abonneer je op de nieuwsbrief van The CTO Club voor meer advies uit onze community.