Most engineering leaders want accountability. But the moment they try to enforce it, delivery often gets worse.
Dashboards multiply. Status meetings increase. Reporting expands.
And somehow, despite all the extra visibility, the team ships slower.
The problem usually is not the engineers. It is the system.
Why team ownership, flow metrics, and small deliverables outperform individual performance tracking.
Shipping software consistently is one of the hardest problems in engineering leadership.
Most organizations try to solve it with process. They introduce new ceremonies, more reporting, or tighter oversight. Yet delivery rarely improves. In many cases it slows down.
The reason is simple. Delivery problems are rarely caused by a lack of activity. They are usually caused by misaligned incentives, unclear expectations, and systems that encourage the wrong behaviours.
Over time I stopped thinking about accountability as something you enforce and started thinking about it as something a system either produces or suppresses.
In some environments, teams naturally push work forward. They notice when something stalls. They unblock each other. They care when delivery slows down.
In other environments, the opposite happens. Work sits in queues. Ownership becomes blurry. Leaders start asking for more reporting because no one trusts what is happening inside the system.
The difference usually is not talent. It is structure.
The systems we build around teams determine whether accountability emerges naturally or whether it has to be forced.
Set Expectations on Teams, Not Individuals
One of the fastest ways to break a development culture is to hold individual engineers responsible for delivery metrics.
Software development is a collaborative system. Features move through design, development, review, testing, and deployment. Measuring individuals inside that system almost always produces distorted behavior.
Instead, expectations should sit with the team.
When the team owns delivery outcomes together, something important happens: peer accountability emerges naturally.
If work stalls, the team notices. If someone is struggling, teammates help. If someone consistently blocks progress, the team addresses it internally long before management needs to intervene.
This shifts the role of leadership from policing individuals to creating an environment where teams can succeed together.
Why Individual Metrics Fail (Goodhart's Law)
Early in my leadership career, we experimented with tracking story points per developer per sprint as a measure of productivity.
On paper it seemed reasonable. Story points were already part of our planning process, so measuring individual throughput felt like a simple way to understand capacity.
In practice it created several unintended problems.
Other departments began treating story points as a proxy for developer performance. Product managers, commercial teams, and even sales started lobbying for the developers with the highest throughput to be assigned to their initiatives.
Inside the engineering team the effects were even worse.
Developers became less willing to help each other because assisting a teammate meant falling behind on their own story points. Some engineers began optimizing for the easiest tickets relative to their point value. Collaboration dropped while gaming the system increased.
The real breaking point came during a monthly review.
One of our developers had been out for four days that month. When leadership looked at the dashboards her story point total was significantly lower than the rest of the team.
The immediate assumption was that she was underperforming.
I suddenly found myself doing reputation management across the organization, explaining that the numbers were misleading and that she was actually a strong contributor.
At the same time we were receiving complaints about some of our most thoughtful engineers. Because they spent more time digging into complex problems, their story point output looked lower than developers working on simpler tasks.
The metric had stopped measuring productivity and started distorting it.
This is a classic example of Goodhart's Law:
"When a measure becomes a target, it ceases to be a good measure."
The moment people know they are being evaluated on a specific metric, behaviour adapts to optimize that metric.
If you measure:
- Tickets closed, work gets split artificially.
- Lines of code, codebases grow instead of improving.
- Story points delivered, estimates inflate.
None of these behaviours improve delivery. They simply optimize the metric.
The metric stops measuring reality and starts shaping it.
The problem was not the engineers. The problem was the system we created.
This is why engineering metrics should focus on system outcomes, not individual activity.
Use Flow Metrics Instead of Activity Metrics
If individual metrics do not work, what should we measure instead?
The most useful metrics focus on flow through the system rather than individual activity.
These metrics tell you whether work is actually moving from idea to production.
The Flow Metric Cheat Sheet
| Metric | What it measures | Why it's better than Velocity |
|---|---|---|
| Cycle Time | Speed of execution once work has started. | Highlights process bottlenecks like slow PR reviews or overloaded engineers. |
| Lead Time | Speed from "Idea" to "Production." | Measures the organization's ability to respond to the market. |
| WIP (Work in Progress) | Number of active tickets currently being worked. | Predicts future slowdowns before they happen (Little's Law: WIP = Throughput x Cycle Time). |
| Deployment Frequency | How often code reaches users. | Reflects the safety and automation of the delivery pipeline. |
These four metrics tell you more about delivery health than any individual productivity dashboard ever will.
When cycle time increases, something in the process is slowing work down. Reviews may be bottlenecked. Work may be too large. Teams may be overloaded with parallel tasks.
Because these metrics operate at the team level, they are much harder for individuals to game.
They measure the health of the delivery system rather than the activity of any single developer.
The Mathematics of Flow (Little's Law)
There is a simple principle from queueing theory that explains why these metrics work.
Little's Law states that:
Work In Progress = Throughput x Cycle Time
In practice, this means that when teams take on too much work simultaneously, cycle time inevitably increases.
Features sit in queues. Context switching grows. Delivery slows.
The most effective teams intentionally limit how much work they start.
Reducing work in progress shortens cycle time and improves predictability. Work moves through the system instead of getting stuck inside it.
Break Work Down Aggressively (Parkinson's Law)
Large tasks create another problem: work naturally expands to fill the time available for it.
This principle is known as Parkinson's Law:
"Work expands so as to fill the time available for its completion."
When teams are given large timelines, scope tends to grow. Edge cases appear. Discussions multiply. Stakeholders add requests.
None of these things are inherently bad, but they often delay the moment when real value reaches users.
Breaking work into small, high-value deliverables reduces this effect. Shorter cycles force prioritization and allow teams to validate progress earlier.
Use Hypothesis-Driven Development
Once work is small enough, planning can change in a meaningful way.
Instead of building large features based on assumptions, teams can frame work as hypotheses.
A hypothesis has a simple structure:
We believe that introducing X will improve Y metric for Z users. We will know this is true when we observe a measurable change.
That structure sounds simple, but it changes how teams think about delivery.
Instead of asking "What feature should we build?" the team starts asking "What assumption are we testing?"
One example from my own teams involved improving a conversion funnel.
Product originally proposed a fairly large feature: redesigning a major onboarding flow. It would have required multiple teams and several weeks of work.
Instead, we reframed the problem as a hypothesis:
We believe reducing the number of required form fields during onboarding will increase completion rate for new users.
Rather than rebuilding the entire flow, we delivered a much smaller experiment. We removed two non-essential fields and measured completion rate.
Within a week we had our answer. Completion improved noticeably, which validated the hypothesis. More importantly, we learned that the biggest friction in the flow was not design, it was cognitive load.
That insight changed the direction of the larger redesign entirely.
The team shipped something small, learned something quickly, and avoided weeks of speculative work.
This is the real power of hypothesis-driven development. The goal is not to ship more features, it is to learn faster than the problem space changes.
When Speed Becomes Its Own Problem
There is another dynamic that shows up once teams start getting faster.
When delivery improves, the natural assumption across the organization is that the team now has more capacity.
Roadmaps expand. More ideas get added. Stakeholders assume the team can ship twice as much.
Economists saw the same pattern during the industrial revolution. Efficiency improvements did not reduce consumption of resources. They increased it.
Software teams experience a similar effect. The faster a team delivers, the more demand the organization places on that team.
This creates a subtle trap. Improving engineering efficiency does not automatically create stability. It often creates more expectations.
The only reliable counterbalance is prioritization tied to outcomes instead of output. If every improvement in delivery speed simply expands the roadmap, the team will feel just as overloaded as before, only faster.
Set Teams Up to Succeed
Accountability only works when teams have the conditions needed to deliver.
One of the most important leadership lessons I learned is that teams rarely fail because engineers do not care. They fail because the system around them makes success difficult.
I once worked with a team whose cycle time kept climbing. Leadership initially assumed the engineers were simply moving too slowly.
When we looked closer, the real problem was structural.
Work items were huge. Reviews often sat for days. Engineers were juggling five or six tasks at once because new requests kept arriving before existing work finished.
From the outside it looked like a productivity problem. Inside the system it was a flow problem.
We made three changes:
- We aggressively reduced work item size.
- We limited how many tasks could be active at once.
- We clarified which work actually mattered for the next release.
Within a few weeks cycle time dropped significantly. The same engineers were suddenly delivering faster, not because they worked harder, but because the system stopped fighting them.
That experience reinforced something important for me as a leader:
Accountability is meaningless if the system makes success unlikely.
Leaders are responsible for designing environments where teams can actually deliver.
Managing Upward During the Transition
One practical challenge with this approach is that engineering leaders rarely control the entire incentive structure around them.
If executives or other departments are used to seeing individual productivity metrics, simply removing them can create anxiety.
The most effective way to handle this transition is not by arguing against metrics, but by changing which outcomes are visible.
Instead of reporting individual velocity, start reporting system outcomes:
- Cycle time trends
- Lead time to production
- Work in progress levels
- Deployment frequency
These metrics tell a much clearer story about whether the organization is actually delivering value.
When leadership sees delivery become more predictable and cycle times drop, the conversation naturally shifts away from individual output.
In other words, the goal is not to convince people that metrics are bad.
The goal is to show them better metrics that reflect how software actually gets delivered.
What About the "Slacker" Problem?
One common concern with team-based accountability is the fear that someone will hide inside the system.
If metrics focus on the team, what prevents an underperformer from coasting?
In practice, the opposite usually happens.
When delivery expectations belong to the team, slowdowns become visible to the people closest to the work. Teammates notice when tasks stall, when reviews linger, or when someone consistently needs help finishing work.
Peer accountability is far more immediate than managerial oversight.
In environments where individuals are measured directly, developers often protect their own metrics first. In team-owned systems, the incentive changes. If someone consistently struggles to contribute, the team feels the impact and addresses it quickly.
Strong teams rarely tolerate long-term coasting because it directly affects their ability to deliver together.
The Real Role of Engineering Leadership
Many leaders try to create accountability by tightening oversight.
More reporting. More status meetings. More dashboards.
But most of the time those things appear after a system has already broken down.
When teams lack clarity, leaders ask for updates.
When work moves slowly, leaders ask for more measurement.
When delivery becomes unpredictable, leaders add more process.
These responses are understandable. They are also usually symptoms of a deeper design problem.
Engineering leadership is less about monitoring output and more about shaping the environment where work happens.
When projects start falling behind, organizations tend to react in predictable ways.
More reporting is requested. More status meetings appear. New oversight roles are introduced.
All of these activities increase watching, but they do not increase doing.
Meanwhile the number of engineers actually designing, coding, reviewing, and deploying software usually stays the same. In some cases the ratio even gets worse, more oversight is added without increasing delivery capacity.
When the ratio of watching to doing increases, delivery almost always slows further.
Strong engineering organizations try to reverse that pattern by improving flow instead of increasing oversight.
If work is small, priorities are clear, and flow is visible, teams rarely need to be pushed.
They push themselves.
And when that happens, accountability stops being something leaders enforce and becomes something the system quietly produces.