The Difference Between High-Performing Teams and High-Performing Systems

I've worked with some genuinely exceptional engineering teams. Talented, collaborative, technically rigorous. Teams that would be elite by almost any measure of individual or team performance.

And some of them were still slow. Still couldn't ship. Still got beaten to market by competitors running on inferior technology with weaker engineers.

The reason, almost without exception: the system they were operating within was the constraint - not the team.

This is one of the most important and most neglected ideas in engineering leadership. We spend enormous energy optimising teams - hiring, coaching, retros, psychological safety, ways of working - while leaving the organisational system largely untouched. The system wins. It always wins.

---

The Constraint Dominates

This isn't a theory. It's basic systems thinking - and it plays out in engineering organisations every day.

Imagine a team that can develop and unit-test a feature in two days. Now add a shared QA environment that books up two weeks in advance. Add a change approval committee that meets fortnightly. Add a deployment pipeline that takes four hours and has a 30% flakiness rate. Add an architecture where a single team's release requires coordinating five other teams.

That exceptional two-day team is now delivering monthly. And the problem has nothing to do with the team.

Eliyahu Goldratt's Theory of Constraints is unambiguous: the throughput of any system is determined by its bottleneck. Improving anything that isn't the bottleneck does not improve system throughput. It just creates more work piling up behind the constraint.

---

What Conway's Law Is Actually Saying

Mel Conway observed in 1968 that organisations design systems that mirror their communication structures. This has been repeatedly validated since. The inverse - that your communication structures mirror your system design - is equally true and equally important.

If you have tightly coupled architecture, you have tightly coupled teams. Tightly coupled teams create coordination overhead. Coordination overhead kills flow. Slow flow is an architectural problem as much as a technical one.

The move to microservices promised independent deployability - the ability for a single team to release without coordinating with others. But many organisations implemented microservices without the corresponding team structure. They ended up with distributed monoliths: all the complexity of microservices, none of the independence.

Team Topologies calls this out directly. Fast flow requires team cognitive load to be managed, interaction modes to be explicit, and dependencies to be deliberately minimised. This is a system design problem, not a team capability problem.

---

The High-Performance Illusion

Here is what a high-performing team in a weak system looks like:

• They ship features quickly... to a staging environment that's always broken.
• They write excellent code... that takes six weeks to get through the release process.
• They have strong retrospectives... about problems they have no authority to fix.
• They are engaged, motivated, capable... and quietly starting to look for new jobs.

The tragedy is that talented people in dysfunctional systems often blame themselves. They work longer hours. They find workarounds. They absorb the system's dysfunction through heroics. And for a while, it works - until it doesn't, and they burn out.

I have seen this pattern in organisations of every size. The team absorbs the system's problems until the team breaks.

---

What System-Level Performance Actually Looks Like

A high-performing system has different characteristics to a high-performing team:

• Low coupling, high cohesion - teams own meaningful slices of capability end-to-end, minimising the need for coordination
• Fast feedback everywhere - automated quality gates, observable production systems, short learning cycles
• Deployment is boring - releases are so routine that nobody is stressed about them
• Governance enables rather than gates - compliance is built into the pipeline, not applied as a manual checkpoint at the end
• Constraints are visible and owned - the organisation knows where the bottlenecks are and has someone responsible for fixing them

These are system properties. No amount of team coaching produces them. They require deliberate architectural decisions, investment in platform capability, and organisational design changes that leadership must own.

---

The BVSSH System View

Better Value Sooner Safer Happier is a system-level outcome framework. This is not accidental. Jonathan Smart was explicit: these outcomes cannot be achieved by individual teams in isolation. They are the product of an entire organisational system working in concert.

Sooner requires flow across the system - from idea to production, not just from ticket to code review. Safer requires quality to be built into the pipeline, not checked at the gate. Happier requires teams to have genuine agency, which means the system must actually allow it.

The teams that deliver these outcomes consistently aren't the ones with the best developers. They're the ones operating within systems designed to let good developers do good work without fighting the organisation every step of the way.

If your transformation programme is focused exclusively on team-level improvements, you're working on the wrong constraint. The system is the product. Design it deliberately.