Type something to search...

Blog

Engineering
Van DevSecOps naar Agentic DevSecOps
Door Lumia Labs/ Op 01 Mar, 2026

Van DevSecOps naar Agentic DevSecOps

DevSecOps begon met een simpel idee: security hoort in het ontwikkelproces, vanaf dag één. Maar "iedereen" in je team omvat nu ook AI-agents. Ze schrijven code en mergen pull requests. Je securitymodel gaat nog uit van mensen. Security opnieuw inrichten voor agents: dat is wat wij Agentic DevSecOps noemen. Het verandert hoe je nadenkt over identiteit, toegangscontrole, verificatie en verantwoordelijkheid. DevSecOps was gebouwd voor mensen DevSecOps draait erom dat het hele team verantwoordelijk was voor security. Shift left, bouw security in het ontwikkelproces en voorkom dat vulnerabilities productie bereiken. Dat ging uit van een menselijke developer die de code schrijft, de intentie begrijpt, scanresultaten beoordeelt en afwegingen maakt over risico. Developers gebruiken tooling zoals statische analyse om problemen te signaleren, maar uiteindelijk beoordeelt een mens of een melding een false positive is of een echte dreiging. Een reviewer leest de diff en bedenkt wat de gevolgen zijn. Uit Sonar's 2025-onderzoek blijkt dat 42% van de productiecode al AI bevat, en dat percentage stijgt. Zodra agents PRs openen en hun eigen code mergen, houdt geen van die aannames stand. Wat Agentic DevSecOps anders maakt Bij Agentic DevSecOps ontwerp je security voor een wereld waarin AI-agents je code schrijven en uitrollen. Wie is de agent, en wat mag die? In traditionele DevSecOps koppel je toegangscontroles aan menselijke identiteiten. Als een AI-agent een PR opent: wiens rechten gebruikt die? Wat zou die mogen doen? In onze ervaring draaien de meeste organisaties agents onder de persoonlijke credentials van een developer. De agent krijgt rechten die bedoeld waren voor een mens. AI-agents kiezen ook hun eigen dependencies. Onderzoek van Veracode toonde aan dat 45% van AI-gegenereerde code kwetsbaarheden bevat. Een agent kan een dependency toevoegen die technisch niets mankeert maar niet in je architectuur past. Of code schrijven die een kwetsbaar patroon nabootst zonder dat je scanners het oppikken. Snelheid versus verificatie AI-agents schrijven en deployen code tien tot honderd keer sneller dan mensen. Een security scan van 15 minuten werkt prima als developers een paar keer per dag pushen. Bij tientallen agent-wijzigingen per uur wordt die scan een bottleneck, of hij wordt "tijdelijk" overgeslagen en komt nooit meer terug. Agents laten genoeg sporen achter in commits en PR-beschrijvingen. Maar tegen de tijd dat een fout in productie opduikt, zitten er al tientallen commits bovenop. De code stapelt zich sneller op dan iemand kan reviewen. Andere fouten, andere risico's AI-agents maken andere fouten dan mensen. Menselijke fouten zijn voorspelbaar: input niet valideren, onveilige patronen kopiëren, credentials hardcoden, slordig worden onder tijdsdruk. Dat zie je in een review. AI-gegenereerde code is lastiger. Het lijkt correct, het doorstaat eenvoudige checks, maar er zit een fout in die je niet meteen ziet. De code ziet er goed uit, maar het doet alleen niet wat je denkt. Nieuwe aanvallen duiken al op in agentic workflows: Prompt injection via codecontext Een aanvaller verbergt kwaadaardige instructies in een codebase-comment of issue-omschrijving. De AI-agent leest die context, volgt de instructies en introduceert een backdoor die eruitziet als een legitieme codewijziging. Onderzoekers hebben aangetoond dat LLM's via hun inputcontext te manipuleren zijn. Een AI-agent die je vraagt een feature te bouwen kan een dependency binnenhalen die nog niet bestaat. Registreert een aanvaller die pakketnaam eerst, dan installeert de agent het foute pakket. Agents die zelf lockfiles aanpassen als onderdeel van hun workflow omzeilen die bescherming. Niemand kijkt mee Een AI-agent schrijft de code, een andere reviewt het, een geautomatiseerde pipeline deployt het. Niemand heeft dat zo bedacht, maar de stappen bij elkaar zijn een volledig geautomatiseerde route naar productie. AI-agents hebben API-keys en credentials nodig. Een agent die zijn context logt of secrets in een commit message zet, lekt credentials op plekken waar je secret scanning niet kijkt. Wat je pipeline nodig heeft Geef agents hun eigen identiteit Geef AI-agents eigen service-accounts met beperkte rechten. Schrijft een agent code? Dan mag die niet mergen. Draait een agent tests? Dan mag die de testconfig niet aanpassen. In de praktijk draaien de meeste agents nog op het token van een senior developer met volledige repo-toegang. Behandel ze als serviceaccounts: zo min mogelijk rechten, gecontroleerde toegang. Meer dan één scan Eén scan is niet genoeg, combineer statische analyse, semantische analyse, gedragstests en afwijkingsdetectie. AI-gegenereerde code heeft herkenbare patronen. Daar kun je op scannen. Rem agents bewust af Beperk hoe snel agents wijzigingen kunnen pushen, en bouw circuit breakers die activiteit pauzeren bij afwijkingen: ongebruikelijke dependency-toevoegingen of wijzigingen aan security-gevoelige bestanden. Weet waar elke wijziging vandaan komt De transparantieverplichtingen in de EU AI Act gelden al voor AI-gegenereerde code in gereguleerde sectoren, en handhaving komt eraan. Elke wijziging moet terug te voeren zijn op wie (of wat) het schreef, wat de aanleiding was, welke context de agent had en welke review het doorliep. Begin daar nu mee. Menselijke review Niet elke wijziging heeft een menselijke reviewer nodig. Maar wijzigingen aan authenticatie, autorisatie, betalingsverwerking, dataverwerking en infrastructuur wel. Bepaal je risicogebieden en wijk daar niet van af, ook als het de ontwikkeling iets vertraagt. Dit is geen toolingvraag Agentic DevSecOps gaat minstens zoveel over organisatie als over techniek. Securityteams moeten snappen hoe agents werken. Ontwikkelteams doen er goed aan agents te behandelen als een nieuwe collega: stel kaders, controleer het werk. En je platform moet er rekening mee houden dat niet alleen mensen code schrijven. Wie dit goed regelt kan agents met vertrouwen inzetten.Lumia Labs helpt teams die met AI-agents werken om security goed te regelen. Zet je agents in binnen je pipeline en wil je dat veilig doen? Neem contact op.

Engineering
Wie is verantwoordelijk voor je AI-agents?
Door Lumia Labs/ Op 13 Feb, 2026

Wie is verantwoordelijk voor je AI-agents?

In 2022 vroeg een klant de chatbot op de website van Air Canada naar korting voor tickets voor het bijwonen van uitvaart. De chatbot vertelde vol overtuiging dat hij een ticket tegen het normale tarief kon boeken en binnen 90 dagen een gedeeltelijke terugbetaling kon aanvragen. Dat klopte niet. Bij Air Canada moet je het kortingstarief aanvragen vóór de boeking. De klant gaf ruim $1.500 CAD uit aan vluchten die hij anders niet had geboekt. Toen hij de terugbetaling aanvroeg, wees Air Canada de claim af. Vervolgens betoogde het bedrijf dat de chatbot "een afzonderlijke juridische entiteit" was en dat Air Canada niet verantwoordelijk was voor diens uitspraken. Een Canadese rechter was het daar niet mee eens en veroordeelde Air Canada tot een schadevergoeding. Maar "de AI zei het, niet wij" blijft het favoriete verweer. De verantwoordelijkheid bij het gebruik van autonome AI-agents is een enorme uitdaging. McKinsey's beeld van de toekomst McKinsey's onderzoek uit 2025 naar de agentic organization noemt AI de grootste organisatieverandering sinds de Industriële Revolutie. Hun model beschrijft een toekomst van "platte netwerken van hybride teams van mensen en AI-agents" met "realtime, ingebouwde governance en geautomatiseerde controles met menselijke verantwoordelijkheid." Dat klinkt makkelijker dan het is. Het gaat ervan uit dat organisaties erachter komen hoe ze mensen verantwoordelijk houden voor systemen die autonoom handelen. Daar is vrijwel geen enkele organisatie op voorbereid. Een tool doet wat je zegt. Een agent beslist zelf wat hij doet. Als een developer een AI coding assistant gebruikt, beoordeelt de developer met code reviews de output en neemt daarmee verantwoordelijkheid. Wanneer een AI-agent autonoom claims verwerkt, supporttickets afhandelt of prijzen aanpast, wordt onduidelijk wie waarvoor verantwoordelijk is. Waar verantwoordelijkheid verdwijnt Niemand ontwerpt met opzet een oncontroleerbaar AI-systeem. Het sluipt erin via problemen die los van elkaar klein lijken. Versnipperd eigenaarschap Meerdere teams dragen bij aan het gedrag van een agent: het ML-team traint het model, het platform-team rolt het uit, het productteam bepaalt de regels, het datateam beheert de input. Als er iets misgaat, is elk team verantwoordelijk voor een stukje, maar niemand voor het resultaat. Braham en van Hees noemen dit het probleem van de vele handen. Hoe meer mensen betrokken zijn bij een beslissing, hoe minder ieder individu zich verantwoordelijk voelt. Ondoorzichtigheid Wanneer een AI-agent een beslissing neemt, kunnen zelfs de mensen die het systeem gebouwd hebben vaak niet uitleggen waarom de beslissing op die manier genomen is. De Europese Unie erkende dit in de EU AI Act, die vereist dat AI-systemen met hoog risico menselijk toezicht toelaten en uitleg geven over hun beslissingen. De regelgeving loopt voor op wat organisaties technisch aan kunnen. Regelgeving helpt niet als je zelf niet kunt uitleggen wat je systeem doet. Snelheid wint van toezicht AI-agents zijn vrijwel onbeperkt schaalbaar. Een menselijke goedkeuringsstap van dertig seconden klinkt haalbaar, tot de aantallen groeien en het toezicht niet meer meekomt. De keuze is simpel: de agent afremmen zodat mensen mee kunnen kijken, of snelheid voorrang geven. Snelheid wint meestal, want het is goedkoper. Organisatorische traagheid Zelfs als teams dit herkennen, houdt de organisatie het tegen. Governance-commissies werken per kwartaal, developers shippen per week. Het organigram is niet gebouwd voor systemen die door meerdere afdelingen beheerd worden. Autonomie zonder verantwoordelijkheid is aansprakelijkheid Neem de Boeing 737 MAX. Het MCAS-systeem nam autonome beslissingen en Boeing informeerde piloten onvoldoende over het gedrag ervan. Toen het systeem situaties tegenkwam die de ontwerpers niet hadden voorzien, kwamen 346 mensen om. Uit de onderzoeken bleek versnipperde verantwoordelijkheid: engineers, managers en toezichthouders waren elk voor een deel verantwoordelijk. Dus voelde niemand zich verantwoordelijk voor het geheel. AI-agents nemen al beslissingen over krediet, triage in ziekenhuizen, werving en selectie en contentmoderatie. In Nederland bestempelde een algoritme van de Belastingdienst meer dan 26.000 gezinnen onterecht als fraudeur. Duizenden gezinnen in de financiële problemen. Het kabinet trad af. Stanford's Human-Centered AI Institute publiceert beleidsonderzoek dat laat zien hoe organisaties die AI-systemen inzetten het benodigde toezicht stelselmatig onderschatten. De technologie beweegt snel, het toezicht blijft achter, en in de kloof daartussen ontstaat schade. Wat organisaties volgens ons moeten doen Governance vóór autonomie kost geld: meer mensen, minder snel releasen, ontwikkeltijd. Het is echter een groot risico om het geld niet uit te geven. Wijs eigenaren toe voor uitkomsten, niet voor componenten Elke AI-agent heeft een persoon nodig die verantwoordelijk is voor het gedrag in productie. Eén eigenaar voor de uitkomsten, niet één per component. Deze persoon moet de bevoegdheid hebben om de agent uit te schakelen als het misgaat. Bouw observability voor autonomie Je zou een kritieke service niet uitrollen zonder monitoring en alerting, dat is waar DevOps om draait. AI-agents verdienen dezelfde behandeling: logging van beslissingen, monitoring en geautomatiseerde alerts wanneer gedrag afwijkt van verwachtingen. Zonder observability is toezicht onmogelijk. Definieer je model expliciet Beslis vooraf of mensen beslissingen beoordelen voordat ze plaatsvinden (human-in-the-loop), nadat ze plaatsvinden (human-on-the-loop), of alleen bij afwijkingen (human-over-the-loop). Elk model heeft een ander risicoprofiel. Als je niet kiest, krijg je 'human-over-the-loop', en dat kan te laat zijn. Ontwerp voor uitlegbaarheid Neem bij het bouwen van AI-agents uitgebreide logging en traceerbaarheid op als requirements. Doe pre-mortems Stel voor de uitrol de vraag: "Als deze agent schade veroorzaakt, wie is er dan verantwoordelijk en hoe komen we erachter?" Als het antwoord onbekend is, neem dan de agent niet in productie. De governance-kloof is een leiderschapsprobleem De organisatiestructuren om AI-agents te besturen lopen achter. McKinsey's visie van "realtime, ingebouwde governance met menselijke verantwoordelijkheid" is goed, maar dan moet je wel je verantwoordelijkheid, toezichtmodellen en organisatiecultuur goed regelen. De organisaties die dit goed doen, bouwen het vertrouwen waarmee ze AI-agents effectiever kunnen inzetten. Dat vertrouwen heeft een prijs: governance-rollen en observability in plaats van features. Maar wie duurzaam wil innoveren, moet eerst verantwoordelijkheid regelen. Anders wordt ambitie aansprakelijkheid.Lumia Labs helpt organisaties om governance en engineering voor AI-systemen goed in te richten. Wil je AI-agents inzetten en verantwoordelijkheid goed regelen? Neem contact op.

Engineering
Je hebt geen microservices nodig
Door Lumia Labs/ Op 09 Feb, 2026

Je hebt geen microservices nodig

Segment bouwde meer dan 140 microservices voor hun event routing. Drie ontwikkelaars besteedden uiteindelijk het grootste deel van hun tijd aan onderhoud in plaats van features bouwen. Ze stapten terug naar een monoliet. In plaats van sneller te werken, schreef Alexandra Noonan, verdronk het kleine team in complexiteit. We zien dit patroon ook bij klanten. Amazon's Prime Video-team stapte over van serverless microservices naar een monoliet en verlaagde de infrastructuurkosten met 90%. Zelfs het bedrijf dat service-oriented architecture uitvond, kwam erachter dat het niet altijd het juiste antwoord is. Amazon's architectuur is niet de jouwe De microservices-beweging begon omdat monolithische applicaties onhandelbaar werden naarmate teams groeiden. Conway's Law speelde zich af: grote codebases dwongen ontwikkelaars tot eindeloos afstemmen. Jeff Bezos stuurde rond 2002 zijn beroemde API-mandaat waarin hij alle Amazon-teams verplichtte om via service-interfaces te communiceren. Die architectuurkeuze maakte AWS mogelijk. Het patroon werkte voor Amazon, dus iedereen kopieerde dat. In 2020 vond O'Reilly dat 77% van de organisaties microservices had overgenomen. Maar de meeste van die organisaties zijn Amazon niet. Ze hebben geen duizenden ontwikkelaars, geen decennia aan infrastructuurtooling, en niet het budget om honderden onafhankelijke services te beheren. Martin Fowler zag het al in 2015, hij schreef: bijna alle succesvolle microservices-verhalen begonnen met een monoliet die te groot werd en werd opgesplitst. Bijna alle gevallen waarbij een systeem vanaf het begin als microservices werd gebouwd, liepen vast. De meeste microservices zijn verkapte monolieten De meeste microservice-architecturen waar we mee werken doen niet wat ze beloven. Fouten die we zien:Meerdere services delen een database, waardoor migraties van het schema lastig worden Lastig om één wijziging in één service te deployen, door lekkende abstracties en verborgen afhankelijkheden Moeilijk om leveringen over teams te coördineren, omdat services niet onafhankelijk zijn Slecht API-ontwerp, waardoor services hun interne werking blootleggen (dit is ook slecht in monolieten, maar daar zit het nog in één delivery) Een storing in één service rolt door het hele systeemTaibi, Lenarduzzi en Pahl catalogiseerden 20 van dit soort antipatronen via gesprekken met ontwikkelaars. De meeste herkennen we. Het heeft een naam: de distributed monolith. Je betaalt de volledige operationele kosten van microservices, maar krijgt niets van de onafhankelijkheid. Elke service-hop voegt latency toe, en debuggen over servicegrenzen duurt zo'n 35% langer dan in één proces. Kelsey Hightower, destijds Distinguished Engineer bij Google Cloud, was er duidelijk over: monolieten zijn de toekomst, want microservices lossen een probleem op dat er niet is. Je gaat van slechte code naar slechte infrastructuur waar je diezelfde slechte code bovenop draait. Wat ons betreft wordt de complexiteit voor teams te vaak over het hoofd gezien. Team Topologies-onderzoek van Matthew Skelton en Manuel Pais bevestigt dit: niet de architectuurkeuze doet ertoe, maar of je team die architectuur aankan. Microservices verveelvoudigen wat een team moet begrijpen: networking, service discovery, distributed tracing, container orchestration. Method calls, niet netwerkcalls Er is een andere optie: de modulaire monoliet. Eén deployment met strikte interne grenzen tussen domeinmodules, waar communicatie via method calls gaat in plaats van netwerkcalls. Eén testpipeline, één deployment, maar mét de structuur die spaghetti voorkomt. Shopify draait een van de grootste Ruby on Rails-applicaties ter wereld: 2,8 miljoen regels code, meer dan 500.000 commits, honderden actieve ontwikkelaars. Ze evalueerden microservices en wezen ze bewust af. Kirsten Westeinde van Shopify's engineeringteam schreef dat ze een oplossing wilden die modulariteit bood zonder het aantal deployments te vergroten. Dat leverde 37 componenten op met duidelijke grenzen, afgedwongen door tools als Packwerk voor statische analyse. Ontwikkelaars werken binnen heldere grenzen zonder de overhead van gedistribueerde systemen. DHH van Basecamp beschreef hun aanpak in 2016: 12 programmeurs die miljoenen gebruikers bedienen op zes platformen, met een monoliet van 200 controllers en 190 modelklassen. In 2023 schreef hij "How to Recover from Microservices", met Gall's Law als uitgangspunt: een complex systeem dat werkt, is altijd ontstaan uit een simpel systeem dat werkte. Zelfs Google erkende het patroon. Hun Service Weaver-framework laat je een applicatie schrijven als modulaire monoliet en pas als microservices deployen wanneer dat nodig is. De architectuur begint simpel en wordt alleen complexer waar het systeem erom vraagt. De meeste teams zijn te klein voor microservices Microservices lossen problemen op die eenvoudigere architecturen niet aankunnen. Honderden ontwikkelaars die onafhankelijk moeten deployen. Componenten met fundamenteel andere schaaleisen. Op die schaal verdienen microservices hun complexiteit terug. Stefan Tilkov stelt dat een monoliet leidt tot koppeling die je er later moeilijk uit krijgt. Daar heeft hij gelijk in, als je geen modulegrenzen afdwingt. Maar hij nuanceert het zelf: de aanpak vereist diepe domeinkennis en past alleen bij grotere systemen. Het onderzoek achter Accelerate (Forsgren, Humble, Kim) laat zien dat topteams architectuur hebben waarmee teams onafhankelijk kunnen deployen. Dat kan met microservices, maar net zo goed met een modulaire monoliet. Teamautonomie bepaalt het resultaat, niet het architectuurpatroon. Als je engineeringteam kleiner is dan 50 ontwikkelaars, heb je vrijwel zeker geen microservices nodig. Begin met modules en stap over op microservices als dat nut heeft. Eerst modules, dan pas services Als we teams helpen met hun software-architectuur, gebruiken we deze principes: Trek eerst domeingrenzen. Snap je bedrijfsdomeinen voor je een architectuur kiest. Goede domeinkennis is de basis voor een goede architectuur. Dwing grenzen af in code. Modulegrenzen zonder handhaving vervagen binnen een paar maanden. Gebruik tooling als SonarQube om schendingen zichtbaar te maken. Meet de belasting op je team. Besteedt je team meer tijd aan infrastructuur dan aan features? Dan is je architectuur te complex. Plan vooruit. Een goed gemodulariseerde monoliet kan doorgroeien naar microservices wanneer nodig. Ontwerp modules alsof ze services kunnen worden.Lumia Labs helpt organisaties met architectuurkeuzes. Heroverweeg je je architectuur? We horen graag van je.

Engineering
Innovatie is geen afdeling
Door Lumia Labs/ Op 05 Feb, 2026

Innovatie is geen afdeling

Bedrijven die voorop willen blijven richten vaak innovatiehubs of -labs op: aparte teams, los van de dagelijkse gang van zaken, met de opdracht om de volgende doorbraak te bouwen. Geef slimme mensen de ruimte om te experimenteren, is de gedachte, en de rest komt vanzelf. Soms werkt het. Een lab waar we mee werkten bouwde een prototype dat de manier van werken binnen het bedrijf had kunnen veranderen. Ze hadden het getest met gebruikers en het was klaar om ingevoerd te worden. Maar de productteams zaten al vol. Het prototype was met andere technologie gebouwd, dus geen enkel team kon het overnemen. Een jaar later was het innovatielab een gewoon team geworden, bezig met onderhoud in plaats van vernieuwing. Het instinct om innovatie apart te zetten is begrijpelijk. Clayton Christensen's Innovator's Dilemma liet zien waarom succesvolle bedrijven moeite hebben met grote marktverschuivingen: ze zijn te goed in het bedienen van bestaande klanten. Als er een nieuwe technologie opkomt, lijkt het onverstandig om daarin te investeren. De logische keuze om je op winstgevende klanten te blijven richten, blijkt achteraf de verkeerde. Christensen stelde een oplossing voor: zet aparte teams op om nieuwe technologieën te onderzoeken. Veel bedrijven volgden dit advies, maar de meeste faalden alsnog. Losse innovatieteams kunnen werken voor onderzoek en proof of concepts. Dat model werkt niet zodra de rest van het bedrijf ermee aan de slag moet. Of je houdt het team echt los als apart bedrijf, of je zorgt dat bestaande teams zelf leren vernieuwen. Onderzoek van Harvard Business Review toonde aan dat de meeste innovatiehubs hun belofte niet waarmaken. Soms reageren labs door zelf producten uit te rollen, maar dat zorgt voor nieuwe problemen. Innovatie en onderhoud vragen andere vaardigheden en een andere manier van denken. Zodra een lab productiesystemen onderhoudt, wordt het een beheerteam in plaats van een vernieuwingsteam. Waarom afscheiding faalt Culturele isolatie. Innovatielabs hebben andere waarden, durven meer risico te nemen, en werken anders. Wanneer projecten terug moeten naar de hoofdorganisatie, stuiten ze op weerstand. De ontwikkelaars die er niet bij horen, ergeren zich aan de voorkeursbehandeling, en managers zien hun budget in gevaar komen. "Not invented here" wordt "not wanted here." Verkeerde metrics. De rest van het bedrijf kijkt naar kwartaalomzet en marge, terwijl het lab kijkt naar hoe snel ze experimenteren en wat ze ervan leren. Geen van beiden snapt wat de ander onder succes verstaat. Bij bezuinigingen worden labs stopgezet omdat ze geen meetbare resultaten kunnen aantonen. Onderzoek naar wendbare organisaties van O'Reilly en Tushman vond dat bedrijven nauwe samenwerking op directieniveau nodig hebben tussen experimentele en bestaande teams, maar de meeste krijgen dit niet voor elkaar. Kennis blijft hangen. Google's Project Aristotle ontdekte dat psychologische veiligheid, het gevoel dat je risico's kunt nemen zonder afgerekend te worden, voor bijna de helft bepaalt hoe goed teams presteren. Losse labs hebben dit misschien intern, maar de rest van de organisatie meestal niet. Het nieuwe denken blijft in het lab hangen, en de rest van het bedrijf leert nooit anders te denken. Verdwijnende aandacht. Zodra het slechter gaat met het bedrijf, kijkt de directie niet meer naar het lab. Budgetten worden bevroren, deadlines schuiven op, en de beste mensen worden teruggehaald naar "echte" projecten. Labs hebben blijvende steun van de top nodig om te overleven, en die verdampt zodra de kwartaalcijfers tegenvallen. Overleven Kodak vond digitale fotografie uit in de jaren '70. Nokia zag de smartphone al jaren aankomen, nog voor de iPhone bestond. Beide bedrijven hadden innovatie ergens in de organisatie. De ideeën waren er, maar ze kregen het niet voor elkaar. Onderzoek dat de ondergang van Nokia en Kodak vergeleek vond dat beide een starre bedrijfscultuur hadden, verkeerde keuzes maakten, en weigerden om hun eigen winstgevende producten te vervangen. Ze zagen het aankomen maar ondernamen niets. Analyse van HealthManagement.org vond dat bij Nokia angst de oorzaak was: topmanagers waren bang voor externe concurrenten, middenmanagers voor interne politiek. Niemand durfde de knoop door te hakken. Kodak voerde in 1981 een studie uit die liet zien dat ze ongeveer tien jaar hadden om zich voor te bereiden op digitale fotografie. Ze stopten het in een la om de filmtak te beschermen. De kennis was er, maar de wil ontbrak. Innovatie inbouwen in de organisatie BCG-onderzoek vond dat bedrijven waar innovatie overal in de organisatie leeft 60% meer kans hebben om voorop te lopen. O'Reilly en Tushman onderzochten bedrijven waar dezelfde directie verantwoordelijk is voor zowel innovatie als dagelijkse operatie. Doorbraken lukken daar in 90% van de gevallen. Bij aparte innovatieteams is dat minder dan 25%. Creëer ruimte voor experiment Traditionele maatstaven verstikken experimenteel werk. 3M laat werknemers 15% van hun tijd aan eigen projecten besteden, hier kwam Post-it Notes uit voort. Google had vroeger de 20% innovatietijd, wat Gmail en AdSense opleverde. Meet experimenteel werk anders, maar doe dat in de hele organisatie. Maak falen risicovrij Als falen risicovol is, probeert niemand meer iets nieuws. Organisaties die willen innoveren moeten laten zien dat ze van fouten leren, en mensen belonen die risico durven te nemen. Dat vraagt een cultuuromslag. Roteer mensen en ideeën Als innovatie in een lab zit, blijft de kennis daar hangen. Laat ontwikkelaars en productmensen wisselen tussen regulier werk en experimentele projecten. Zo leert iedereen hoe je iets uitprobeert, test of het werkt, en op tijd stopt als het niets wordt. Zet in op veel kleine vernieuwingen Bedrijven geven innovatie vaak maar één kans, terwijl investeerders juist verwachten dat het meeste mislukt. Diezelfde aanpak werkt ook intern: voer veel kleine experimenten uit, stop wat niet werkt, en ga door met wat wel aanslaat. Onderzoek van McKinsey vond dat de beste vernieuwers acht keer zo vaak écht wendbaar zijn geworden als organisatie. Niet Agile op papier, maar in de praktijk. Cultuur eet labs als ontbijt Kodak en Nokia hadden beide de technologie. Ze zagen het aankomen en hadden al jaren eerder werkende prototypes dan de concurrentie. Wat ontbrak was een organisatie die achter haar eigen uitvindingen durfde te staan. Zit vernieuwing in je cultuur, dan bloeit het. Zit het in een lab, dan verzandt het.Lumia Labs helpt bedrijven die technisch én organisatorisch willen vernieuwen. Benieuwd hoe je teams innovatiever maakt? We horen graag van je.