The Rule of No Surprises

7 min read

TL;DR:Summary: If something would surprise someone when they find out later, tell them now, not once it’s convenient or fixed. Lead with the headline, say what you need, and name the rule. If you manage people, thank them for early warnings, or you’ll get watermelon status updates: green on the outside, red on the inside. Do it consistently and people stop checking your work.

Early on at GitHub, I shipped a tiny diff that broke some of the millions of sites on GitHub Pages.1 For those users, it was a big change, and some of them took their complaints straight to my leadership.

Soon after, I got a not-so-great message about how I’d handled the rollout. Not the breakage. Things break. The problem was that leadership heard about it from upset users first, with nothing in hand to explain or defend the call. I’d written a good technical rationale in the wrong place, for the wrong audience, at the wrong time.

I owned the surprise and explained the decision, in writing and in public. The change stuck. Rebuilding the trust took longer than building the feature had.

Surprises break trust faster than setbacks. Bad news is survivable. Hearing it from someone else first is what does the damage.2

When you’re unsure whether to share something, apply one test: if it would surprise them later, share it now. Don’t wait until it’s convenient, or until you’ve fixed it.

That list includes work that’s going fine. I was once responsible for a new product at GitHub, and everything was on track. Leadership just wasn’t as in the loop as I thought. When they learned the specifics, including how it would affect a subset of customers, the reaction was defensive, and the product was dead within a week. On track isn’t the same as in the loop.3

But what about… Won’t all these heads-ups bury my manager, and make me look like I can’t handle my work?

Not if you use the right test: “would this surprise them,” not “could this go wrong.” A risk you’ve already flagged, or one they’d shrug at, doesn’t qualify, so you’re forwarding the few that matter. And surprises are what make you look like you can’t handle it, because either you didn’t see the problem coming or you saw it and sat on it. Call a risk a risk, not a certainty, and you’ll read as thoughtful, not alarmist.

Don’t treat the rule as permission to dump problems on people. How you say it matters:

💡 Name the rule When you’re telling someone earlier than they’d normally expect to hear it, say so: “Under the rule of no surprises, I wanted you to be the first to hear from me…” It tells them you’re early on purpose, not because something’s on fire. Use it consistently and the phrase itself becomes the signal.

It works at any scale, too. I once sent: “Under the rule of no surprises, I wanted to let you know that I just expensed two Furbies.” Nobody wants to discover that line item on their own.

Put together, it’s a message you can send in under a minute:

Under the rule of no surprises: the billing migration is likely to slip about a week. The vendor changed their integration under us, and we’re still sizing the fix. No action needed yet. I’ll know more Thursday and will flag right away if it gets worse.

When someone brings you bad news early, how you react sets the price of every warning after it. Thank them first, then ask what they need. If early warnings get met with visible frustration, even unintentionally, people stop sending them, and the surprises that replace them are bigger and costlier. A heads-up is the andon cord of knowledge work.4

Punish yellow (the “at risk” status), and you’ll get watermelon status updates: green on the outside, red on the inside.

I’ve been on the receiving end of one. Someone on my team was green for weeks, across every one of their projects. Then the quarter closed, it was time to share results, and I learned the scope had been quietly whittled away the whole time. Deliverables dropped one at a time, never flagged, each project technically “on track” to deliver a little less, until there was little to show for the quarter. No single update was a lie.

Watermelons are usually a rational response to an environment where “at risk” hurts more than silence. If every status you see is green, don’t congratulate yourself. Ask what it would cost someone to tell you otherwise, and what’s been cut to keep it green.

Surprises come in tiers. Not everyone needs to hear at the same time, but the order matters. A team shouldn’t find out they’re being reorged at the same moment as the rest of the company, in a town hall. The people most directly affected by a decision should be among the first to learn it. Give them time to process it and ask questions before they have to react in front of everyone else. Then their partners and the teams who depend on them. Then the broad announcement.

The same rule applies to an audience of one. If a promotion isn’t happening this cycle, tell them long before the cycle closes.5

The hard part isn’t knowing what to share. It’s beating the instinct to wait: until you’ve fixed it, until you’re sure, until you can control the story. We just don’t want to look bad. But waiting is exactly what makes you look bad.

Make it routine with a standing section at the bottom of your weekly update:

If the list is empty, say so. “Nothing new to watch” is information too.

Keep it up, and people stop checking your work, because they trust you’ll tell them if something’s wrong. No surprises is how you earn autonomy.

One quick message to my leadership before that Markdown change shipped would have taken minutes. Skipping it cost me trust, and bought extra scrutiny on everything I shipped after. Send the message.

We were standardizing GitHub Pages on a single Markdown engine, which meant swapping out the renderer underneath every site on the platform. A non-trivial number of sites stopped rendering the way their owners expected. ↩︎

And the damage spreads. If you work loudly, people assume your updates are the full picture. A surprise exposes a gap, and suddenly the bad news isn’t the only thing on the table. They’re rereading every update you’ve ever sent and wondering what else wasn’t in it. ↩︎

If your manager could hear about it in someone else’s meeting, they should hear about it from you first. That holds even when the work comes from above. If a skip-level pulls you into something urgent, a request from above isn’t a substitute for an update to your manager. ↩︎

On a Toyota assembly line, any worker who spots a problem can pull the andon cord to stop the line. Stopping early is cheap. Shipping the defect isn’t. ↩︎

I extend this to team meetings, too. No surprise announcements unless it’s unavoidable. Same for reviews. If someone hears surprise feedback in their review, it’s way too late. ↩︎

The collaborative software development playbook for remote and distributed teams. Drawing on over a decade at GitHub. On Kindle, Apple Books, Kobo & more.

AI-augmented program management is the natural evolution of async-first and engineering-inspired workflows — amplifying human judgment, not replacing it.

In an office, some of your visibility is free. Go remote and it drops to zero. Working loudly makes your impact visible as you do it, not after the fact in a status update nobody reads.

Tips I share with every new GitHubber — from shipping something in your first two weeks to pushing through the inevitable overwhelm.

What does a product manager actually do all day? After six months of note-taking, here are 12 responsibilities from user advocacy to strategic thinking.

I'm Ben Balter, and I write here about developer platforms, product and engineering leadership, open source, and showing your work. I spent a decade building developer platforms at GitHub: five years as a product manager for trust and safety, shipping 500+ features and the API endpoints behind them to 50M+ developers, plus a bottom-up rewrite of GitHub Pages and the open source library behind GitHub's license detection. My open source projects have hundreds of millions of downloads. I wrote Open and Async, the playbook for remote and distributed teams, and shipped an MCP server alongside it so agents can query it directly. At GitHub I was also Director of Hubber (Employee) Enablement, owning the internal platform 4,000+ GitHubbers use to get their work done, Chief of Staff for Security, and the company's first Government Evangelist. Before GitHub: attorney, Presidential Innovation Fellow, and member of the White House's first agile development team. More about the author →

Originally published October 29, 2026 · View revision history