The Value Flywheel Effect: When Tech Strategy Meets Reality

David Anderson stood on stage at GOTO Serverless in Bengaluru with a provocative claim: we're asking the wrong question about serverless. The real question isn't "why serverless?" but "when do we modernize?"

Anderson, who spent five years at Liberty Mutual wrestling with large-scale modernization before writing The Value Flywheel Effect, has seen enough failed transformation initiatives to know that technology choices are rarely the bottleneck. The bottleneck is momentum—or rather, the lack of it.

The Flywheel Nobody Talks About

The Value Flywheel framework sounds deceptively simple: clarity of purpose, psychological safety, rapid iteration, and long-term value. Four phases. Nice and tidy. But Anderson's talk reveals something more interesting than the framework itself—the gaps between what we say about modernization and what actually happens.

He uses Wardley mapping to visualize how ideas evolve from experimental concepts to accepted practice. Technology moves left to right on this spectrum: from hypothesis to theory to widely adopted standard. But that evolution isn't smooth. Anderson calls the resistance points "inertia"—and that's where things get messy.

"A lot of leaders were maybe software engineers 10, 20 years ago," Anderson noted. "They used to have knowledge back then, right? Expertise is something different... Knowledge becomes stale."

This hits different when you've watched a former engineer turned manager insist on patterns from 2009 because "that's how we did it when I was coding." That's not wisdom. That's inertia.

The Human Side of Event-Driven Architecture

Anderson's current work at G-P (Globalization Partners) provides the practical backdrop for his framework. They're building a serverless-first, event-driven platform across 180 countries. It's ambitious. It's also revealing about what actually matters when you're trying to move fast.

The technical choices are almost boring in their sensibility: Lambda for compute, DynamoDB for storage, EventBridge as the event backbone. But here's what's interesting—they scaffold this standard stack for every new bounded context. Forty squads, same building blocks.

"We start with a kind of a reduced operational overhead," Anderson explained. "You can bring in other services as needed."

This isn't about dogma. It's about reducing cognitive load. When every team uses the same primitives, you create shared context. That matters more than people realize, especially as AI tools proliferate.

Psychological Safety Isn't Soft

The section on psychological safety could have been throwaway corporate-speak. Instead, Anderson mapped it to a four-stage progression: from inclusion to belonging to learning to challenging. That fourth stage—being safe enough to tell your boss they're wrong—is where most organizations fail.

"Shilpa tells me all the time, no, you're incorrect. That's wrong. Here's a better way of doing it," Anderson said. "But for me, that's that fourth level of psychological safety."

He's describing something specific: the ability to point out mistakes in real-time without triggering a defensive response or career consequences. This becomes critical in fast-moving technical environments where yesterday's best practice might be today's antipattern.

The counterpoint Anderson raises—knowledge versus expertise—cuts through a lot of industry mythology. Just because someone coded 15 years ago doesn't mean they understand current systems. Expertise requires continuous learning. Knowledge without update cycles becomes an obstacle.

Where DevOps Lost the Plot

Anderson's aside about DevOps is worth sitting with: "DevOps was originally created as a way of thinking to sort of join development and operations, but it's become an infrastructure thing. I think it's almost forgot about the developer."

He's pointing at something many developers feel but don't always articulate. DevOps became a job title, a team, a silo. Platform engineering attempts to correct this by explicitly serving developer needs. But the underlying tension remains: who decides what gets automated, what gets abstracted, what developers need to understand?

At G-P, they use Event Catalog—an open source tool from former AWS engineer David Barney—to create a single place where all API and event specifications live. It's infrastructure as documentation, documentation as shared language. The technical and social dimensions converge.

Code as Liability, System as Asset

The most quietly radical thing Anderson said: "The value isn't in the code that I write. The value is in the system I designed and that is expressed in code."

This reframes the entire AI code generation conversation. Managers who think you can just prompt-generate 100,000 lines of code and ship it are missing the point. "You have to check it in, you have to store it, you have to maintain it, you have to test it, you have to fix it," Anderson pointed out. "It's awful lot of hassle."

The system—the boundaries, the interactions, the contracts, the evolution strategy—that's the actual work. Code is just one expression of it. With serverless, you're often writing less code. The system design matters more, not less.

The Actual Flywheel

Anderson's framework loops back on itself by design. You establish clarity of purpose. You build psychological safety so people can challenge assumptions. You create technical foundations that reduce undifferentiated heavy lifting. You build for long-term value, not quarterly demos.

Then something new emerges—AI agents, a new compliance requirement, a market shift—and you don't start over. You build on what you already created. That's the flywheel effect: each iteration makes the next one faster because you've built momentum and shared context.

"We often think of projects as being linear," Anderson said. "When I start here, I'll do this, I'll be done. That's never how things happen."

Most modernization efforts fail because they're designed as projects with endpoints. But systems don't have endpoints. They evolve or they ossify. The question isn't whether to modernize—it's whether you're creating the conditions for continuous evolution or just completing another project.

Anderson's been doing this for 30 years, and he noted that the pace of change right now is unlike anything he's seen. AI, cloud-native patterns, platform engineering, event-driven everything—it's genuinely accelerating. Which means the companies that built momentum yesterday can leverage it today. And the ones that treated modernization as a one-time project? They're back at square one.

—Dev Kapoor