You're accountable for things you don't control. Put that in writing.

The gap between what you answer for and what you actually decide is where delivery careers quietly die. Here's how to manage it on paper.

Here's a fun exercise. Write down everything your project needs to hit its date. Now circle the items you actually control. Not influence. Control. For most Scrum Masters and project managers, the circle covers maybe a third of the list.

The vendor's delivery date. The QA environment staying up. The Product Owner showing up to refinement. The exec signing off on scope. The platform team picking up your ticket this sprint instead of next. None of it is yours to decide. All of it is yours to answer for.

Nobody puts this in the job description. The framework doesn't mention it either. Scrum hands the Scrum Master accountability for the team's effectiveness and then gives them exactly zero authority over the things that wreck it. Traditional PM is worse: you own the baseline, and the baseline is built on twelve promises other people made.

Most people respond to this gap in one of two ways. They absorb it quietly and burn out, or they complain about it in meetings and get labelled negative. There's a third option, and it's the one that actually works: name the gap, in writing, before it bites.

The part of your job that was never on the org chart

Think about what accountability without control actually looks like on a Tuesday.

A release depends on a vendor API fix. The vendor reports to a procurement relationship three levels above you. Their date slips. Your date slips. In the steering meeting, nobody asks the vendor to explain. They ask you.

That's not a broken org. That's the job. Delivery roles exist precisely because outcomes depend on people who don't report to anyone in the room. If everything your project needed sat inside one team's authority, they wouldn't need you.

So the question was never how to close the gap. You can't. The question is who carries the risk that lives inside it, and whether that risk is visible before it detonates or only after.

Why saying it out loud doesn't count

You probably already flag these risks. Verbally. In standup, in the hallway, in the steering call. "Just so everyone knows, we're waiting on the vendor." Heads nod. Meeting ends.

Here's the uncomfortable truth: a spoken risk has a half-life of about one meeting. When the date slips six weeks later, nobody remembers the caveat. They remember the date. The slip gets attached to the last name on the plan, and that name is yours.

Spoken flags fail for a simple reason. They don't create a record, they don't force a decision, and they don't move the risk to the person who can actually retire it. They just make you feel like you said something.

Writing does three things talking can't. It timestamps the risk before the outcome is known, so it reads as foresight instead of excuse. It forces you to be specific, because vague dread looks ridiculous in a sentence. And it puts the dependency in front of the one audience that can act on it, in a form they can forward.

The same slip, replayed twice

I watched one slip play out both ways, about a year apart, same company, different PMs. Worth replaying.

Round one. A payments integration needed a test environment refresh from the infra team. The PM raised it in three standups and once in the weekly sync. Infra was buried in an audit. The refresh landed two weeks late, UAT compressed from ten days to three, and a defect that would've been caught sailed into production. In the post-incident review, the question on the table wasn't "why was infra late." It was "why didn't the project flag this." She had flagged it. Four times. Out loud. There was no evidence, so the flag didn't exist, and she spent the next quarter rebuilding credibility she'd never actually lost.

Round two. Different PM, same dependency, same buried infra team. In week two he sent a five-line note to the sponsor: the refresh date he needed, infra's current commitment, what a two-week slip would do to UAT, his fallback, and the date he'd escalate if nothing moved. The sponsor forwarded it to infra's director with one line on top. The refresh landed three days late instead of fourteen. Nobody got blamed, because nothing blew up. The sponsor started inviting him to planning sessions he had no formal business being in.

Same gap. Same lack of control. The only variable was whether the risk lived in the air or on paper.

Four lines that cover you and move the project

You don't need a risk register with forty rows that nobody reads. For any commitment that depends on something outside your control, write four lines.

• What I'm owning. The commitment, stated plainly. "UAT ready for the 14th."

• What it depends on. The thing you don't control, with its own date attached. "Vendor fix, promised for the 10th."

• What happens if it slips. The consequence, sized honestly, plus your fallback. "Each day late moves UAT a day. Plan B is testing against the stub, which covers 70 percent of cases."

• What I'm doing about it. Your active moves. "Daily check with the vendor PM. Escalation booked with procurement for Thursday if the build isn't in."

Send it to the person who owns the decision, not just your team channel. Then keep it updated. Thirty seconds a day, maybe.

Notice what the four lines are not. They're not a complaint. There's no "as previously mentioned," no sigh in text form. Every line is a fact or an action. That's what separates a professional putting risk where it belongs from someone building a paper trail of grievances.

The tone test: protection without defensiveness

Some people hear "put it in writing" and produce something that reads like a legal deposition. That lands badly, and it should. If your note's only job is to prove you innocent later, people can smell it.

The test is simple. Read your note and ask: does this help the reader make a better decision this week? A good dependency note gives the decision-maker a chance to lean on the vendor, buy the contingency, or move the date early, while moving is still cheap. The protection you get is a side effect of being useful. That's why it works.

One more tone rule: write it the same week things are calm, not the week they're on fire. A note sent after the slip is a defence. The same note sent six weeks before is a service. Timing is most of the difference between the two.

When they ask about managing risk in your next interview, this is what they're fishing for, by the way. Not the definition of a RAID log. They want to know whether you make invisible risk visible early, to the right person, in a way that creates options. One true story about a four-line note that moved an escalation two weeks earlier is worth more than every framework term you know.

What changes when the gap is on paper

The first thing that changes is practical. Written dependencies get acted on at a rate spoken ones never do, because forwarding an email to a vendor's account manager is easy and recalling a hallway comment is impossible.

The second thing is slower and bigger. You stop being the person who absorbs every slip, and you start being the person who saw it coming and had a plan B priced. Leadership keeps a quiet mental ledger of who creates clarity under pressure. Four honest lines, sent early, consistently, is how you get on the right side of it.

You'll still be accountable for things you don't control next quarter. That part never changes, in this role or the ones above it. What changes is whether the gap runs you, or you run the gap.

Start this week. Pick the one dependency most likely to hurt you, write the four lines, and send them to the person who can actually do something. That's the whole move.