What Manchester City Taught Me About Building Systems

I started following Manchester City when Pep Guardiola took over in 2016. For the past eight years, that's meant watching him build one of the most dominant systems in football history: four consecutive league titles, a Champions League, a treble. Then, in a single season, watching it collapse. One win in thirteen matches. Five consecutive losses, something that had never happened in Guardiola's entire career.

I also build systems for a living. I run engineering, product, and design for a commerce platform that coordinates inventory, orders, and logistics across thousands of stores. Somewhere around City's third consecutive title, I started noticing that the things I admired about how they played were the same things I valued in how we built software. Not as a forced metaphor. As a genuine pattern.

In this post:

1. The system, not the stars: why Guardiola's philosophy mirrors platform thinking
2. Context engineering on the pitch: coaching as constraint-setting, not scripting
3. Rodri and the single point of failure: what the 2024-25 collapse reveals about fragility
4. Reactivity over rigid planning: principles that enable fast adaptation
5. The City Football Group as a network: 13 clubs, shared methodology, player pipelines
6. When the system needs a rebuild: the question every mature system faces
7. What I take from all of this: watching football as systems practice

---

The system, not the stars

Guardiola's core belief is that the system produces outcomes, not individuals. He doesn't buy the best player for each position and tell them to express themselves. He builds a structure of spatial relationships, positional rules, and collective movement patterns. Then he recruits players who can execute within that structure.

When the system works, average players look exceptional. Joao Cancelo, a fullback, became one of the best midfielders in the Premier League because the system put him in positions where his passing ability mattered more than his defending. John Stones, a centre-back, started playing as a holding midfielder in certain phases, because the structure created space for his ability to carry the ball under pressure.

When the system breaks, exceptional players look average. That's exactly what happened in the 2024-25 season. The same squad that won the league by five points in May looked directionless by December.

This is the platform engineering insight dressed in football kit. A well-designed system amplifies the people inside it. You don't need ten brilliant engineers if the architecture, tooling, and processes make competent engineers highly effective. The inverse is also true: drop a brilliant engineer into a broken system and watch their output shrink to match the chaos around them.

The system is the multiplier. Get it right and good people produce great work. Get it wrong and great people produce mediocre work.

---

Context engineering on the pitch

Guardiola doesn't script plays. He famously loathes the term "tiki-taka," which he sees as purposeless passing. "I loathe tiki-taka," he said. "Passing for the sake of it has no purpose. You pass with a clear intention."

What he does instead is set context. He teaches players spatial principles and positional constraints, then trusts them to make decisions in real time. The coaching isn't "when the ball is here, run there." It's "when the ball is in this zone, these are the five things that should be true about the shape of the team." The players figure out how to make those things true based on what the opponent gives them.

This is context engineering applied to football. You don't script the execution layer. You give it enough structure and information to make good decisions autonomously. The quality of the output depends not on how precisely you dictate the steps, but on how well you define the constraints.

Guardiola's pre-match preparation is legendary. He studies opponents obsessively, then distills that analysis into a small number of principles for the game. Not a 50-page playbook. A few clear rules about where space will open up, which opponent to press, where the overloads should happen. He sets the context. The players execute.

I think about this every time I write a product spec or define an architecture. The temptation is always to over-specify: dictate every API contract, every state transition, every edge case. The better approach is to define the constraints clearly, explain why they exist, and let the people (or agents) closest to the problem work out the details. The spec is the spatial principle. The implementation is the player's decision on the pitch.

---

Rodri and the single point of failure

In September 2024, Rodri tore his ACL. What followed was the most dramatic collapse in English football's recent memory.

The numbers are stark. With Rodri in the 2023-24 season: four consecutive titles, a team that controlled nearly every match. Without Rodri in 2024-25: one win in thirteen, five straight losses, eliminated from the Champions League by Real Madrid, a loss to Crystal Palace in the FA Cup final, and a finish of third in the league.

Rodri wasn't just a good player. He was the single point of failure in the system. He was the player who received the ball from the defenders and decided whether to play forward, switch the angle, or recycle possession. He was the metronome that set the tempo. He was the player who understood Guardiola's positional principles so deeply that he could adjust the shape of the team in real time, without instruction from the sideline.

No backup could replicate this. Not because City lacked talented midfielders, but because Rodri's role was load-bearing in a way that no other position was. Remove the right winger and the system adapts. Remove the holding midfielder who orchestrates everything, and the entire structure loses coherence.

In engineering, we call this the bus factor: how many people need to get hit by a bus before the project stalls? If the answer is one, you have a fragile system. I've seen this in every organization I've worked in. There's always someone who is the only person who understands the payment reconciliation logic, or the only person who can debug the inventory sync pipeline, or the only person the key vendor trusts. When that person goes on leave, things slow down. When they leave the company, things break.

City's 2024-25 season is the most public, most expensive bus factor failure I've ever watched. The fix isn't "have two Rodris." The fix is designing the system so that no single component's absence causes a cascade. Easier said than done, in both football and engineering.

---

Reactivity over rigid planning

One of the things that makes Guardiola's best teams beautiful to watch is their reactivity. They don't execute a pre-set plan. They read what the opponent is doing and respond in real time.

If the opponent presses high, City play through the press with short passes from the goalkeeper. If the opponent drops deep, City circulate the ball and create overloads on the flanks. If the opponent leaves space between the lines, a midfielder drops to receive and turns to exploit it. The system doesn't prescribe a single approach. It creates a set of options and trusts the players to pick the right one based on what's in front of them.

This is the difference between a rigid plan and a set of principles that enable fast adaptation. A rigid plan breaks the moment conditions change. Principles flex.

I see this in how the best engineering teams operate. They don't follow a fixed sprint plan blindly when the requirements shift mid-week. They have clear priorities, architectural guardrails, and enough context to make good trade-offs in the moment. The sprint plan is a starting shape, not a script. When the market throws a curveball (a competitor launches a feature, a partner changes their API, a customer escalation reveals a gap), the team adjusts without waiting for someone to redraw the plan.

The worst teams I've worked with are the ones that treat the plan as sacred. The best teams treat the principles as sacred and the plan as a best guess.

---

The City Football Group as a network

Manchester City doesn't operate in isolation. They're part of City Football Group (CFG), which owns or holds stakes in 13 clubs across the world: New York City FC, Melbourne City, Girona in Spain, Troyes in France, Lommel in Belgium, and others. On the surface this looks like a financial play. Look closer and it's a systems play.

CFG operates a shared methodology across its clubs. The same playing philosophy, similar coaching principles, compatible data infrastructure. Young players develop at smaller clubs within the network, then move up when they're ready. Savinho, who joined Manchester City's squad, came through Troyes and Girona before arriving in Manchester. He'd already been playing in a system that shared City's principles. The onboarding was seamless.

This is a platform strategy applied to football. The parent organization doesn't micromanage each club. It provides shared infrastructure (scouting data, coaching methodology, medical protocols, analytics tools) and lets each club operate semi-autonomously within that framework. Each club adapts to its own league, its own market, its own competitive context. But the underlying system is shared.

I've seen this pattern work in multi-team engineering organizations. When each team builds its own authentication layer, its own logging pipeline, its own deployment tooling, you get duplication, inconsistency, and wasted effort. When you build a shared platform layer and let each team build on top of it, you get speed and coherence. The platform doesn't dictate what each team builds. It gives them the infrastructure to build faster and with fewer mistakes.

CFG is a platform org with football clubs as the product teams. Whether you find that romantic or cynical probably depends on how you feel about the commercialization of football. But as a systems thinker, I find it genuinely interesting.

---

When the system needs a rebuild

After four titles, the 2024-25 season forced a question City hadn't faced under Guardiola: does the system need iteration, or a rebuild?

The squad had aged. Key players had been together for five or six years. The patterns were so deeply ingrained that opponents had learned to read them. The tactical innovations that surprised teams in 2018 were scouted and countered by 2024. And the one player who held the system together was injured.

Guardiola extended his contract. Then he did what great system designers do: he looked at which assumptions still held and which had expired. The result was a significant rebuild in the summer of 2025. New signings like Ait-Nouri, Reijnders, and Cherki weren't just good players. They were players who could execute a different version of the system. Faster transitions, more directness, less reliance on patient buildup through a single pivot.

Every mature system faces this question. The codebase that served you well for three years starts creaking under new load patterns. The architecture that worked for ten microservices doesn't work for fifty. The organizational structure that shipped the MVP can't scale to the growth phase.

The temptation is always to patch. Add another cache layer. Hire one more person into the bottleneck team. Tweak the tactics without changing the personnel. Sometimes patching works. But when the underlying assumptions have changed (the market shifted, the technology evolved, the scale increased), patching creates a system that's complex without being capable. You end up with something that's hard to understand and still doesn't perform.

The harder choice is to identify which parts of the system are still sound and which need to be rethought from the foundation. Guardiola didn't throw away positional play. He threw away the specific version of it that depended on Rodri as the sole orchestrator. He kept the principles and rebuilt the implementation.

That's the move. Keep the principles. Rebuild the implementation.

---

What I take from all of this

I didn't expect watching football to make me better at building systems. But the pattern recognition is hard to unsee once you notice it. Systems over individuals. Context over scripts. Fragility in single points of failure. Reactivity over rigid plans. Platform thinking across organizations. Knowing when to iterate and when to rebuild.

Guardiola is, in the end, a systems designer who happens to work in football. The best engineers, product leaders, and architects are systems designers who happen to work in technology. The domains are different. The principles are the same.

Every Saturday, I watch City play and I notice things I can't unnotice. That's been worth more than any management book.

---

A personal post, not a technical one. For the systems thinking applied to engineering, see The Engineering Org of One. For reactivity as a design principle in retail systems, see Prediction Is a Crutch for Slow Systems.