When a Priority Marker Pretended to Be a Status Field

Our work list was full of items labeled “active now” that were finished, paused, or merely planned. The more we leaned on that list, the less it described what we were actually doing.

We had used one field to carry two ideas. A priority-like marker was standing in for current focus, while the formal status described the lifecycle of the work. The lifecycle moved when work moved forward. The priority marker often stayed put. Over time the same label meant both “we are working on this now” and “we worked on this at some point,” and those are different claims.

Contradictions, not volume

A long queue is not automatically a problem. A queue whose fields disagree with each other is.

Start by comparing the work a surface calls active with the work whose lifecycle state says it is unfinished and underway. Then sample the items instead of trusting the aggregate. These are the contradictions to look for:

• a high-priority item that is explicitly not started;
• a completed item still presented as current work;
• a blocked item with no owner or next review date;
• a follow-up that exists but cannot be found from the work that created it;
• a container that looks current but has been archived, abandoned, or turned into a catch-all.

These defects change the decisions people make. If a board says everything is urgent, nothing is meaningfully urgent. If it says planned work is active, people spend their attention triaging a picture of the past.

What a priority marker does and doesn’t hold

The correction that mattered was seeing that a priority marker only changes how a surface orders work. It does not preserve anything. You should be able to lower an inactive item’s priority without making it disappear, because the item stays findable through durable relationships: a current project or workstream, an accountable owner, a clear next action, and a real link to any follow-on work.

That doesn’t make changing priority risk-free. Before a cleanup, check that the work has a live home and that there is a deliberate way to recover or reconsider it. A task with no meaningful parent, owner, relationship, or review date can drop out of attention even though the system still stores it.

So the useful question is whether the right person will be able to find the item and understand what should happen next. Whether it still exists matters less.

The order we cleaned up in

We did not start by bulk-changing the label that makes work visible. We rebuilt the navigation around the work first.

1. Clarify lifecycle states. Define what “planned,” “in progress,” “blocked,” “ready for review,” and “complete” mean in observable terms.
2. Restore durable ownership. Give every non-complete item an accountable owner, a meaningful home, and a next action or review date.
3. Repair relationships. Make follow-ups, dependencies, and replacements explicit in the system, rather than leaning on a free-text field or remembered context to carry them.
4. Split catch-all containers. A generic maintenance bucket is still a form of hiding when it is the only explanation for why unrelated work belongs together.
5. Then adjust priority. Once work can be found through its lifecycle, ownership, and relationships, priority goes back to its narrower job: helping people choose among the work that is ready for attention.

Make the change through an authorized, reviewable process. Keep an audit trail of material reclassification, validate that the intended views still return the right work, and retain a recovery path in case an item is accidentally moved or hidden. If automation helps identify stale work, have it produce suggestions and evidence, and leave the decisions about ownership or priority to a reviewer.

A work queue is a decision surface, and it has to be honest about what is happening, what is waiting, and what is merely remembered. When priority and status drift apart, fix the model before you blame the people trying to use it.

Related

• The cheapest fix to a backlog is often splitting one overloaded state: making ownership and waiting visible instead of hiding both inside one label
• The omnibus ticket is a coordination tax: matching the shape of work to the way people must verify and hand it off

dxdev LESSON · paste into your AI agent

LESSON: Apply the Lesson: When a work queue stops telling the truth

WHAT TO SHARE:
A short description of the work, the problem you are seeing, the constraints that matter, and any de-identified examples or notes you want reviewed.

ASK YOUR AGENT TO:
1. Restate the problem in plain language and identify the assumption that needs checking.
2. Separate observations from guesses and list the evidence that is still missing.
3. Suggest a small, reversible next step or review plan that fits the situation.
4. Identify the decisions, approvals, and safeguards that should remain with a person.

RETURN:
A concise table with the problem, evidence to check, safe next step, human owner, and questions to resolve.

BOUNDARY: Analyze and recommend only. Do not alter code, records, files, permissions, settings, external systems, or published content. A responsible person must review and approve any action.