Categorie: Blogs

Een managementconsultant vraagt:

In mijn werk heb ik te maken met meerdere projecten van verschillende klanten. Die afwisseling maakt het werk spannend, maar de stapel memo’s en rapporten wordt te veel. Als ik ’s avonds naar huis ga, heb ik niet kunnen doen wat ik had gepland door alle telefoontjes, e-mails en vergaderingen. Het is erg frustrerend en ik krijg steeds vaker commentaar op het niet halen van deadlines. Hoe schep ik orde in deze chaos?

De communicatietrainer antwoordt:

De theorie over prioriteiten stellen is eenvoudig, maar het toepassen ervan is o zo lastig. Waarom? Omdat er veel factoren tegelijk spelen die van persoon tot persoon en van werkplek tot werkplek verschillen en bovendien voortdurend veranderen. Belangrijke factoren zijn bijvoorbeeld de dynamiek van het werk, de mate waarin je kunt delegeren, het niveau van de mensen om je heen en natuurlijk je eigen persoonlijkheid. Persoonlijke neigingen, die het je moeilijk kunnen maken, zijn perfectionisme (‘nooit afmaken, want het moet 110 procent goed’), pleasen (‘als ik zeg dat ik het niet doe, vindt hij me niet meer aardig’), rampdenken (‘als ik een fout maak, gaat het vreselijk mis, dus stel ik uit’), enthousiasme (‘ik vind alles leuk, afmaken is iets waar ik minder goed in ben’) en behulpzaamheid (‘ik help graag mensen, dus aan mijn eigen werk kom ik nauwelijks toe’). Al deze persoonlijke factoren in combinatie met alle voortdurend veranderende omstandigheden maken dat je voortdurend bewust en actief bezig moet zijn met het stellen van prioriteiten.

Hoe doe je dat? In het kort, de theorie. De prioriteit van een taak wordt bepaald door de factor ‘belangrijkheid’ en de factor ’tijd’. Of iets belangrijk is, hangt in de eerste plaats af van je kerntaak. Waar word je voor betaald? Stel dat je architect bent, dan is werken aan de architectuur van een machine belangrijk. Een vergadering regelen of een berekening maken die misschien een ingenieur zou kunnen doen, is minder belangrijk. Vervolgens controleer je de urgentie. Moet het snel gebeuren of kan het nog even wachten? En voor hoe lang?

Op basis van deze twee criteria beslis je hoeveel tijd je aan een taak besteedt en wanneer. Is het belangrijk en dringend? Dan doe je het nu en goed. Als het belangrijk en niet dringend is, kun je het werk inplannen of een begin maken. Is het niet belangrijk maar wel dringend? Laat iemand anders het werk doen of besteed er zelf zo weinig mogelijk tijd aan. Niet belangrijk en niet dringend? Negeer ze!

Ga eens bij jezelf na: wat geeft de meeste druk, urgentie of belang? Juist, urgentie. We worden geleefd door de waan van de dag. We geven toe aan druk. Iemand aan je bureau, een e-mail, alles vraagt nu om aandacht. Sommige van die dingen moet je doen om de zaak draaiende te houden, maar andere zijn tijdverspilling. De tijd die je hierdoor verliest, kom je tekort voor het uitvoeren van de belangrijke taken, die daardoor ook urgent worden.

Prioriteiten stellen vereist dus een actieve houding en regelmatig nee verkopen, maar met een rechtvaardiging. De aanpak is als volgt.

1) Maak voor jezelf een lijst van de belangrijkste en moeilijkste taken die je echt moet doen.

2) Zorg ervoor dat je tijd vrijmaakt in je agenda om deze taken uit te voeren en wees bereid om dit met hand en tand te verdedigen.

3) Zorg ervoor dat je genoeg tijd overlaat voor allerlei ’tussendoor’-dingen (gemiddeld dertig procent).

4) Wees bereid om je agenda en planning op elk moment aan te passen als dat nodig is.

Een laatste advies: maak een realistische planning en communiceer wat je wel en niet kunt doen. Zo word je een betrouwbare collega. De wereld draait niet volgens jouw schema. Je zult voortdurend flexibel moeten zijn, maar verlies nooit je hoofddoelen uit het oog.

Vorige week organiseerden we de sprint 19 rapportage workshop van Software Center. De opening keynote van Frances Paulisch (Siemens Healthineers) ging over de transitie van een transactioneel business model naar continue waarde levering aan klanten. De afsluitende keynote van Aleksander Fabijan (Microsoft) ging over het starten en opschalen van A/B-testen. Hoewel de keynotes zich richtten op zeer verschillende onderwerpen, deelden ze een gemeenschappelijk thema.

Dit thema ging over het aansturen van verandering en de uitdaging om de verandering succesvol te implementeren. Zowel Frances als Aleksander brachten naar voren dat de meeste veranderingen in organisaties veel individuen, functies en afdelingen raken, evenals talloze processen en manieren van werken. Zoals ik in eerdere posts heb besproken, moet je in de meeste organisaties alles veranderen om iets te veranderen. Het is echter onmogelijk om alles tegelijkertijd volledig te veranderen. En dit is waar ik veel organisaties zie vastlopen.

De weg hieruit is accepteren dat alle verandering geleidelijk zal moeten gaan en dat in plaats van de verandering in één klap te realiseren, het een continu proces zal moeten zijn gedurende een langere tijd. De analogie is die van een vliegwiel. Om een vliegwiel van volledige stilstand naar ten minste enige rotatie te krijgen, is behoorlijk wat energie nodig. Zodra er enige beweging is, moet je kracht blijven uitoefenen om sneller te gaan. Maar als er eenmaal meer snelheid is, wordt het steeds makkelijker om die snelheid vast te houden. De vraag is hoe we dat in organisaties bereiken. In mijn ervaring zijn er drie belangrijke aspecten: de waarde laten zien, de betrokkenheid vergroten en infrastructuur opbouwen.

Ten eerste, om de waarde te laten zien, moet je een klein gebied vinden waar succes vrijwel gegarandeerd is, maar waar de waarde van de verandering die je wilt bereiken duidelijk wordt aangetoond. Omdat je dit in eerste instantie allemaal moet realiseren met een klein team, is het belangrijk om datgene wat je wilt bereiken zoveel mogelijk binnen jouw bereik te houden om het risico te minimaliseren dat anderen je inspanningen torpederen. Als je bijvoorbeeld je eerste A/B-experiment uitvoert, kies dan een onderwerp waarover de meningen in de organisatie sterk uiteenlopen, zorg voor de kwaliteit van de gegevens van het A/B-experiment en gebruik deze om in gesprek te gaan met relevante belanghebbenden om te laten zien hoe de gegevens van het experiment de organisatie ten goede komen.

Ten tweede, als je eenmaal een succesvolle case hebt, betrek dan de belanghebbenden die je moet overtuigen om de reikwijdte van de verandering te vergroten en laat de echte, concrete, tastbare voordelen zien die je in de eerste lus hebt gecreëerd. Gebruik dit om de betrokkenheid te vergroten bij de mensen die je nodig hebt in de volgende iteratie van het vliegwiel om de volgende showcase te creëren. Wanneer je bijvoorbeeld de releasefrequentie van software verhoogt op weg naar DevOps, kan in het begin vaak de mogelijkheid om defecten snel in het veld op te lossen gemakkelijk worden gebruikt als een middel om het bewustzijn en de buy-in bij relevante belanghebbenden te vergroten.

Ten derde, zoek naar manieren om sommige van de activiteiten die je tot nu toe handmatig hebt uitgevoerd te automatiseren, zodat na verloop van tijd de kosten van het doorlopen van de iteraties van het vliegwiel lager worden. Dit heeft te maken met het opbouwen van de infrastructuur voor de verandering die je wilt realiseren. Voor A/B-testen kan dit betekenen dat je delen van de gegevensverzamelingspijplijn automatiseert en voor het invoeren van DevOps vereist dit meestal het automatiseren van de CI/CD-pijplijn en de testinfrastructuur.

Als je eenmaal de eerste iteratie van het vliegwiel hebt doorlopen, is het eigenlijk afspoelen en herhalen om de volgende stap te zetten en te proberen te versnellen. Het is makkelijk om ontmoedigd te raken als je dit probeert, maar vergeet niet dat vliegwielen heel langzaam versnellen en veel energie nodig hebben om überhaupt in beweging te komen. En in het begin, omdat alles handmatig moet gebeuren, heeft het vliegwiel veel weerstand. Met meer en meer van de infrastructuur op zijn plaats, draait het steeds gemakkelijker.

Veel van de bedrijven waar ik mee werk worstelen met het realiseren van de veranderingen die nodig zijn in hun organisatie. Sommige schommelen tussen het proberen te realiseren van een big-bang verandering en een complete impasse waarin niets gebeurt. De meest effectieve manier om verandering te realiseren is het aanhoudend, misschien langzaam, maar continu versnellen van het vliegwiel door waarde te laten zien, belanghebbenden te betrekken en infrastructuur op te bouwen. Accepteer dat het tijd kost en begin daarom gisteren in plaats van morgen. Bouw je vliegwiel en laat het draaien!

Omdat het vorige week Thanksgiving was in de VS, wilde ik even stilstaan bij het begrip schaarste en overvloed. Velen in het bedrijfsleven werken met een schaarste-mentaliteit, in de overtuiging dat eigenlijk alles wat ons bezighoudt slechts in beperkte hoeveelheden beschikbaar is. Of het nu gaat om het ‘binnenhalen’ van een klant, promotie of het krijgen van een project waar je om hebt gevraagd, de basisaanname is dat of iemand anders het krijgt of jij het krijgt. Het is een win-verlies situatie.

De reden hiervoor is natuurlijk te vinden in de evolutie van de mens. Gedurende de honderdduizenden jaren dat de voorgangers van de moderne mens op aarde rondzwierven, werd alles gedreven door schaarste. Voedsel was schaars, veilige plekken om te wonen waren schaars, mensen om veilig mee samen te werken waren schaars, enzovoort. En dit vertaalt zich in veel van onze huidige gedragingen in de maatschappij. Bij voetbalwedstrijden wint het ene team en verliest het andere. In televisieshows is er één winnaar. In computerspellen doorlopen de battle royale-spellen opeenvolgende gevechtsronden tot er nog maar één speler over is.

Voor vrijwel iedereen in de westerse wereld is schaarste grotendeels een illusie. We hebben allemaal toegang tot voedsel, een veilige plek om te wonen, toegang tot gezondheidszorg, bescherming tegen bedreigingen, enzovoort. Met de theorie van Maslov als basis, wordt er grotendeels voorzien in onze fysiologische en veiligheidsbehoeften en deze basisbehoeften waren historisch gezien waar schaarste bestond. Onze psychologische behoeften en behoeften aan zelfvervulling zijn meestal niet waar schaarste een probleem is. Als iemand anders een relatie aangaat, vermindert dat niet jouw kansen om een relatie aan te gaan. Als een collega van mij een artikel publiceert, heeft dat geen invloed op mijn mogelijkheden om een artikel te publiceren.

In onze economie en ons bedrijfsleven hebben we dezelfde misvatting van schaarste. De meeste mensen lijken te missen dat de economie voortdurend groeit. Groei van het BBP betekent dat er meer waarde, met geld als proxy, wordt gecreëerd door een economie. Die waarde en dat geld betekenen niet dat een land moest verliezen om een ander land te laten winnen. Op een bepaalde manier creëren we waarde en geld ‘uit het niets’ (zie Wikipedia voor een langere verkenning van dit onderwerp). Dankzij de digitalisering van de samenleving is steeds meer van die waarde digitaal, zoals blijkt uit de waarderingen van technologiegiganten als Microsoft, Facebook en Google. En daardoor zijn de fysieke hulpbronnen van onze planeet steeds minder de bron van waardecreatie, wat een goede zaak is vanuit milieuperspectief.

Het punt dat ik probeer te maken is dat we in een tijdperk van overvloed leven. Voor de meesten van ons geldt dat we vrijwel al onze levensenergie kunnen steken in zelfverwerkelijking en het creëren van een positieve impact op de wereld waarin we leven. We kunnen dit doen door middel van werk, vrijwilligerswerk, relaties, gemeenschapswerk, politiek of wat dan ook. Maar we moeten de wereld om ons heen bekijken door de lens van overvloed, in plaats van de lens van schaarste.

In het bedrijfsleven betekent dit dat een concurrent of partner die het goed doet, niet betekent dat je kansen mist om het goed te doen. Sterker nog, verschillende startups waar ik bij betrokken ben vieren het wanneer bedrijven in dezelfde sector het goed doen, omdat het betekent dat de taart groter wordt. Vooral voor nieuwe bedrijven is het niet de concurrentie waar het om gaat, maar het overwinnen van niet-consumptie, bijvoorbeeld bedrijven die pen en papier blijven gebruiken in plaats van de handige tool die jij hebt gemaakt. Dus, in plaats van te concurreren op het scherpst van de snede met een schaarste-mentaliteit, zoek naar manieren om win-winsituaties te creëren en neem een overvloed-mentaliteit aan. Er is meer dan genoeg voor ons allemaal. Jouw groei helpt mijn groei alleen maar!

Velen die dit lezen zullen ongetwijfeld wijzen op alle pijn en lijden die nog steeds in de wereld bestaan en ik wil dat niet negeren of onder het tapijt vegen. Maar het is een feit dat vrijwel elke metriek met betrekking tot de kwaliteit van leven in de wereld, variërend van oorlogsdoden en mensen die in armoede leven tot kindersterfte en levensverwachting, verbetert en de mensheid heeft nog nooit in een betere tijd geleefd. We leven in het tijdperk van overvloed en ondanks alle problemen in de wereld van vandaag, denk ik dat het goed is om dat te onthouden en er dankbaar voor te zijn.

Deze week was ik aanwezig bij de International Conference on Software Business(ICSOB 2020) en gaf ik een presentatie over autonoom verbeterende systemen. De kerngedachte is dat software-intensieve systemen hun prestaties kunnen meten, weten waarvoor ze moeten optimaliseren en autonoom kunnen experimenteren met hun eigen gedrag.

De geschiedenis van software-intensieve systemen kan worden verdeeld in drie hoofdfasen. In de eerste fase bouwden we systemen volgens een specificatie. Deze specificatie kon afkomstig zijn van de klant of van productmanagers, maar het doel van het R&D team was om een systeem te bouwen dat voldeed aan de eisen in de specificatie.

Veel online bedrijven, maar ook de eerste embedded-systems bedrijven, bevinden zich in de volgende fase. Hier krijgen teams geen specificatie, maar eerder een set van één of meer geprioriteerde KPI’s om te verbeteren. In e-commerce is conversie vaak de belangrijkste KPI; in embedded systemen wordt vaak een gewogen mix van prestatie, betrouwbaarheid en andere kwaliteitsattributen gebruikt. Teams krijgen als doel een of meer van deze KPI’s te verbeteren zonder de andere (significant) te verslechteren. Ze moeten hypotheses hierover ontwikkelen en deze in het veld testen met behulp van bijvoorbeeld A/B-experimenten.

Hoewel de tweede fase voor veel bedrijven een grote stap voorwaarts is, is het probleem dat het nog steeds het team is dat al het zware werk doet. Vooral het uitvoeren van veel A/B-experimenten kan veel moeite kosten. De volgende stap die sommige bedrijven beginnen te verkennen is om het systeem zijn eigen experimenten te laten genereren met de bedoeling te leren over manieren om zijn eigen prestaties te verbeteren. Theoretisch valt dit in de categorie van reinforcement learning, maar het blijkt een hele uitdaging om dit in een empirische, industriële context te realiseren.

De evolutie die bedrijven doormaken om dit derde stadium te bereiken, kan in een model worden gezet, dat de activiteiten en technologieën toont die op elk niveau kunnen worden gebruikt. Vanaf niveau 2 zien we een aantal autonoom verbeterende systeemgedragingen, zoals het toevoegen van intelligente, online selectie van experimenten en het automatisch genereren van experimenten. Dit resulteert in allerlei uitdagingen, waaronder het voorspellen van de slechtste prestaties van de gegenereerde alternatieven. Als een systeem autonoom experimenten genereert en inzet, kunnen sommige van deze experimenten zeer slechte prestaties laten zien, wat betekent dat het systeem modellen nodig heeft om de slechtste uitkomst voor elk experiment te voorspellen, evenals oplossingen om lopende experimenten te annuleren als de prestaties negatief worden beïnvloed.

Met de toenemende prevalentie van AI moeten we beginnen te kijken naar online reinforcement learning in software-intensieve systemen, omdat dit het autonoom verbeteren van systemen zou vergemakkelijken. Deze ambitie gaat gepaard met grote uitdagingen die we nu aan het onderzoeken zijn. Ik moedig je echter aan om te onderzoeken waar de systemen die je bouwt autonoom hun eigen gedrag zouden kunnen verbeteren. Zelfs beginnen in een klein, risicovrij hoekje van het systeem kan heel nuttig zijn om dit paradigma te leren kennen. Het algemene doel is dat elke dag dat ik je product gebruik, ik wil dat het beter wordt!

Onlangs, in een gesprek met een bedrijf over datagedreven worden, liep ik tegen dezelfde uitdaging aan als zo vaak: het bedrijf beweert zoveel gegevens te verzamelen, maar de hoeveelheid waarde die uit die gegevens wordt gegenereerd is erg klein. Je vraagt je af wat er ten grondslag ligt aan deze patronen van, ogenschijnlijk, enorme hoeveelheden gegevens die worden verzameld, maar heel weinig van die gegevens die worden gebruikt om iets van waarde te creëren. Mijn ervaring is dat er ten minste drie factoren een rol spelen: gevoel van eigenaarschap, lokale optimalisatie en de kosten van het ‘produceren’ van gegevens.

Een typisch patroon in veel organisaties is dat teams die gegevens genereren en verzamelen voor hun doeleinden, zich sterk eigenaar voelen van die gegevens en niet willen dat anderen met hun grote, dikke vingers aan “hun gegevens” komen peuteren. Het is van hen en als iemand anders soortgelijke gegevens nodig heeft, kunnen ze die zelf gaan verzamelen in plaats van ze gratis van het team te krijgen.

Dit leidt tot veel kleine eilandjes van gegevens die volledig losgekoppeld zijn en niet samenkomen in iets dat waardevoller is dan de som der delen. Teams kunnen opscheppen over al hun gegevens, maar niemand anders kan ze gebruiken.

Elk team dat besluit dat ze gegevens nodig hebben om de kwaliteit van hun beslissingen te verbeteren, zal zich richten op hun eigen uitdaging en alleen verzamelen wat ze nodig hebben op het niveau van detail, frequentie en aggregatie dat ze nodig hebben. Bovendien kunnen ze op elk moment beslissen om de manier waarop gegevens worden verzameld en welke gegevens worden verzameld fundamenteel te veranderen.

Het gevolg is dat de gegevens meestal moeilijk te gebruiken zijn buiten de onmiddellijke context waarvoor ze gegenereerd werden. Dit leidt ertoe dat verschillende teams zeer gelijkaardige gegevens verzamelen door een gebrek aan coördinatie. Ook kunnen teams die zich realiseren dat ze gegevens nodig hebben, omdat weinig teams nadenken over het bredere gebruik, de bestaande gegevens niet hergebruiken omdat ze zo specifiek zijn voor de use case waarvoor ze zijn verzameld.

Als een team besluit om zijn gegevens beschikbaar te stellen voor anderen, moet het documentatie over de semantiek van de gegevens verstrekken, een systeem opzetten voor het vinden en downloaden van gegevenssets, ervoor zorgen dat wijzigingen in de manier waarop gegevens worden verzameld, de semantiek, enzovoort, zorgvuldig worden gecommuniceerd met belanghebbenden en natuurlijk reageren op verzoeken van deze belanghebbenden en wijzigingen aanbrengen in de gegevensverzamelingsprocessen, niet om er zelf beter van te worden, maar om anderen in de organisatie te helpen. En, last but not least, kan het team gemakkelijk verantwoordelijk worden gehouden voor privacy, GDPR, beveiliging en andere zorgen die bedrijven hebben rond de opgeslagen gegevens.

Het gevolg is dat, tenzij er een tegenkracht aanwezig is, teams actief zullen proberen om gegevens niet te delen vanwege de moeite en de kosten van het delen met anderen in de organisatie. Dit leidt weer tot veel gegevens die worden vastgelegd, opgeslagen en gebruikt voor specifieke, smalle use cases, maar geen synergie, geen end-to-end begrip van systemen in het veld en de manier waarop klanten ze gebruiken, enzovoort.

De oplossing voor deze uitdagingen is een hiërarchische benadering van waardemodellering waarbij je top-down bedrijfs-KPI’s verbindt met meetgegevens op een lager niveau die direct uit het veld kunnen worden verzameld. Door deze hiërarchische, acyclische, gerichte grafiek op te bouwen en de relatie tussen factoren op hoger en lager niveau kwantitatief vast te stellen, kunnen we eindelijk beginnen met het genereren van bedrijfswaarde uit alle gegevens die we verzamelen.

Het is niet eenvoudig om van de huidige staat naar dit hiërarchische waardemodel te gaan, al was het maar omdat de meeste mensen in de bedrijven waar ik mee werk het extreem moeilijk vinden om te bepalen voor welke kwantitatieve factoren we optimaliseren, en als we het al weten, is de relatieve prioriteit van deze factoren een bron van aanzienlijke discussie. Het biedt echter enorme voordelen, omdat je het verzamelen van gegevens kunt richten op de dingen die er toe doen, de gegevens kunt gebruiken om beslissingen van hogere kwaliteit te nemen en op gegevens gebaseerde aanbiedingen aan klanten kunt doen die je anders niet had kunnen doen. Zoals het gezegde luidt: het gaat er niet om wat je hebt, maar hoe je het gebruikt!

Een ingenieur vraagt:

Ik werk al vele jaren als chief design engineer. Toch krijg ik regelmatig te horen dat ik beter moet communiceren. Inmiddels ben ik op het punt gekomen dat ik wat verbeteringen wil aanbrengen, maar wat bedoelen ze precies met “beter communiceren” en hoe doe ik dat?

De communicatietrainer antwoordt:

Goede communicatievaardigheden zijn nodig om goed samen te werken in complexe projecten. Het komt erop neer dat je weet hoe je een boodschap geeft en hoe je de informatie die iemand anders je geeft op de juiste manier ontvangt. De noodzakelijke voorwaarde om dit te laten slagen is contact tussen zender en ontvanger.

Contact maak je door aandacht te besteden aan de persoon met wie je praat. Je moet dus interesse tonen in de ander. Als de ander ook aandacht voor jou heeft, is het contact gelegd. Vergelijk het met het bellen van een collega. Op het moment dat de verbinding er is en de lijn geruisloos is, kun je dingen gaan bespreken.

Door actief te luisteren, zorg je ervoor dat je de boodschap van de ander begrijpt. Dit doe je door toe te passen: luisteren, samenvatten en vervolgvragen stellen. Luisteren betekent aandacht hebben voor de ander. Je vat samen door bijvoorbeeld te zeggen: “Oké, ik begrijp dat …” of “Oké, ik hoor je dit en dat zeggen, klopt dat?”. De andere persoon hoort wat je hebt geleerd en krijgt de bevestiging dat je het goed hebt begrepen, of hij heeft de gelegenheid om wat correcties aan te brengen of het niveau van zijn uitleg aan te passen aan het niveau van jouw begrip. In beide gevallen is dit prettig voor degene die vertelt en schept het duidelijkheid.

Wanneer je je boodschap verstuurt, is het belangrijk om zo concreet mogelijk te zijn. Kwantificeer waar je kunt. Dit maakt je verhaal altijd beter. Stem je verhaal af op het begripsniveau en de focus van de ander. Wat wil de ander weten? Waarschijnlijk is je projectmanager vooral geïnteresseerd in de planning, risico’s of kosten en minder in technische details. De salesmanager is waarschijnlijk meer geïnteresseerd in de gevolgen voor zijn klant dan in het probleem zelf. Je kunt dit van tevoren inschatten en er rekening mee houden in je verhaal.

Maar nu het belangrijkste. Het spel van zenden en ontvangen verloopt zelden soepel. Simpelweg omdat we allemaal ons eigen referentiekader hebben en elkaar dus niet meteen begrijpen. Het is daarom uiterst belangrijk dat je altijd oplet of je boodschap overkomt en dat je reageert als dat niet zo is.

Je merkt dat je boodschap overkomt als de ander aandachtig naar je verhaal luistert en misschien af en toe instemmend knikt. Als de ander echter plotseling van houding verandert, fronst of iets begint te zeggen, kan dit een teken zijn dat je boodschap niet goed overkomt. Het kan zijn dat de ander iets niet begrijpt, een interessante associatie heeft of het er niet mee eens is. Je weet het pas als je het controleert.

En dat laatste is dus wat je moet doen. Doorgaan met je eigen verhaal terwijl de ander afdwaalt in zijn eigen gedachten bereikt weinig. Op het moment dat je merkt dat er iets gebeurt met de aandacht van de ander, draait de communicatie honderdtachtig graden en schakel je over van zenden naar ontvangen. Je vraagt: ”Ik zie je fronsen, vertel …” of ”Wil je iets zeggen, vertel …”. Op deze manier schommelt de communicatie heen en weer en kom je snel tot helderheid.

Moet je onmiddellijk stoppen met je verhaal bij elke spier die de ander vertrekt? Nee, maar het is wel aan te raden om je altijd bewust te blijven van de reactie van de ander op je verhaal terwijl je het vertelt. Check het in ieder geval om de zoveel tijd door te vragen: “Hoe klinkt het tot nu toe? Op die manier nodig je de ontvanger van je boodschap uit om te reageren en krijg je feedback over hoe je verhaal is aangekomen.

 

De afgelopen weken ben ik met verschillende bedrijven in gesprek geweest en hetzelfde probleem deed zich voor: mijn contactpersonen stelden een verandering aan de orde die ze in hun organisatie wilden realiseren en vroegen me om hulp bij het realiseren ervan. Toen ik vroeg hoe ze in de situatie terecht waren gekomen die deze verandering noodzakelijk maakte, waren de meesten stomverbaasd – het was duidelijk dat ze hier niet aan hadden gedacht.

Natuurlijk zijn we als ingenieurs getraind om in oplossingen te denken en velen van ons volgen die training op de voet. Het ontwikkelen van een oplossing voor een probleem dat eigenlijk een symptoom en het gevolg van iets anders is, is echter volkomen nutteloos omdat de kans dat de oplossing iets oplost net zo groot is als de overlevingskans van een sneeuwvlok in de hel.

Verschillende R&D-afdelingen willen bijvoorbeeld continuous deployment of DevOps introduceren in hun bedrijf, maar stuiten op sterke weerstand van sales en customer support. Velen klagen dat de mensen aan de andere kant van het hek het gewoon niet snappen. Als je de situatie echter analyseert, is het duidelijk dat de introductie aanzienlijke kosten met zich meebrengt en een fundamenteel andere relatie met klanten. En zonder een businessmodel om de continue levering van waarde te gelde te maken, heeft het geen zin om DevOps in te voeren. Dus, in plaats van te benadrukken dat de mensen aan de zakelijke kant idioten zijn, werk samen met hen om uit te zoeken hoe je bedrijfsmodellen en klantbetrokkenheidsmodellen kunt creëren die zinvol zijn en werk vervolgens samen met leidende klanten om te experimenteren met dit nieuwe model.

Velen kennen de “regel van 5 waarom’s”: het idee om na het observeren van een probleem vijf keer “waarom” te vragen om van de waargenomen symptomen naar de werkelijke hoofdoorzaken te gaan. De uitdaging is dat deze regel in de praktijk lang niet zo vaak wordt gevolgd als zou moeten.

Een verwante en volgende uitdaging is dat zelfs als we de hoofdoorzaak hebben geïdentificeerd en een idee hebben om het op te lossen, er een enorme weerstand in de organisatie is om alles te implementeren wat nodig is om daadwerkelijk vooruitgang te boeken. In plaats daarvan is er de neiging om de implementatie van iets kleins te ondersteunen, zodat het voor iedereen in het bedrijf aanvaardbaar is. Het resultaat is vaak een verwaterd en verkleind voorstel dat brede steun krijgt, maar dat weinig meer biedt dan een symbolische inspanning met weinig echte impact op het bedrijf. In het algemeen is mijn ervaring dat hoe meer een organisatie gepolitiseerd is, hoe meer ze geneigd is zich te richten op symptomen in plaats van op de hoofdoorzaken en hoe meer ze geneigd is zich te richten op verwaterde veranderingsinitiatieven die de illusie van actie wekken maar niet leiden tot echte verandering.

Mijn advies ligt voor de hand. Gebruik eerst je intelligentie en ervaring om een goed begrip te ontwikkelen van de onderliggende oorzaken van waargenomen verschijnselen. Trap niet in de val om te geloven wat iedereen gelooft. Ten tweede, gebruik je sociale en interactievaardigheden om je begrip met anderen te bevestigen en een gemeenschappelijk platform op te bouwen van een op de onderliggende oorzaken gericht begrip. Ten derde, als je eenmaal een gemeenschappelijk begrip hebt vastgesteld, onderzoek dan meerdere (in plaats van slechts één) wegen om de geïdentificeerde hoofdoorzaak aan te pakken en bouw een platform op voor de weg die de vereiste impact heeft terwijl de bijkomende schade tot een minimum wordt beperkt. Ten vierde, als er voldoende overeenstemming is, ga dan verder met de uitvoering op een iteratieve, experimentele manier waarbij je één end-to-end deel van de organisatie door de verandering haalt, de impact observeert en meet, dienovereenkomstig aanpast en verder gaat met het volgende deel. Vind gedurende dit alles de juiste balans tussen het aansturen en toegewijd zijn aan het realiseren van de verandering en een objectieve, reflectieve houding waarbij je in staat bent om de nadelen van de verandering en de noodzaak voor aanpassing waar nodig te identificeren.

Zoals de boeddhisten zeggen, ligt het verschil in het kleine venster tussen trigger en reactie. In plaats van instinctief te reageren op wat het leven je voor de voeten werpt, sta je even stil, denk je na en neem je een beslissing over een actie die daadwerkelijk resulteert in wat je wilt bereiken. Met andere woorden, denk in plaats van te reageren.

Onlangs heb ik als expert een workshop verzorgd bij een bedrijf dat datagedreven wilde worden. Anders dan de productbedrijven waar ik normaal gesproken mee werk, is dit bedrijf een dienstverlener met een groot aantal medewerkers die diensten aanbieden aan klanten. Tot de deelnemers aan de workshop behoorden de CEO en het hoofd bedrijfsontwikkeling, evenals verschillende anderen die deel uitmaken van het managementteam van het bedrijf of daar dicht bij staan.

In veel opzichten lijkt dit de ideale opstelling te zijn, omdat je ervan uitgaat dat we alle managementondersteuning hebben die we nodig hebben en een aantal van de slimste mensen in het bedrijf bij ons hebben. Dit werd zelfs versterkt doordat verschillende mensen in het bedrijf vertelden dat ze al heel lang met gegevens werken. Desondanks liepen we tegen een aantal aanzienlijke uitdagingen aan en kwamen we lang niet zo ver als we hadden gehoopt.

De eerste uitdaging was om concreet te worden over specifieke hypotheses om te testen. Hoewel we concrete voorbeelden van hypotheses en bijbehorende experimenten deelden toen we begonnen met brainstormen en teamwerk, had iedereen het ongelooflijk moeilijk om van een doel op hoog niveau, het verhogen van een specifieke bedrijfs-KPI, bijvoorbeeld klanttevredenheid, naar een specifieke hypothese en een bijbehorend concreet experiment te gaan. Daar zijn veel redenen voor. Een voor de hand liggende is dat veel mensen vinden dat ‘iemand’ ‘iets moet doen’ aan datgene waarover ze zich zorgen maken, maar nooit veel hersencycli besteden aan het nadenken over hoe dat eruit zou zien.

De tweede uitdaging was dat voor alle gegevens die het bedrijf tot zijn beschikking had, de gegevens die relevant waren in de betreffende situatie vaak niet beschikbaar waren. Veel bedrijven waar ik mee werk beweren dat ze heel veel gegevens hebben en velen in de organisatie zijn dan echt verbaasd dat ‘gewoon’ de gegevens die ze nodig hebben niet zijn vastgelegd. Als je erover nadenkt, ligt het voor de hand dat dit het geval zou zijn, aangezien het aantal hypotheses dat je kunt formuleren vrijwel oneindig is en de kans dat gegevens niet beschikbaar zijn dus vrij groot is.

De derde uitdaging waar we tegenaan liepen was dat zelfs in de gevallen waarin de gegevens beschikbaar waren, deze geaggregeerd bleken te zijn en/of een te lage registratiefrequentie hadden om relevant te zijn voor het doel dat we voor ogen hadden. Dus, we hebben de gegevens, maar ze zijn in een vorm die niet de analyse mogelijk maakt die we willen doen.

De reactie op deze uitdagingen is, zoals je zou verwachten, erop uit gaan en verzamelen wat we nodig hebben om het experiment voort te zetten om tot een bevestiging of verwerping van de hypothese te komen. Het grappige besef dat ik had, is dat hoe relevanter en belangrijker de hypothese is vanuit een zakelijk perspectief, hoe waarschijnlijker het is dat het te maken heeft met regelgevende beperkingen die beperken wat kan worden verzameld zonder door een heleboel disclaimers en toestemmingen te gaan. We kwamen dus in de situatie terecht dat verschillende veelbelovende hypotheses niet testbaar waren vanwege juridische beperkingen.

Tot slot, zelfs als we een specifieke hypothese en bijbehorend experiment hadden en we in staat waren om de gegevens te verzamelen die we nodig hadden, bleek het ontzettend moeilijk om op te schalen naar het punt van statistische significantie. Het uitvoeren van een grootschalig experiment dat een behoorlijke kans op mislukking heeft, maar dat erg duur en riskant is om uit te voeren, doet het doel van experimenteren een beetje teniet.

Een datagestuurde organisatie worden is een van de belangrijkste doelen die elk bedrijf zou moeten hebben. Het zorgt voor een veel hogere kwaliteit van besluitvorming en activiteiten en bereidt je voor op het gebruik van AI als een belangrijke differentiator en enabler. De stap van woord naar daad is echter een uitdagende reis waarbij je idealiter leert van de fouten van anderen voordat je zelf nieuwe fouten maakt. We hebben de gegevens nodig, maar we moeten het slim uitvoeren.

Kort na de introductie van wendbaarheid in softwareontwikkeling, werd ook het begrip business agility geïntroduceerd. Het basisidee was om de concepten achter agile softwareontwikkeling op te schalen naar grotere gebieden, met de ambitie om de hele organisatie te bereiken, inclusief R&D en IT. In de praktijk bleek het voor veel organisaties echter moeilijk om verder te gaan dan het softwaredeel van de organisatie en bleef het vaak steken bij DevOps. Ook was de basis mindset vaak om veranderingen te behandelen als verstoringen in een steady-state systeem, gericht op het zo snel mogelijk terugkeren naar een steady-state. Agile hield zich bezig met het minimaliseren van de impact van veranderingen door er snel op te reageren. Het begrip business agility was erg populair rond 2010 en begon daarna te vervagen omdat het niet het voordeel bood waar bedrijven naar op zoek waren. Om een manager van een van de Software Center-partners te citeren: “We gebruiken Safe en zeggen dat we allemaal agile zijn, maar we hebben niets veranderd…”

Meer recent zien we een ontwikkeling die niet helemaal afwijkt van de eerste incarnatie van business agility (1.0), maar die een aantal unieke kenmerken heeft en leidt tot een 2.0 versie van business agility. Deze versie heeft ten minste drie unieke aspecten: bedrijfsmodellen, technologische reikwijdte en snelle feedbacklussen.

Ten eerste zijn veel bedrijven zich gaan realiseren dat wendbaarheid op bedrijfsniveau begint met het bedrijfsmodel dat je hanteert. Het moet beginnen met een overgang van een transactioneel naar een continu model. Als je de mogelijkheid bouwt om waarde te leveren aan klanten, maar geen manier hebt om de continue waardecreatie te gelde te maken, is er geen enkele zakelijke stimulans. Als je het product, het systeem of het aanbod op een of andere manier verbetert, moet je in staat zijn om een deel van die waarde vast te leggen. Als je bijvoorbeeld een vrachtwagenbedrijf hebt en je voert A/B-tests uit op de motoren van je klanten in het veld om de brandstofefficiëntie te verbeteren, dan wil je een deel van de besparingen die je klanten genieten vastleggen. Waarom zou je anders überhaupt experimenteren? Dus, waar business agility 1.0 bottom-up begon met de softwareontwikkelingsteams, begint de incarnatie van 2.0 top-down vanuit het businessmodel.

Ten tweede groeit in de industrie voor embedded systemen het besef dat continue inzet of DevOps niet beperkt hoeft te blijven tot software. Met de juiste stimulansen en bedrijfsmodellen is het heel goed mogelijk om periodiek elektronische en mechanische onderdelen van systemen in het veld te updaten om de systeemprestaties te verbeteren. Tesla biedt onder andere chipupgrades en hardware retrofits die aanzienlijk verbeterde mogelijkheden bieden, die de software vervolgens kan gebruiken om de functionaliteit in de auto te verbeteren. Business agility 2.0 richt zich dus niet alleen op software, maar strekt zich uit tot elektronica en mechanica aan de ene kant en data en AI aan de andere kant.

Ten derde ligt de focus in business agility 2.0 op snelle feedbacklussen binnen het bedrijf en alle technologieën. Dit heeft twee aspecten. Ten eerste heeft elke technologie een optimale feedbacklengte waarbij het klant- en bedrijfsvoordeel van nieuwe releases in evenwicht zijn met de kosten van productie, distributie en installatie. Dit betekent natuurlijk dat software (inclusief AI-modellen) zich zeer snelle cycli kan veroorloven omdat de distributie- en installatiekosten zeer laag zijn en er geen productiekosten zijn. Voor elektronica, vooral wanneer de mechanische interface constant wordt gehouden (pinconfiguratie, stroomverbruik, EMC, enzovoort), zijn de kosten hoger en is een jaarlijkse of tweejaarlijkse cyclus misschien het meest logisch. Voor mechanische onderdelen ten slotte zou de updatefrequentie nog lager moeten liggen omdat het nog duurder is om ze te produceren, te distribueren en te installeren. Toch, als het continue bedrijfsmodel je heeft bevrijd van de “laten we alle verbeteringen bewaren voor het volgende product” houding, kunnen ook verbeterde mechanische onderdelen worden gedistribueerd, laten we zeggen, elke drie tot vijf jaar.

Bedrijfsflexibiliteit 1.0, digitalisering en bedrijfsflexibiliteit 2.0

Het tweede aspect is dat geen enkele langzamere cyclus de snellere cyclus kan vertragen. Traditioneel was de releasefrequentie van software gebonden aan de releasecyclus van het product. In business agility 2.0 kan geen enkele snellere cyclus (software of elektronica) worden vertraagd door een langzamere cyclus (bijvoorbeeld elektronica of mechanica).

We gaan het tijdperk in van business agility 2.0, dat begint met de invoering van een continu bedrijfsmodel en vervolgens het hele bedrijf optimaliseert om te profiteren van snelle feedbacklussen die ervoor zorgen dat alle technologieën in producten in hun eigen tempo verbeteren. Zelfs als je klanten er nog niet om vragen, je leveranciers klagen en je partners nog niet klaar zijn om mee te spelen, kun je hier maar beter mee aan de slag gaan, want de tweede incarnatie van business agility biedt grote voordelen en verbeteringen in efficiëntie en effectiviteit waar je niet zonder kunt. Ga voor agile, maar ga voor 2.0!

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!