Why the tracker became the weakest link

Watch someone finish a piece of work. Really watch, at the moment the pull request goes green and merges.

There is a small pause. Then, sometimes, they switch to another tab, find the ticket, click a dropdown, choose a value, and click again. Six seconds, maybe ten with the page load. Then they go and get a coffee, because the thing they were doing is finished and their brain has already released it.

Now watch the other version, which is more common. The pull request merges. They go and get a coffee. The tab never gets opened.

Nothing has gone wrong here. Nobody is failing at their job. What you are watching is a system whose only synchronisation mechanism is a voluntary act performed at the exact moment when motivation is at its lowest and the reward is zero. It worked for twenty years because the act was rare. It stopped working when the act became frequent, and the interesting question is not how to make people click the dropdown. It is why the dropdown exists at all.

What the tracker was designed for

I want to be fair to the tracker, because it is fashionable to dunk on Jira and most of the dunking is misdirected. The tools are not badly built. They solved a real problem extremely well for a world that has changed underneath them.

That world had four properties.

Work was slow enough that manual updates were negligible overhead. A task took days. Recording its state took seconds. The ratio was so favourable that nobody thought about it, and an entire management practice could be founded on those seconds being free.

The set of people who did the work and the set who needed to know were nearly disjoint. Developers built, managers reported. The tracker was the interface between them, and its whole design (fields, workflows, permissions, reports) is the design of an interface for an audience that cannot read the underlying system.

The work itself was not machine-readable. In 2005, there was no way for a computer to determine whether a task was done. The information existed only in a person’s head. So of course the tracker asked the person. It was not a lazy design, it was the only possible design.

And a ticket was roughly a unit of human effort. One ticket, one person, one to five days. The granularity of the tracker matched the granularity of the work, which meant the board was a legible picture of who was doing what.

Every one of those four is now false or badly weakened. That is not a criticism of the tool. It is what obsolescence looks like: the tool works exactly as designed and the design describes something that is no longer there.

Work was slow enough that updates were negligibleA task took days, recording it took seconds. The ratio was so favourable nobody thought about it.

Doers and knowers were nearly disjointDevelopers built, managers reported. The tracker was the interface between two separate populations.

The work was not machine-readableIn 2005 no computer could tell whether a task was done. The information existed only in a person's head.

A ticket was a unit of human effortOne ticket, one person, one to five days. Tracker granularity matched work granularity.

The four assumptions failing

Take them in turn, because each failure produces a distinct symptom that teams usually treat as unrelated.

Speed. When changes come at four times the rate, the manual update tax rises fourfold and lands during the worst possible moment of the work cycle. Compliance drops. But it does not drop uniformly, which is the poisonous part. It drops for small changes, routine changes and end-of-week changes. So the board is not randomly wrong, it is systematically wrong in a direction that makes routine work invisible and dramatic work overrepresented. Any conclusion you draw about where effort goes is skewed by the same bias.

Audience. The people who need to know what is happening are no longer just managers. Agents need to know. When an agent picks up work, decides what to build, or checks whether something is already in progress, it consults the tracker, which is a stale human-maintained description. You now have a fast system taking direction from a slow one, which produces a specific new failure: two agents implementing the same ticket, or an agent building on top of a “not started” ticket that shipped last week.

Machine-readability. This is the assumption whose failure is most useful, because it failed in the good direction. In 2005 you could not compute whether work was done. Now you very often can. The branch exists, the pull request merged, the tests pass, the criteria evaluate true. The information the tracker asks a human to type is, for a large share of work, already sitting in a system that knows it exactly. Asking a person for it is asking them to transcribe from a machine that could have told you directly. That is the strongest argument against the manual model and it is not an argument about laziness at all.

Granularity. A ticket used to be a unit of human effort. Now a single ticket might be six pull requests from three agent sessions and a human, or three tickets might be satisfied by one change that touched a shared module. The mapping between the planning artefact and the work artefact has come apart, and no amount of “write better tickets” fixes it, because the underlying unit sizes genuinely no longer correspond.

The symptom nobody escalates

Here is what makes this the weakest link rather than merely a weak one.

A slow tracker is annoying. A tracker with an unknown error rate is dangerous, and the danger is entirely in the word “unknown.”

If your board is uniformly two days stale, you can work with that. Everyone applies a mental correction. But that is not how it degrades. It degrades unevenly: some tickets are current because someone happened to be in the tool, some are three weeks behind, and there is no way to tell which is which by looking. Every item on the board carries an invisible confidence interval, and they are all different.

An organisation cannot apply a mental correction to that, so it does the only other thing available: it treats the board as true. Roadmaps get built on it. Reprioritisation happens on it. Customers get dates from it. Capacity gets planned from it. The whole apparatus continues at full confidence on data whose error rate nobody has measured, and the errors surface one at a time, as surprises, each of which gets attributed to a local cause. “The team underestimated.” “There was a dependency we missed.” Almost never: “our system of record was wrong and we did not know.”

A board that is uniformly two days stale is workable. Everyone applies a mental correction. But that is not how it degrades.

It degrades unevenly, so the error rate is unknown, and an organisation cannot correct for unknown. So it does the only other thing available: it treats the board as true.

That is why I call it the weakest link. Not because it is the most broken component, but because it is the component that everything else trusts, and its failure mode is invisible.

What people try, and why it does not hold

Automation rules inside the tracker. Move the ticket when the pull request merges. This is the right instinct and it helps, genuinely. It is limited by the fact that it can only see what the tracker’s integration surfaces, and it fires on merge rather than on outcome. Merged is not done. You get a faster board that is confidently wrong about the same thing it was slowly wrong about before.

Making the tracker mandatory in the workflow. Cannot merge without a ticket reference. Effective at the linking problem and worth doing. Does nothing about state, and it generates a small amount of resentment plus a nonzero number of tickets created purely to satisfy the gate, which pollutes the data you were trying to protect.

Simplifying the workflow. Three states instead of nine. This genuinely helps compliance, and I would recommend it to anyone. It also loses the information that made the board useful for anything other than a rough burndown, so you have traded accuracy for resolution.

Abandoning the tracker. Some teams do this and are happier. It works up to a size and then reintroduces itself under a different name, usually a spreadsheet, which has all the same properties plus no history.

Each of these is a reasonable response to a symptom. None addresses the structural problem, which is that the tracker asks humans for information that a machine already has, at a moment when humans are least inclined to give it, at a frequency that keeps rising.

The reframe

The tracker’s problem is not that it is a bad database of work. It is that it is being used as a system of record when it is only capable of being a system of intent.

That distinction is worth keeping. Intent is genuinely valuable and genuinely human: what do we want, why, in what order, for whom, what does success look like. No repository knows that. The tracker is a good home for it, arguably the only good home for it.

Record is a different job: what is actually true right now. The tracker is structurally bad at this, because the information lives elsewhere and reaches it only by voluntary human transcription.

So the resolution is not to replace the tracker. It is to stop asking it to do the job it cannot do. Let it hold intent, including acceptance criteria specific enough to be checked. Derive the record from source control. Write the derived record back into the tracker so that the people and processes that live there see something true, without anyone typing it.

That is a smaller and less dramatic conclusion than “trackers are dead,” and I think it is the correct one. Your tracker is fine. It is being asked the wrong question by everybody, all day.

System of record

• What is actually true right now
• Information lives elsewhere
• Reaches the tracker by voluntary transcription
• At the moment of lowest motivation
• The job it structurally cannot do

System of intent

• What we want, why, in what order, for whom
• Genuinely human and genuinely valuable
• No repository knows any of it
• Acceptance criteria specific enough to check
• The job it is good at

Where this breaks down

The tracker is often more wrong about intent than about state, and I have let it off lightly. Tickets that describe a solution rather than a problem, tickets that have been open for a year, epics that no longer correspond to anything anyone wants. Deriving state perfectly on top of rotten intent gives you an accurate account of progress toward the wrong destination. If your backlog is mostly archaeology, fixing status derivation is not your first problem.

Some teams’ trackers really are fine. Small teams with strong habits genuinely do keep boards current, and for them this entire piece is a solution to an absent problem. The tell is whether you can look at the board and believe it without checking. If you can, do nothing.

Derived status can be wrong in newer and less obvious ways. A ticket satisfied by a change that never referenced it stays “not started” forever. A pull request touching four tickets moves all four. Work done in a branch that is abandoned and re-done elsewhere leaves a trail that reads as progress. Human-maintained status is wrong in ways people have twenty years of intuition about. Machine-derived status is wrong in ways nobody has intuition about yet, and that unfamiliarity is a real cost during the first few months.

And there is a version of this argument that goes too far. If you conclude that the board should be fully automatic and no human should ever touch it, you lose something. The manual update was terrible as a synchronisation mechanism and occasionally excellent as a moment of reflection: the person paused, looked at what they had done, and made a small judgement about it. Automating it away removes a friction that was mostly waste and partly thinking. I do not think that changes the conclusion, but I would not want to pretend nothing is lost.

The takeaway

The tracker assumed slow work, a separate audience, work that machines could not read, and a ticket that equalled a unit of human effort. All four have failed, and the result is a system of record with an unknown and non-uniform error rate that the entire organisation trusts anyway.

The fix is not a better tracker or stricter process. It is a division of labour: the tracker holds intent, including criteria specific enough to check, and the record derives itself from source control and writes back.

The next piece takes on the objection that most often stops teams from doing any of this: the belief that you must choose between letting agents move fast and keeping control of what they do. That trade-off is not real, and the reason it feels real is worth unpacking.