Guardrails

This is for anyone drawing the line between what someone can decide alone and what needs to come back to you: a lead delegating to a report, a PM writing a brief, a PE reviewing a PR, anyone handing off work at all.

It is built as a kernel: what is actually going wrong, the policy we chose, and what we do because of it.

The diagnosis: an unmarked line keeps you in the loop, just later#

Handing off work without saying which decisions are guarded and which are free produces one of two failures, and both keep you in the loop instead of getting you out of it.

Spell out everything: the stack, the file layout, the copy, the exact words to use, the build order, and the other person learns to wait for you even on calls they could make alone. You’re not delegating, you’re dictating with extra steps, and every trivial question still routes through you.
Spell out nothing: and the other person can make a call with no way back, a promise to a customer, a number that feeds billing, a schema only one migration touches, without knowing it needed a second look. You find out after it shipped, which is the expensive way to find out anything.

Neither failure is about how much freedom you gave. Both are about never saying which decisions were which.

Bad, and this is a brief everyone here has written at some point: “Build the overdue-invoice reminder the way we discussed. Use the existing notification service, keep it simple, ping me if you’re stuck.”

Nothing in that sentence is wrong, and nothing in it is checkable. “The way we discussed” lives in one person’s head. “Keep it simple” is not a line, it’s a mood. The team either builds exactly what they imagine you meant and asks about everything on the way, which is spoon-feeding with extra steps, or they guess wrong on the one call that couldn’t be undone.

The tell: if the same few questions come back every time you hand something off, “can I use a different queue library,” “does the copy need sign-off,” “is this schema change fine,” the handoff didn’t answer them. Answering them once, in writing, is cheaper than answering them project after project.

The policy: hand over a compass, not a leash#

Name the few decisions with no way back and why, say out loud that everything else is theirs to decide, and the other person stops needing you for either kind.

Three things this rules out:

A rule with no reason attached. “Get sign-off on schema changes” is an instruction. “Nobody changes the invoice schema without a second read, because forty thousand rows already trust its current shape” is a reason someone can apply to a case you never listed. The first gets followed until it’s inconvenient. The second gets followed because the person can see why.
Guardrailing everything to feel safe. A handoff that marks the tech stack, the file structure, and the copy as off-limits teaches the reader to stop reading the guardrails, including the one that actually mattered. Three real lines hold. Thirty don’t.
Leaving “you can just decide this” implicit. This is the line nearly everyone skips, and it’s the one that buys the actual speed. If you only ever state what’s locked, the reader assumes the rest is locked too, and asks anyway.

The test for whether it’s working: a good guardrail stops the bad decision and doesn’t slow the good one down. If it’s also taxing the calls that were always going to be fine, it isn’t protecting anything, it’s a toll, and that’s worth fixing before you add the next one.

The payoff isn’t that you did less work up front. It’s that the other person stops needing you in the room: they have the reasoning, not just the instruction, so they can extend it to the next case on their own.

The two questions#

One test decides whether a decision needs a guardrail: can you see the mistake coming, and could you undo it if you got it wrong?

This is the same test behind the well-known one-way door / two-way door distinction. A two-way door, walk through, don’t like it, walk back, is free: just decide, look first, own it. A one-way door, no walking back once you’re through, is guarded, because if you can’t see the mistake coming you won’t know to fix it, and if you can’t undo it, seeing it late doesn’t help either.

Two things follow from that test, and both cut against the instinct to over-guardrail:

“It would be bad” is not the test. A wrong file name is bad and free, because you’ll see it in the first PR and rename it. A wrong number in a customer’s invoice reminder is bad and guarded, because the customer read it before anyone else did.
Reversibility is the cheapest freedom there is. A change behind a flag, a migration that can be rolled back, a message with a 48-hour cancel window: build the way back and a decision that would’ve needed a guardrail becomes free, without anyone having to ask permission for it going forward. Before adding another guardrail, check whether a way back is cheaper than a gate.

Name the crash, every time#

Every guardrail gets one sentence of why, or it’s decoration, and decoration is the first thing a person in a hurry ignores. Same project as the diagnosis above: a reminder email sent to customers whose payment is overdue.

Bad: “Approval required for the reminder copy.”

Good: “This reminder tells the customer nothing else happens if they pay within 48 hours. Once it’s gone out to forty thousand people, there’s no taking it back, so someone reads it before it sends.”

Bad: “Don’t touch the balance calculation without checking with me.”

Good: “The reminder shows the amount owed straight from the billing system, never a cached number, because a wrong balance in a message about money owed turns into a complaint, not a bug report.”

The good version survives a deadline. The first person under pressure can decide “approval required” didn’t really mean today. Nobody decides that about a number they can see is irreversible.

Say it out loud#

This is the sentence most handoffs never write, and it’s the one that actually gets you out of the loop.

Bad: a brief, a ticket, or a delegated task that lists what’s guarded and stops. The reader now assumes the rest is guarded too, because nothing told them otherwise, and asks about the queue library anyway.

Good: “Everything else is yours: which queue library sends it, whether it’s one job or three, the build order, how the subject line reads before legal sees the final copy.”

Say it even when it feels obvious. A new report or a contractor can’t see your mental model of what’s safe; every decision looks guarded to someone who’s never been told otherwise.

When a free call goes wrong#

Someone makes a call that was theirs to make, looks first, and still gets it wrong. The reflex is to guard that decision for everyone by the afternoon. Resist it.

Ask whether they looked, not whether the decision should have been guarded. If they looked and it still went wrong, the sightline was worse than you assumed, so fix the information (a preview step, an example of the failure case, a second data point in the handoff) rather than the freedom. If they didn’t look, that’s a conversation with the person, and no amount of new process fixes it.

Do this backwards a few times, turn every miss into a new guardrail, and the next thing you hand off is the over-signed street the diagnosis warned about: guardrails on everything, read by no one, and everyone back to asking before every move. That’s the dependency this whole page exists to remove.

Make the lines easy to hold#

Drawing the line is half the job. The other half is making it easy to act on, because a guardrail that lives only in a doc depends on someone remembering it exists, under deadline pressure, months after they read it. That isn’t durable.

How We Ship already does this for code: CI labels a PR the moment it touches a guarded path, so nobody has to hold the five solid lines in their head to catch one. That’s the pattern worth copying wherever else a guardrail lives: turn it into a default, a checklist, or an automated check where you can, so it holds on its own instead of running on memory.

The free side needs the same investment, pointed the other way. A good template, the brief template below, a starter file, a documented default, makes the free decisions fast, not just safe. Standards do this too: the more the team has already agreed on how something free gets decided, a style guide, a component library, a default stack, the less anyone has to think about it case by case, which is what actually frees up the time a guardrail was meant to protect.

This is the lead’s other half of the job, and it doesn’t stop at writing the brief. Equip the people you hand work to with the tools and standards that make the good call the easy call, and the guardrails you did write get to stay short.

Example: a project brief#

The clearest place to put this to work is the brief a lead writes before a team builds something: a PM scoping a Define session, a PE writing the technical half, anyone handing work to a report, an apprentice, or a contractor. It has a product half and a technical half, and each gets its own short guarded list. Everything not on either list is free by default, which is exactly why saying so out loud matters.

	Guarded (ask first)	Free (just decide)
Product	A promise made to the customer in the copy. What’s explicitly out of scope, beyond what Define already locked. Which customers get contacted, when the message references a real balance or date.	Wording, layout, which segment ships first, the order features roll out in.
Technical	The source of truth for a number the customer will see. A migration that can’t be rolled back. Anything already on How We Ship’s five solid lines: domain model, migrations and deletions, auth, payments, API contracts.	Library choice, file structure, which internal service does the work, the build order.

The five lines in How We Ship already cover every project at Systeric; don’t restate them in a brief. What belongs in a brief’s guarded list is what’s specific to this build: the one number, the one promise, the one migration this project introduces that the standing five don’t already catch.

Out of scope is a product guardrail, not a footnote. Define already covers how to write that list with the Define trio in the room. A brief written outside a Define session, for a report, an apprentice, or a contractor, still needs it, in the same shape: what’s not being built, and the one-line reason.

The template. Fifteen minutes to fill, and it’s the whole brief for anything sand or pebble-sized, or the cover sheet on top of a full definition doc for a rock.

Project Brief · [project name] · [lead] · [date]

Outcome: [what changes for the user or the business, one line]

Out of scope: [what this explicitly doesn't include, and why]

Guarded, ask first:
Product: [the promise or decision], because [the crash]
Technical: [the decision], because [the crash]

Free, just decide: [the two or three things people always ask
about anyway]

Filled example:

Project Brief · Overdue invoice reminders · Priya · 21 Jul

Outcome: A customer with an overdue invoice gets a reminder before it
reaches collections, without support fielding "why was I charged"
tickets for a reminder that was wrong.

Out of scope: Payment plans and partial settlements. Reminders assume
the full amount is owed; a customer wanting to split it still goes to
support. Revisit if that becomes a large share of tickets.

Guarded, ask first:
Product: the copy promises no further action if the customer pays
within 48 hours. Once that's sent to 40,000 customers it can't be
unsent, so it gets a read before it goes out.
Technical: the reminder shows the amount owed straight from the
billing system, never a cached number. A wrong balance in a message
about money owed turns into a complaint, not a bug report.

Free, just decide: which queue library sends it, whether it's one
job or three, the order you build the segments in, how the subject
line reads before legal sees the final copy.

Every line in the good version is checkable: a reader who wasn’t in the room can point at the outcome, the two guarded calls, and the reasoning behind each, without asking a follow-up.