Creating Momentum with The Value Flywheel Effect • David Anderson • GOTO 2025
David Anderson explains his "Value Flywheel Effect" framework, a model for continuous cloud modernization that joins business and technology strategy. He details how creating psychological safety, a robust serverless-first technology strategy, and a focus on system design over code builds the necessary momentum and shared context to harness future technologies like AI effectively.
Modernization is an inevitable consequence of moving to or operating in the cloud, and a serverless mindset is the best guide for this journey. Rather than asking “Why serverless?”, the more pertinent question is “When do we modernize?”. The Value Flywheel Effect provides a handbook for cloud modernization, joining business and technology strategies to create accelerating cycles of learning and value delivery.
This framework is composed of four key phases:
- Clarity of Purpose: Understanding the fundamental “why” behind any solution or initiative.
- Challenge: Creating an environment of high psychological safety where teams can question the status quo.
- Next Best Action: Implementing a technology strategy that enables rapid, impactful movement.
- Long-Term Value: Building for sustainable growth rather than just short-term proofs-of-concept.
Creating the Environment for Success
A system is more than just code; it includes the people, teams, customers, and stakeholders. Therefore, leadership’s primary role is to create an environment conducive to success. A critical component of this is psychological safety, which evolves through four stages:
- Inclusion Safety: Feeling part of the team.
- Learner Safety: Feeling safe to admit a lack of knowledge and to grow.
- Contributor Safety: Feeling safe to speak up and contribute ideas.
- Challenger Safety: Feeling safe to challenge anyone’s ideas, including leadership, to prevent mistakes and foster innovation.
This environment is crucial for overcoming inertia points, such as when leaders rely on outdated knowledge (“When I was an engineer…”) instead of empowering the current expertise within the team. Expertise continually evolves, while old knowledge can become stale.
A Serverless Technology Strategy for Impact
A technology strategy should be built on four pillars, moving from well-understood concepts to more emergent ones.
1. Data Platform
Beyond entities and databases, the focus must be on establishing a ubiquitous language, a core concept from Domain-Driven Design (DDD). This ensures everyone in the organization shares a common vocabulary for describing the system’s components and contexts. This approach helps in simplifying the system by isolating components and defining their interactions, moving away from the inertia of relying on traditional Entity-Relationship Diagrams (ERDs) in modern distributed systems.
2. Platform Engineering
Serverless is fundamentally event-driven. A robust platform engineering approach enables teams to build event-driven architectures efficiently. This involves creating enabling constraints, such as a sophisticated multi-account strategy to isolate workloads and providing standardized building blocks.
A key tool for managing this complexity is EventCatalog (eventcatalog.dev), an open-source project that ingests API and event specifications to create a single, observable view of all system interactions, reinforcing the ubiquitous language. This approach helps DevOps evolve from a purely infrastructural concern to a true enabler for developers.
3. System Modeling
A powerful technique for alignment is the system metaphor, a concept from Kent Beck’s Extreme Programming. It’s a simple story everyone can tell about how the system works (e.g., “a digital marketplace,” “a shopping cart”). This creates a shared understanding.
For non-functional requirements, the AWS Well-Architected Framework is essential. By creating the acronym SCARP (Security, Cost, Operational Excellence, Reliability, Performance), teams can conduct regular, blameless “pre-mortems.” Using low-fidelity dashboards, they can review metrics for these five pillars in every sprint, allowing for continuous improvement before issues become critical.
4. Engineering Excellence
The serverless-first mindset is about adopting an operational construct that reduces undifferentiated heavy lifting. It’s a spectrum where the further you move towards managed services like Lambda, DynamoDB, and S3, the fewer operational tasks engineers have to perform, allowing them to focus on business value.
“Code is a liability. The system is the asset.”
The value is not in the volume of code written but in the design of the system that the code expresses. Standardizing on a core set of services (e.g., Lambda, DynamoDB, EventBridge, Step Functions, API Gateway) for all new bounded contexts creates unification and reduces operational overhead across dozens of teams.
From Momentum to AI-Native Development
Once these foundational elements are in place—a safe environment and a solid technology platform—the organization has created shared context. This shared context is the key to unlocking the potential of new technologies like AI.
Instead of creating superficial AI proofs-of-concept, the goal should be AI-native development. New AI agents will depend on this shared context to function effectively. The conversation is already evolving from prompt engineering to context engineering. This involves understanding how to structure and provide the system’s shared context (data organization, documented standards, system thinking) to AI tools so they can effectively solve specific problems.
By focusing on clarity, environment, system-level thinking, and simplification, the Value Flywheel creates the momentum needed to not only solve today’s problems but also to be ready to harness the technologies of tomorrow.