In early 2021, the idea that would eventually become The Value Flywheel Effect was little more than a set of shared frustrations, whiteboard sketches, and long conversations between practitioners who had spent years modernising large, complex systems.
Fast forward to 2026, and that idea has turned into a published book, conference talks across the world, and—more importantly—a set of principles that continue to show up inside real organisations doing real work.
In this article, we took the opportunity to pause and reflect. Not to recap chapters or rehash frameworks, but to ask a more interesting question:
What did writing the book actually teach us about building software, organisations, and sustainable change?
This post captures those reflections.
Writing a Book Is Not What You Think It Is
Most engineers assume writing a book is “just” writing. Words on a page. Chapters. Diagrams. Job done.
It isn’t.
Writing The Value Flywheel Effect took years—not because we lacked content, but because shared context doesn’t scale. What made perfect sense to three people who had worked together for over a decade often made no sense at all to an external reader.
The hard part wasn’t ideation. That was the fun bit:
- Capturing ideas
- Writing short essays
- Stress-testing thinking in small, low-risk ways
The hard part was shaping those ideas into something coherent, paced, and accessible to an audience we couldn’t see.
That’s when you realise:
Writing is a refactoring exercise.
And like any serious refactor, you don’t get it right the first—or fifth—time.
“You No Longer Own This”
One line from the editing process has stayed with us more than any other:
“You no longer own this.”
It sounds harsh until you understand what it really means.
At that point, the book stopped being ours and became a shared artefact—shaped by editors, reviewers, and ultimately readers. Repetition was removed. Ideas were challenged. Entire sections were restructured or deleted.
The final published book looked nothing like the first manuscript.
That experience mirrors modern software delivery more closely than most people expect:
- Ownership shifts from individuals to teams
- Progress comes from challenge, not protection
- Quality improves when ego steps aside
If that sounds uncomfortable, it should. Growth usually is.
The Introduction Problem (and Why It Matters)
Ironically, the hardest part of the entire book to write was the introduction.
For over a year, it never quite worked. It felt flat. Unclear. Disconnected.
The breakthrough came only after the rest of the book was finished.
That taught us something important: you don’t always understand the story you’re telling until you’ve told it.
This shows up constantly in architecture and transformation work. Teams want to define the strategy upfront, but clarity often emerges through delivery, not before it.
You still need intent—but you also need the humility to revisit it once reality intervenes.
Impact Is Hard to Measure (But You Know It When You See It)
Books don’t come with telemetry.
You never really know whether someone:
- Skimmed a chapter
- Used one idea
- Or redesigned an entire platform around it
What you do get, occasionally, are moments of signal.
A conversation at a conference.
A message from a practitioner.
A senior leader casually mentioning the flywheel in a context you never expected.
Sometimes, impact whispers rather than shouts.
And when your target audience is niche—technical leaders inside already-complex organisations—that’s exactly what you’d expect.
The Surprising Part: AI Made the Book More Relevant
We wrote the book before ChatGPT, before mainstream GenAI, before “agentic” became a prefix for everything.
And yet, many of the ideas have aged remarkably well.
Why?
Because AI doesn’t remove the need for:
- Clear purpose (North Stars)
- Deliberate architecture
- Explicit constraints
- Thoughtful governance
If anything, it amplifies the value of codified thinking.
When you feed an AI system:
- A well-defined operating model
- Clear architectural principles
- Explicit organisational constraints
You get dramatically better outcomes.
The flywheel becomes context.
Context becomes leverage.
AI lowers the barrier to entry, but it does not replace judgement. Teams still need to understand which outputs are nonsense, which are average, and which are worth pursuing.
Critical thinking didn’t disappear. It just became more important.
Business Strategy vs Technical Strategy Was Always a False Divide
One of the core premises of The Value Flywheel Effect was that business strategy and technical strategy are inseparable.
Five years on, that divide has blurred even further.
Builders today need to understand:
- Business intent
- User value
- Security and compliance
- Platform constraints
- Delivery economics
At the same time, product and business roles are being pulled closer to implementation through prototypes, AI-assisted development, and working software as the primary artefact.
The emerging persona isn’t “business” or “tech”.
It’s the builder.
And the real challenge is removing friction from the builder’s environment—without removing responsibility.
Letting Go Is the Price of Scale
Looking back, the biggest lesson from writing the book isn’t about serverless, platforms, or cloud at all.
It’s this:
If you want impact at scale, you have to let go of ownership.
That applies to:
- Code
- Architecture
- Platforms
- Ideas
- And yes, books
Letting go doesn’t mean lowering standards.
It means creating systems where standards can survive without you.
That, ultimately, is what the flywheel was always about.
What’s Next?
We’re now seeing the emergence of AI-native SDLCs, agent orchestration frameworks, and new models of delivery that would have felt speculative in 2021.
But the underlying questions remain the same:
- How do we respond to opportunity faster?
- How do we manage risk without paralysis?
- How do we create long-term value, not short-term output?
Those are the questions we’ll keep exploring—on Serverless Crack, on The Serverless Edge, and in the work itself.
The conversation isn’t finished.
If anything, it’s just spinning faster.