The System Gambit test
My AWS Enterprise Transformation Community experience. A real loop, but a fragile position.
I have used Rumelt and Martin for years because they force the hard work most teams try to skip. Rumelt makes you find the Crux. Martin makes you choose where to play, how to win, which capabilities must exist and which management systems must hold the whole thing together.
That sequence works. It has saved me from more bad strategy decks than I can count. But it still starts one step too late.
Ritavan’s The System Gambit starts before diagnosis.
It asks a harsher question before you spend time on architecture, workshops and operating plans:
Are you building a position that compounds through its own internal loop, or are you funding a solid intervention inside someone else’s game?
That question touched me because I have one AWS experience that fits it almost perfectly. Almost.
The primary filter
Actually, I do not read The System Gambit as a replacement for Rumelt or Martin. I read it as a gate before both.
The gate is simple and uncomfortable in the right way:
A full system gambit needs self-improvement, path-dependence and management logic antagonism at the same time.
Self-improvement means each cycle makes the next cycle stronger without equivalent new input. Path-dependence means the position gets harder to copy because the loop had to be built over time. Management logic antagonism means the new loop requires behaviors, incentives and priorities that clash with the logic that made the current system successful.
Miss one condition and the judgment changes. You may still have a very good investment. You do not yet have a full system gambit.
That difference sounds academic until you test it against something real. Then it stops being a clever frame and starts cutting.
The AWS Enterprise Transformation Community of Practice
At AWS, the problem was never a shortage of answers. The problem was “answer overload”.
AWS was running on classic Amazon startup logic - high autonomy, strong local ownership, fast invention and very little patience for central drag. That logic produced serious customer value. It also produced a field full of overlapping methods, competing narratives, duplicated assets and too many silver bullets aimed at the same enterprise problem.
For enterprise customers, this abundance actually looked like noise. For account teams, it looked like friction. People could offer a lot. They could not always tell which path was proven, sequenced and right for the customer’s stage of change.
The AWS Enterprise Transformation Community of Practice was built to reduce that noise. Its job was to turn scattered field experience into a reusable loop:
Cloud journeys, blockers, solutions, guided learning paths, expert discovery, contribution tracking and feedback from accounts back into service teams.
The platform idea behind it was concrete. Replace the sprawl of wiki pages, Chime rooms, WorkDocs, Quip, Salesforce, MindTickle and manual trackers with one member experience that could hold the field memory together.
That phrase matters here. Field memory. Because that is what the community was trying to become.
A good customer conversation exposed better blockers. Better blocker visibility pulled in the right experts. Better expert swarming produced sharper assets and solutions. Better assets improved enablement. Better enablement improved the next customer conversation.
One 2019 experiment made the loop visible in numbers. The game-a-thons widened participation and drove a 400 percent increase in blockers identified in a quarter and a 300 percent increase in solutions identified in a quarter.
So the loop was real. Without a doubt, but..
Our community was not a real System Gambit
Run that AWS case through Ritavan’s filter and the answer becomes cleaner than many builders would like.
The AWS Enterprise Transformation Community of Practice was a good investment. But it was not a full System Gambit.
The first condition - self-improvement - was present. The more journeys, blockers, solutions, experts and learning paths the community accumulated, the more useful it became to the next field seller, the next architect and the next customer situation.
The second condition - path-dependence - was weaker. The community had trust, operating history and social capital. Those are real assets. But a rival hyperscaler with enough field scale, leadership backing and internal tooling could build a similar expert network, blocker library and enablement system. They could not copy the exact history. They could copy the capability class.
The third condition is where the case really breaks. The community depended on protected contribution time inside a company strongly optimized for immediate delivery and local ownership. Later, AWS management removed the protected 10 percent community time. That decision did not erase the idea or prove the community useless. It removed the operating oxygen the loop needed to keep feeding itself. Community members were no longer allowed to spend company time on community activities. Professional Services’ utilization metric won. And at that moment, The Community stopped being a community.
This operational line really matters. Strategy people love talking about flywheels. Far fewer are willing to support the payroll condition that keeps the wheel turning.
And this is where the argument gets more interesting, not less. The old AWS logic was not stupid. Local autonomy, speed and customer obsession were exactly what made the company formidable in the first place. The same logic that made the community necessary also made it institutionally fragile.
That is real management logic antagonism. Shared memory needed protected commons time. The dominant operating system kept pulling resources back toward near-term local delivery. Both sides were rational. They were both rational but against different values.
Let’s steelman this
A smart skeptic can push back here. They can say the community lasted, delivered value, remained functional after 2022 and improved reuse across enterprise transformation work. They would be right to say that.
They can also say that replicability is often overstated by strategy frameworks. Plenty of organizations fail to copy things that are visible in plain sight because they cannot copy trust, internal reputation and the social fabric around contribution. That is also true.
But that counterargument still falls short of the full claim.
A full system gambit does more than create a useful loop. It creates a position whose logic becomes harder and harder to defund, dislodge or reproduce as the loop strengthens.
That did not happen at AWS. The community needed continued management’s shelter. When the protected 10 percent time went away, the system showed its dependence on sponsorship and slack rather than its own growing inevitability.
Why Ritavan’s frame matters to me
Because it sharpens the entry test before I reach for Rumelt and Martin.
First ask whether the game can compound through its own loop.
Then diagnose the Crux.
Then design the choices, capabilities and systems.
Without that first filter, strong operators can spend months improving something that will always remain a funded intervention rather than a compounding position. The work can still be valuable. It just belongs in a different bucket.
That is the bucket I would put the AWS Enterprise Transformation Community of Practice in. It solved a real problem. It reduced field noise. It improved reuse. It built a functioning memory layer across enterprise transformation work.
But it did not become structurally irreversible. It stayed useful, yet broadly reproducible. It worked, yet still depended on active protection from the very management logic it was trying to correct.
Good investment, not a full system gambit.
A meaner standard
Too much strategy writing hands out gold medals for loops that have not earned them. This framework forces a meaner standard.
The AWS case met that standard in one place, half-met it in another and failed it where it mattered most. The loop improved with use. The history had value. The management system never stopped being able to starve it.
That is why the lesson is not triumph and it is not failure.
It is tension.
Some systems die because the idea was weak.
Others die because the institution refuses to keep funding the behavior that made the idea work.
The difference between those two deaths is where the real diagnostic work begins.
Before you close the article
This is the kind of diagnostic work I do before any transformation mandate starts. Not after the operating model is designed. Before.
If this helped you see the difference between a compounding position and a funded intervention, do two things.
First, send it to someone who is currently building a loop inside their organisation and calling it a flywheel. They need the filter before they need the architecture.
Second, subscribe. I write these to sharpen the entry test before the expensive work begins. The next piece will be just as uncomfortable.
And if this was worth a coffee: buymeacoffee.com/andreisavine