A team can have good professionals and still deliver slowly. It can also deliver a lot and produce little result. When that happens, the easiest answer is to ask for more, hire more senior people or reorganize the squads.
The problem is that those actions treat the team as the cause before proving it is the cause.
High performance in technology is a result of the system of work. It depends on clarity about the expected outcome, boundaries of responsibility, autonomy matched to risk, manageable cognitive load, technical capability and feedback cycles that allow fast learning.
The leadership decision, then, comes before the demand. It is finding where the flow loses capacity.
High performance is not a grade on the people
It is tempting to measure performance by what is easiest to count. Closed tickets, pull requests, lines of code, story points and busy hours produce fast numbers. They can also produce a bad reading.
The SPACE framework, created by researchers from Microsoft and GitHub, starts from an important principle. Developer productivity is multidimensional. Activity is only one dimension, and satisfaction, communication, efficiency and flow matter too. No single indicator safely represents the productivity of a person or a team.
The same logic shows up in the DORA metrics. The current documentation works with five software delivery performance metrics. Three observe throughput, which are change lead time, deployment frequency and failed deployment recovery time. Two observe instability, which are change fail rate and deployment rework rate.
These metrics describe the delivery system. DORA itself recommends applying them in the context of an application or service and warns against simplistic comparisons between different teams.
That changes the question. Instead of asking who is delivering little, leadership needs to ask what is preventing this flow from producing results safely and predictably.
The first diagnosis separates a team problem from a system problem
There are signals that appear in the team but originate outside it.
If the backlog changes priority every week, the team loses focus even with good execution. If a delivery depends on five areas, waiting grows even with fast developers. If simple decisions climb many levels, autonomy exists in the speech and disappears in the work. If the scope demands too much knowledge to fit the team, the problem is not solved with more pressure.
Team Topologies treats cognitive load as a central variable of organizational design. The purpose of the team types and interaction modes is to enable value flow without requiring every team to carry all the surrounding complexity.
Before reorganizing, five symptoms are worth observing.
| Observed symptom | Likely constraint | Evidence to collect | Leadership decision |
|---|---|---|---|
| Work sits idle between stages | Dependencies, approvals or handoffs | Wait time, number of dependencies, approval queues | Redesign flow and decision rights |
| Delivery ships, then returns with fixes and incidents | Quality, architecture or change batch size | Post-deploy failures, rework, size of change | Reduce batch size, strengthen tests and remove technical fragility |
| New people take a long time to gain autonomy | Cognitive load or excessive scope | Onboarding time, number of domains and services, recurring questions | Reduce scope and abstract repetitive complexity |
| Team produces a lot, business result barely moves | Wrong priority or wrong metric | Relation between delivery and revenue, cost, deadline or risk | Reprioritize by outcome, not by volume |
| Technical decisions always wait for the same person | Weak ownership or poorly distributed authority | Escalation points, pending decisions, dependence on specialists | Define responsibility and limits of autonomy |
The usefulness of this reading is simple. It stops the organization from replacing people when it should replace the system.
Five conditions sustain reproducible performance
The team needs to know which outcome it should move
A vague objective produces a vague backlog. When the team knows the outcome, the deadline and the constraints, it makes better trade-offs.
That does not mean turning every technical decision into a financial spreadsheet. It means making clear why the work exists and which consequence matters.
A platform may aim to reduce setup time. A product may aim to reduce abandonment. A critical service may prioritize availability and recovery. The indicator changes with context, and the logic holds. Activity has to point at an outcome.
Responsibility has to match the ability to decide
A team can be called autonomous and still depend on external approval for almost everything.
Real autonomy requires clear limits. The team needs to know what it can decide alone, when it must involve another area and who answers for the service outcome over time.
Without that, the organization creates two queues. A work queue and a decision queue.
The second tends to be invisible in engineering dashboards, and it shows up in lead time.
The scope has to fit the team's cognitive capacity
Teams do not have infinite capacity for context.
When a group needs to know many domains, tools, exceptions, rules and dependencies to make a simple change, delivery becomes slower and more fragile. The four fundamental team types in Team Topologies use this problem as one of the foundations of team and platform design.
The answer is not to remove all complexity, because part of it is inherent to the business. The decision is to separate the complexity that differentiates the product from the complexity that can be absorbed by a platform, a better interface or another design of responsibility.
The technical environment has to reduce friction, not create a new queue
Tools and platforms do not create performance on their own. They create leverage when they remove repetitive work and make the safe path the easy one. It is the difference between a ticket catalog and a platform as an internal product.
Developer experience combines tools, processes and interactions. The DevEx in Action study, published by researchers from Microsoft and GitHub, found a relationship between better feedback cycles and outcomes such as innovation, quality and lower technical debt.
The executive point is not to buy more tooling. It is to observe where the system forces qualified professionals to spend energy on waiting, hunting for context and tasks that could be simplified.
Measurement has to protect the system from easy conclusions
DORA today recommends five delivery metrics and warns against using a single measure as a target.
SPACE reinforces that productivity does not fit in one dimension. In 2026, EngThrive, developed at Microsoft, organizes the reading into speed, ease and quality, with wellbeing as a guardrail.
The approaches differ, and they share a useful idea. Measuring activity alone produces an incomplete picture.
An executive performance dashboard can combine three layers.
- Business outcome, such as enabled revenue, cost, deadline, risk or another effect that makes sense for the service.
- Delivery system, with the five DORA metrics at the application or service level.
- Experience and capability, with feedback, ease of execution, cognitive load, quality and health of the work.
The combination lowers the risk of rewarding volume while the system degrades, and it is the same reasoning behind the technology capability metrics that reach the board.
When the five conditions become explicit, the conversation stops being about effort and starts being about design. That is the work of the high-performance teams capability.
AI amplifies the system that already exists
AI adoption made this diagnosis even more important.
The 2025 DORA report describes AI as an amplifier. It tends to amplify strengths and weaknesses already present in the organization, and the greatest return comes not from the tool alone but from the quality of the system receiving that capability.
If the flow is well designed, AI can cut task time and improve work cycles. If the flow already suffers from confused priorities, large change batches or weak governance, increasing production speed can also increase rework volume and pressure on later stages.
For that reason, measuring AI adoption as a synonym for performance is insufficient.
The question stays the same. Did the system get better at turning decisions into results?
How to start without reorganizing the whole company
The first move does not have to be a new org chart.
Pick a relevant flow. It can be a product, a service or a journey with a clear consequence for the business.
Then run five readings.
- Define the outcome that flow needs to move.
- Measure where work waits, returns or escalates.
- Record the dependencies between teams and decisions.
- Assess whether the scope fits the cognitive load of the responsible group.
- Create a baseline with delivery metrics and one outcome indicator.
From there, fix the largest observed constraint.
It may sit in an approval, in an architecture that demands an exception for every change, in a platform still operating as a ticket queue, in a scope that needs splitting, or in a business priority that shifts too fast to allow learning.
The point is to avoid a reorganization based on impression.
The executive test is simple
A high-performance team is not the one that looks busiest. It is the one that turns a clear priority into results predictably, safely and sustainably.
That does not remove individual responsibility. People still matter, and skill, leadership, collaboration and technical quality matter a great deal.
The difference is that the organization stops using people as the default explanation for problems the system itself produces.
Before hiring, demanding more or redrawing the org chart, find where the flow loses capacity. When the constraint becomes visible, the decision improves, and performance stops depending on heroics and becomes a property the system can repeat.
Pick one flow in your operation and answer the five readings above with data, not impression. If the largest constraint sits outside the team, the problem was never effort, and a capability assessment shows where that same constraint repeats across the rest of the operation.
Sources
- DORA. "DORA's software delivery performance metrics" (updated January 5, 2026). https://dora.dev/guides/dora-metrics/
- DORA. "State of AI-assisted Software Development 2025" (2025). https://dora.dev/research/2025/dora-report/
- Forsgren, N.; Storey, M.; Maddila, C.; Zimmermann, T.; Houck, B.; Butler, J. "The SPACE of Developer Productivity" (Microsoft Research, February 2021). https://www.microsoft.com/en-us/research/publication/the-space-of-developer-productivity-theres-more-to-it-than-you-think/
- Forsgren, N.; Kalliamvakou, E.; Noda, A.; Greiler, M.; Houck, B.; Storey, M. "DevEx in Action: A study of its tangible impacts" (Microsoft Research, January 2024). https://www.microsoft.com/en-us/research/publication/devex-in-action-a-study-of-its-tangible-impacts/
- Houck, B.; Bozarth, T.; Liu, D.; Carignan, D. "EngThrive: Make It Fast and Easy to Do Great Work" (Microsoft Research, May 2026). https://www.microsoft.com/en-us/research/publication/engthrive-make-it-fast-and-easy-to-do-great-work/
- Team Topologies. "What are the core team types in Team Topologies?". https://teamtopologies.com/key-concepts-content/what-are-the-core-team-types-in-team-topologies
- WatchZ. "High-performance technology teams". Revised editorial version, September 2026.
Note: the five conditions and the symptom table are WatchZ advisory propositions, with no correspondence to a regulatory standard or third-party framework. The DORA metrics cited follow the current five-metric documentation, which replaced the classic set of four.
