The rule of no surprises

A new post from ben.balter.com · Read it on the web →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 The rule When you’re unsure whether to share something, apply one test: if it would surprise them later, share it now.…