Prof. Jan Bosch
Vorige week hadden we een strategieworkshop bij het Software Center, het publiek-private samenwerkingsverband voor versnelde digitale transformatie dat ik leid. Tijdens een van de breakout-sessies hadden we een leuke discussie over business agility die een heel herkenbaar patroon illustreerde. In een discussie over hoe je business agility kunt realiseren, lag de focus op wie er verantwoordelijk voor was. En toen werden er meer voorbeelden gedeeld van verschillende mensen en rollen die afstand deden van verantwoordelijkheid dan je met een stok kunt schudden.
In veel opzichten is het de reis van Software Center geweest. We begonnen te werken met software engineers rond Agile practices, maar al snel zeiden de engineers dat de architecten erbij betrokken moesten worden omdat Agility ook invloed heeft op de architectuur. Toen de architecten eenmaal betrokken waren, kwamen al snel de verzoeken om de ontwikkelmanagers bij de discussie te betrekken, aangezien zij de lijnmanagers zijn van zowel de engineers als de architecten. De ontwikkelingsmanagers vroegen natuurlijk al snel om productmanagers erbij te betrekken, omdat zij hun teams alleen maar vertelden dat ze moesten bouwen wat het productmanagement vroeg. Het duurde niet lang nadat we de productmanagers erbij betrokken hadden, totdat ze begonnen te klagen dat we de verkopers erbij moesten betrekken, omdat alles wat we aan de productontwikkelingskant deden door hen verkocht moest worden. De verkopers merkten meteen op dat als we wilden veranderen wat we verkochten, we de C-suite erbij moesten betrekken omdat het een wezenlijke invloed zou hebben op de resultaten. En de C-suite reageerde natuurlijk met het argument dat onze klanten er niet om vroegen en dat onze leveranciers en partners niet bereid waren om met ons samen te werken om deze veranderingen te realiseren.
Wat is hier aan de hand? Nou, het heeft te maken met een column die ik enkele maanden geleden deelde: om iets te veranderen, moet je alles veranderen! En het sluit perfect aan bij ons instinctieve verlangen om alles bij het oude te houden en onze omgeving zoveel mogelijk te controleren.
Er is echter een bijkomend perspectief: de R&D-organisatie in de meeste bedrijven waar ik mee werk beschouwt zichzelf als de plicht om te bouwen wat de zakelijke kant van het bedrijf vraagt. Het probleem is natuurlijk dat de business niet weet wat ze wil totdat het overduidelijk is wat er nodig is en dan willen ze het ook meteen. De nieuwe eisen van de business komen vaak laat en vragen om een onmiddellijk antwoord van R&D.
De realiteit is dat het in de praktijk de R&D-organisatie is die de bedrijfsstrategie voor elke organisatie bepaalt. De ontwerpbeslissingen die genomen worden door sleutelfiguren in R&D maken bepaalde zakelijke kansen onmogelijk duur om na te streven, in termen van kosten en tijd, terwijl andere zakelijke kansen eenvoudig en snel te realiseren zijn. Ondanks al het gepraat over wendbaarheid, kost het realiseren van een belangrijke architecturale verandering in een groot, gevestigd systeem veel tijd, vaak gemeten in kwartalen en jaren. Het gevolg is dat het de verantwoordelijkheid van de R&D organisatie is om de meest waarschijnlijke bedrijfsstrategie opties te voorspellen die het bedrijf een jaar of langer later zal nastreven en de systeemarchitectuur hierop voor te bereiden.
Dit betekent dat als je in R&D werkt, je verantwoordelijkheid moet nemen. Het is jouw taak om een duidelijk beeld te hebben van hoe de toekomst eruit kan zien en ervoor te zorgen dat je een toekomst voor je bedrijf creëert terwijl je de uitdagingen van vandaag aangaat. Het is cruciaal om tweezijdig te zijn en een balans te vinden tussen de korte en langere termijn. De meeste organisaties bouwen hier snel patronen voor op, met de neiging om zich vooral te richten op de korte termijn. Het is jouw verantwoordelijkheid om niet blindelings de gevestigde patronen te volgen, maar om de status quo voortdurend in vraag te stellen. Zoals Andy Grove altijd zei: alleen de paranoïden overleven.
In de meeste organisaties bestaat de neiging om excuses te gebruiken om te verklaren waarom bepaalde veranderingen niet worden gerealiseerd. Een van de meest effectieve excuses is om afstand te doen van verantwoordelijkheid en te wijzen naar anderen in de organisatie als zijnde verantwoordelijk voor het tegenhouden van jou. Zoals het gezegde luidt: je comfortzone is een prachtige plek, maar daar groeit nooit iets. Het is aan ieder van ons om de zwaarste verantwoordelijkheid te dragen die we kunnen dragen en om in een onzekere, onvoorspelbare toekomst te stappen, berekende risico’s te nemen en resultaten te boeken voor vandaag en morgen. Het is aan jou!