I spent years as a developer with a tidy issue tracker and a recurring, stupid problem: the things that actually derailed our projects were almost never in it.
The database migration that needed a DBA who was on leave. The client contact who stopped replying for three weeks. The staging environment nobody owned. None of these were tickets. All of them cost us more than any bug we shipped.
I only got a clean vocabulary for this when I started studying project management properly. The distinction turns out to be small, old, and genuinely useful — so I want to hand it over without the certification padding.
The distinction: an issue is not a risk
Here is the whole thing:
- A risk is a problem that might happen. Future, probabilistic.
- An issue is a problem that is happening. Present, certain.
- When a risk materialises, it stops being a risk and becomes an issue.
That last line is the useful part. Risks are not a list you write once at kickoff and never revisit — they are supposed to graduate. "The lift supplier might get held up at customs" is a risk. The morning the lifts are actually sitting in a customs warehouse, it is an issue, and it needs a different response: not monitoring, but an owner and an action today.
Most teams I have seen have no mechanism for that transition. The risk list lives in a document from month one. The issue nobody saw coming lands in standup as a surprise. It was not a surprise — it was on page two.
Why your tracker can't hold this
Nothing stops you putting "lifts stuck at customs" in Jira. People do. It is just that the tracker is already doing a different job, and the two jobs fight.
Your tracker holds work you intend to do. Issues are problems blocking work you already planned. Mixed into one backlog:
- The blocker gets a priority label and sits in a column with forty other things.
- It has an assignee — but the assignee is usually whoever will do the work after the blocker clears, not the person who can clear it. Those are frequently different people, and often the blocker-clearer is not an engineer at all.
- It has no escalation path. A ticket's escalation is "move it up the backlog". A real blocker's escalation is "this needs the sponsor to make a call by Thursday".
- It closes when the code merges. But most impediments are cleared by a conversation, a decision, or a payment — nothing merges, so nothing closes.
The mismatch is not about tooling. It is that one of these is a work queue and the other is a blocker list, and a blocker list is read by different people, at a different cadence, with different authority to act.
RAID, in ninety seconds
The frame this comes from is RAID — four registers, kept separately because they get different treatment:
| What it is | What you do with it | |
|---|---|---|
| Risks | Might happen | Monitor; plan a response in advance |
| Assumptions | Believed true, unverified | Validate before it bites you |
| Issues | Happening now | Own it, date it, drive it closed |
| Dependencies | Someone else's work gates yours | Track the other party, not your own team |
It looks like bureaucracy. In practice, for a team of any size, it is four lists and a weekly ten minutes. The value is almost entirely in the separation — assumptions in particular, because an unexamined assumption is the single most common way a plan quietly becomes wrong.
What actually changes in practice
Four things, and they are cheap:
One named owner per issue — a person, not a team. "Platform team" owns nothing. Unowned issues drift, and drift is the default state of a blocker that is inconvenient for everyone.
A date, not a priority. Priorities inflate until everything is P1. A date is falsifiable: Thursday arrives and either it moved or it did not.
An explicit escalation path. Before you need it. "If this is not cleared by Thursday, it goes to X." Most blockers persist not because they are hard but because nobody knew who was allowed to decide.
Review and close, in a fixed cadence. The failure mode of every issue log is becoming a graveyard — forty open entries, half resolved months ago, nobody trusting it enough to read it. A log nobody trusts is worse than no log, because it creates the feeling of control without any.
The part that reframed the job for me
In the PM literature this task is not called "track issues". It is called remove impediments — and the framing is deliberate. Tracking is bookkeeping. The job is clearing the path in front of your team.
That reads as soft-skills fluff until you notice it changes what you do on a Tuesday. Logging "waiting on legal review" is bookkeeping. Walking to legal, finding out the review is stuck on a question nobody asked them, and answering it — that is the job. The log exists to make sure you know which path to clear, not to be the work itself.
For anyone moving from senior dev toward lead or EM: this is a large part of what the role actually is, and it is nearly invisible from the IC seat. It looks like someone going to a lot of meetings. Sometimes it is. Sometimes it is the only reason your sprint finished.
If you want the longer version
I have been writing up the PMP exam content as practical lessons while studying it, with worked examples — the one on issue logs and removing impediments is here. It covers the risk→issue escalation path in more detail, and what the exam expects you to do when a blocker appears (short version: act to clear it, don't just log it).
Full disclosure: I build VanillaPM, an open project management tool, and the lessons are part of it. They are free and ungated — I wrote them to learn the material myself, and publishing them seemed better than letting the notes rot in a folder.
The one thing worth stealing from this post, if you take nothing else: separate the problems that are happening from the work you intend to do. They need different owners, different cadences, and different people reading them. One backlog cannot do both jobs, and the one it quietly stops doing is the one that sinks projects.
Top comments (0)