Ask a good project lead how they catch work before it slips, and the honest answer is often three words: I just know.
They know the client that goes quiet before it cancels. They know which task has been “nearly done” for a suspiciously long time. They know that when a particular developer stops commenting on a ticket, it usually means he’s stuck and hasn’t said so yet. None of this is written down. It lives in one person’s head, refreshed every morning by scanning boards and reading between the lines. It works. That’s the trap.
Because if the system that catches slipping work is your memory, then you are the system. And a system made of one person’s attention has a single point of failure: that person. It holds up right until the week you’re out sick, on holiday, buried in a launch, or handed a second team to cover. The knowledge doesn’t transfer, because it was never anywhere but in your head. The moment you look away, the early warning goes with you.
“I just know” is a data model, and it’s a fragile one
It’s worth being precise about what “I just know” actually is. It’s not magic and it’s not carelessness. It’s a real model of risk, built from experience, running on human memory and refreshed by hand. Every morning you reload it: open the boards, notice what moved and what didn’t, remember which project felt fragile last week, cross-reference that against who’s on leave. Then you carry the result around all day and act on it.
That model is often genuinely good. The problem isn’t accuracy. The problem is where it’s stored. Memory is volatile. It doesn’t persist when you sleep, it doesn’t survive a holiday, and it absolutely cannot be in two places at once. So the better you are at holding it all in your head, the more completely the team depends on your head specifically, and the more quietly dangerous your own absence becomes. Being indispensable in this particular way isn’t a compliment. It’s a risk you’re carrying on the team’s behalf.
The tools don’t help, because they’re built to be read, not to conclude
The reasonable objection is: isn’t this what the project tool is for? Shouldn’t the software hold the risk map so you don’t have to?
It should. It doesn’t. Almost every mainstream tool is a pull system: it stores the raw material for the answer, tasks, dates, blockers, dependencies, and then waits for a human to come assemble it into a conclusion. The board can tell you a task is overdue, but only if you go and look. It will never lean over and say “this initiative is now at risk because that task is late and two others are waiting on it.” Reaching that conclusion is your job. So the map ends up in your head not because you failed to log things, but because the tool was only ever a filing cabinet, and a filing cabinet doesn’t notice anything. It stores; you conclude. You’re still the system. The software just gave you somewhere to put the files.
This is why the usual advice, “document more, write better handover notes, keep the board current”, helps but never solves it. A snapshot you wrote on Monday is stale by Wednesday. The living part, the daily re-reading that turns a hundred tasks into the three that matter, still runs on you. You can’t hand over a process that only exists while you’re performing it.
The fix is to move the conclusion out of your head
The way out isn’t a better memory or more discipline. It’s to make the conclusion something the system computes and keeps, instead of something a person re-derives each morning.
That’s the whole idea behind SRP. Health isn’t a field someone types and hopes to remember to update. It’s derived from the work itself, from objective signals like an open blocker, a passed date, a decision that’s gone stale, an iteration running late, recomputed continuously in the background and rolled up so one initiative can gather work from across your projects. Nobody has to notice. The verdict is calculated, stored, and pushed to you: this is slipping, and here’s the reason it’s slipping. The map that used to live in your head now lives in the tool, where it persists whether you’re looking or not.
That change is small to describe and large to feel. It means the answer to “what’s falling behind?” doesn’t disappear when you go on holiday, doesn’t reset when a new lead takes over, and doesn’t quietly degrade the week you’re stretched across three teams instead of one. The knowledge stops being yours and starts being the team’s, because it lives somewhere that doesn’t sleep.
What this doesn’t mean
It doesn’t mean the tool replaces your judgment. Deciding what to do about a slipping project, who to call, what to cut, what to reassure the client about, is still the human part, and the good part. SRP won’t run your projects and won’t catch literally everything; no tool can. What it does is take the one job you should never have been doing by hand, holding the entire risk map in working memory and refreshing it every morning, and give it to software that’s actually built to remember.
So here’s the test. Picture yourself out for a week with no laptop. Would the team still find out what’s slipping while there’s time to fix it? If the answer depends on you being reachable, you’re the system, and it’s worth moving that job somewhere it can’t call in sick.