Het engineeringteam van Compass zat met een probleem. Onze functies waren technisch in orde, maar er ontbrak iets: echte klantliefde. We waren goed in het schrijven van code, maar waren we wel de juiste problemen aan het oplossen?
Ik ben Senior Engineering Manager bij Atlassian en ik werk met Compass, waardoor ik jarenlang met deze uitdaging heb geworsteld. Mijn team en ik zijn verantwoordelijk voor het ontwikkelen van tools waarmee ontwikkelingsteams hun softwarecomponenten en -resources op grote schaal kunnen beheren. Toen ik hier kwam werken, merkte ik een patroon op waar veel technische organisaties mee te maken hebben: we zijn goed in het ontwikkelen van functies, maar soms slaan we de plank mis als het gaat om het leveren van waarde.
Ik heb zelf gezien hoe een engineeringcultuur het succes van een product kan maken of breken. Bij Atlassian ontwikkelen we niet alleen tools voor softwareteams. We herkennen ons in dezelfde uitdagingen waar onze klanten dagelijks mee te maken hebben. Dit geeft ons een unieke kijk op de transformatie van de engineeringcultuur en daarom vind ik het bijzonder leuk om te delen wat we hebben geleerd.
De traditionele afstand die engineers hebben tot klanten
We gaan het hebben over een hypothetisch productteam waarvan het verhaal je misschien bekend in de oren klinkt.
Tina is een senior ontwikkelaar die bekend staat om haar technische uitmuntendheid. Hoewel haar code onberispelijk was, zat ze vast in een bekende cyclus: vereisten ontvangen, code schrijven en functies implementeren. "Ik was code aan het schrijven in een vacuüm", geeft Tina toe. "Ik had geen idee of wat ik aan het ontwikkelen was ook echt de problemen van klanten oploste". Ze wilde meer context van de klant, maar voelde zich beperkt door haar focus op alleen de implementatie.
Rita, de productontwerper van het team, had te maken met haar eigen problemen. Ze was wekenlang bezig met het maken van pixelperfecte ontwerpen, om vervolgens cruciale feedback te krijgen tijdens de ontwikkeling, die tot grote herzieningen leidde. "Tegen de tijd dat ontwikkelaars mij wijzen op technische beperkingen, is het vaak te laat om de oorspronkelijke ontwerpvisie te behouden", legt ze uit. Rita had een betere integratie nodig met het ontwikkelingsproces en een manier om ontwerpen eerder te valideren.
Dan is er nog Paul, de productmanager, die probeert om alles bij elkaar te houden. Hij heeft talloze uren besteed aan het schrijven van gedetailleerde documenten met vereisten, maar er ging altijd iets verloren bij de vertaling. "Het leek op giswerk", zegt Paul. "Tegen de tijd dat functies onze klanten bereiken, zijn ze veranderd in iets anders dan wat we aanvankelijk voor ogen hadden". Hij was wanhopig op zoek naar een betere samenwerking tussen engineering- en ontwerpteams, maar het traditionele overdrachtsproces bleef barrières opwerpen.
Rick, de programmamanager, had misschien wel de meest uitdagende functie van allemaal. Door de afhankelijkheden tussen meerdere teams te coördineren en tegelijkertijd de snelheid van de levering en de kwaliteit in evenwicht te brengen, bleef hij 's nachts wakker. "Als teams in silo's werken, kunnen eenvoudige veranderingen leiden tot wekenlange vertragingen", merkt Rick op. Hij had een manier nodig om betere samenwerking en zichtbaarheid tussen teams te bevorderen.
Anna, de leidinggevende van het engineeringteam die alles overzag, had moeite om de manier te veranderen waarop haar teams werkten. Hoewel ze waarde hechtte aan technische topkwaliteit, wist ze dat er iets ontbrak. "We hebben ongelooflijk getalenteerde engineers," merkt ze op, "maar we leveren niet altijd de waarde die onze klanten nodig hebben." Anna wilde de cultuur van het team veranderen, maar het traditionele ontwikkelingsmodel maakte het moeilijk om technische topkwaliteit te combineren met klantwaarde.
De ervaring van dit team weerspiegelt een breder patroon in softwareontwikkeling. De traditionele stapsgewijze aanpak is dan wel georganiseerd en voorspelbaar, maar zorgt ook standaard voor afstand tussen degenen die het product maken en degenen die het gebruiken.
Cultuur: de sleutel tot verandering
"Culture eats strategy for breakfast". Hoewel dit citaat vaak wordt toegeschreven aan managementgoeroe Peter Drucker, kreeg het bekendheid toen Mark Fields het in 2006 permanent tentoonstelde in de discussieruimte van Ford. De boodschap was niet alleen een pakkende zin, het bevatte een fundamentele waarheid die we herhaaldelijk hebben gezien in de technische sector: zelfs de meest briljante strategie is gedoemd te mislukken als die in strijd is met je organisatiecultuur.
Toen we besloten om onze engineeringcultuur bij Compass te transformeren, ontdekten we iets belangrijks: alleen technische uitmuntendheid was niet genoeg. We moesten de kloof tussen onze engineers en klanten overbruggen. De cijfers zijn hier bewijs van: bij bedrijven met een sterk aanwezige bedrijfscultuur ligt de omzetgroei 4 keer hoger dan bij concurrenten.
Ons transformatietraject bij Compass illustreert dit perfect. We zijn overgestapt van een traditioneel proces voor de levenscyclus van functies, dat doorgaans 6 tot 8 weken duurde, naar een iteratief ontdekkingsproces dat ons veel dichter bij de problemen van klanten bracht. Dit was niet alleen een procesverandering — het was een fundamentele verschuiving van een 'alleskenner-' naar een 'alleslerer-mentaliteit', waarbij elke functie een kans werd om van onze klanten te leren.
De evolutie van productengineering
Software-engineering gaat van oudsher om het omzetten van vereisten in werkende code door middel van systematisch ontwerpen, ontwikkelen en testen. Engineers richten zich voornamelijk op technische uitvoering: het schrijven van efficiënte code, het onderhouden van systemen en het waarborgen van kwaliteit.
Productengineering staat echter voor een fundamentele verandering in de manier waarop we denken over het ontwikkelen van software. Hoewel de technische nauwkeurigheid van software-engineering behouden blijft, voegt het een cruciaal element toe: diepgaand inzicht in de klant en voortdurend leren. Productengineers schrijven niet alleen code. Ze ontdekken en lossen problemen op van klanten, geven technisch inzicht in productbeslissingen en zien zelf de resultaten van hun werk.
Het traditionele model voor software-engineering
In het traditionele model volgt ontwikkeling een lineair pad. Productbeheerteams stellen vereisten op en die gaan via de ontwerp-afdeling naar de engineeringteams die ze implementeren. Zie het als een estafetteloop, waarbij elk team het stokje doorgeeft aan het volgende.
De oude workflow van ons team weerspiegelde deze lineaire aanpak:
- Het duurde maanden om documenten met vereisten te maken en goed te keuren
- Architecten en ontwerpers werkten onafhankelijk van elkaar
- Engineers codeerden aan de hand van duidelijke specificaties
- Het testen en implementeren vond aan het einde van het proces plaats
- Feedback van klanten werd via meerdere lagen gefilterd
Deze aanpak werkte goed toen de vereisten stabiel waren en veranderingen duur waren. Maar in de snel evoluerende markten van vandaag hadden we iets nodig dat makkelijker aan te passen en klantgericht was.
De continue cyclus van productengineering
Onze transformatie richtte zich erop om dit lineaire proces te vervangen door een continue leercyclus. In plaats van ontwikkeling te beschouwen als een estafetteloop, werken we nu meer als een voetbalteam: iedereen beweegt samen, past zich aan veranderende omstandigheden aan en houdt het doel in de gaten om klantwaarde te leveren.
Dit nieuwe model betekent het volgende:
- Engineers nemen deel aan gesprekken met klanten en ontdekkingssessies
- Ontwikkelen en ontwerpen vinden tegelijk plaats, met snelle toepassing van prototypes en testen
- Technische beslissingen worden gevalideerd op basis van de behoeften van de klant
- Implementatie is een kans om te leren, niet alleen een mijlpaal
- Teams meten succes aan de hand van de impact op de klant, niet alleen aan de hand van technische statistieken
Van implementatie tot zichtbare prestatie
Voor engineers zoals Tina betekende deze transformatie de evolutie van pure implementatie naar het ervaren van de resultaten. Engineers:
- Nemen nu deel aan het definiëren van problemen en het zoeken naar oplossingen
- Delen technische perspectieven tijdens vroege discussies
- Valideren veronderstellingen nu rechtstreeks bij klanten
- Zijn nu zelf verantwoordelijk voor het resultaat dat verder gaat dan alleen de kwaliteit van de code
- Volgen nu bedrijfsstatistieken en de marktimpact
De resultaten spreken voor zich: organisaties die dit model toepassen, zien een snellere time-to-market en hogere acceptatiepercentages voor functies dan organisaties die een traditionele engineeringaanpak gebruiken. Misschien nog belangrijker: er was meer betrokkenheid van het team, er werden betere technische beslissingen genomen en er was een sterkere afstemming tussen onze technische oplossingen en de behoeften van de klant.
Hoe we onze transformatie mogelijk hebben gemaakt
Om de manier waarop engineers werken te veranderen, was meer nodig dan alleen een mentaliteitsverandering: we hadden de juiste basis nodig. Voor ons team was Jira Product Discovery, een tool die op natuurlijke wijze de context van de klant in onze dagelijkse workflow bracht, een cruciaal onderdeel van deze basis.
De eerste uitdaging die we moesten oplossen was het toegankelijk maken van klantinzichten voor iedereen. Vroeger stonden feedback van klanten en productvereisten in Confluence-documenten, Slack-discussies en Jira-tickets. Jira Product Discovery bracht al deze context rechtstreeks naar onze ontwikkelingsworkflow. Engineers konden nu gesprekken met klanten, feedbacksessies en gebruikspatronen naast hun ontwikkelingswerk zien, waardoor de behoeften van klanten tastbaar en duidelijk werden in plaats van abstract en afstandelijk.
Deze toegankelijkheid heeft de manier waarop onze teams samenwerkten fundamenteel veranderd. Als een ontwerper zoals Rita nieuwe ontwerpen maakte, kon ze die rechtstreeks koppelen aan de pijnpunten van klanten die engineers konden zien en begrijpen. Toen Paul prioriteit gaf aan functies, kon hij de impact van de klant gemakkelijk koppelen aan technische complexiteit, wat leidde tot beter onderbouwde beslissingen. Het belangrijkste was dat onze engineers eindelijk het complete plaatje konden zien: niet alleen wat we aan het ontwikkelen waren, maar ook waarom dat belangrijk was voor onze klanten en welke invloed dat zou hebben op hun werk.
Teams die een soortgelijke transformatie overwegen, moeten niet vergeten dat het niet gaat om de keuze tussen technische uitmuntendheid en klantgerichtheid, maar om het samenbrengen van deze twee om producten samen te stellen waar klanten echt dol op zijn. Als engineers de behoeften van klanten goed begrijpen, nemen ze betere technische beslissingen, ontwerpen ze elegantere oplossingen en vinden ze meer betekenis in hun werk omdat ze de directe impact ervan kunnen zien.
Wil je meer weten over hoe we deze transformatie tot stand hebben gebracht? Bekijk ons webinar: De magie achter productengineering: Problemen van klanten omzetten in functies die ze goed kunnen gebruiken, waarin ik dieper inga op ons traject en praktische strategieën en rituelen deel die je met je eigen team kunt implementeren.