An essay

Why stay upfront

The hardest part of an incident isn't fixing it. It's deciding whether to tell anyone before you have to.

A few years ago, the CEO of a company I worked at got a phone call on a Saturday.

One of our customers had a deadline bearing down, and a few of their team had given up their weekend to hit it — in the office on a Saturday, heads down, working overtime. Except the thing they'd come in to use was down. So they waited. And it didn't come back.

What happened next is the part I still think about. They had no status page to check, no update to read, no way to know whether anyone was even aware. So they did the only thing left to them: they escalated — up through their own chain, all the way to their CTO, who then had to go and find the phone number of our CEO, on a Saturday, to tell him his own product was down. Our CEO tracked down an engineer. The engineer had it back up quickly once he knew. But by then it had been down more than three hours — and the only reason anyone on our side knew at all was that the customer told us. Our monitoring had broken, and nobody had noticed. Nobody, that is, except the people whose Saturday it had just cost.

The outage was over in an afternoon; the damage lasted far longer. Customers know things break. What they don't forgive is finding out before you do, and having to claw up two org charts to get anyone to act. That doesn't read as "their software failed." It reads as "I'm not sure these people have a handle on my business" — and by then, you've lost the round.

Silence is the default, and it's nobody's fault

Staying quiet during an incident is rarely a decision; it's the path of least resistance, and that path is built into the tools — because customer communication is the work nobody owns. Engineering owns the fix. Support owns the inbox. But the public update — the one that goes out before a customer asks — sits in the gap between them, and on a small team that gap is usually one tired person deciding, at the worst possible moment, whether they have the energy to update a separate tool too.

And it is a separate tool — one that asks you to write something calm while everything's on fire. So it doesn't happen. Not because the team doesn't care, but because the system makes caring expensive.

I watched this play out in the worst possible room once. The sales team at a company I worked at walked into an annual-renewal meeting with an important client — and got ambushed. The client opened by raising the downtime they'd had the week before. Our own sales team had no idea it had happened. They were hearing about our product's outage from the customer, across the table, with the renewal on the line.

The part that stuck with me is that the information existed. Engineering had done the right things — caught it, fixed it, even written up a proper incident report. It was sitting on a Confluence page. It just never travelled. Nobody had told the commercial side, because telling the commercial side wasn't anyone's job — there was no habit of it, no shared place it would surface, no culture that said when something breaks, everyone who faces a customer should know. The write-up had an owner. The spread of it didn't.

That's the shape of it on a small team: not malice, not nobody caring — just the gaps where what one person knows never reaches the person who needs it, whether that's a customer or the colleague about to sit across from one.

What staying upfront actually means

Staying upfront isn't a tone of voice or a values slide. It's three habits, and none of them require our product — you could start tomorrow with a public page and the discipline to use it. That last part is the hard part. That's the whole point.

Post before anyone asks. The bar for a status update isn't certainty; it's "a customer might notice this." Wait for the full picture and you'll post after they've felt it. The update that matters most is the early, ugly one: we're seeing elevated errors on exports, we're looking into it, more shortly. It costs you nothing to be wrong about the scope later. It costs you a customer to be silent now.

Connect the dots for them. When a customer's open ticket turns out to be a known incident, say so — on the ticket, before they ask. "This is part of the export issue we're tracking here; you'll get an update when it's resolved" turns a frustrated customer into an informed one in a single reply. Most tools make you do that linking by hand, from memory — which is exactly why it rarely happens.

Name what you don't know. This is the one that feels wrong and is right. Admitting uncertainty feels like admitting incompetence; to a customer it reads as the reverse. "We don't yet know the root cause, but here's what we've ruled out and when we'll update again" is the most trust-building thing you can write during an incident — and customers can tell when you're pretending to know more than you do.

It compounds

None of this is charity. Staying upfront is the most valuable habit a small company has, and it pays off in three places you don't expect.

The first is your own inbox. When the incident is already posted, the "is it just me?" tickets never arrive. You spend the incident fixing the incident, not fielding twenty copies of the same question.

The second is renewal. Customers don't churn over incidents — they churn over the feeling that nobody was minding the store. Handled in the open, a major incident is, strange as it sounds, a retention event.

The third shows up before someone's even a customer. More buyers now check your status page before they sign — they want to see how you handle the bad days, not just the demo's good ones. A public history of incidents handled cleanly closes deals a spotless, empty page never will: the transparency is the sales asset.

"Doesn't this just make us look worse?"

The objection I hear most: if we broadcast every incident, won't we look less reliable than the competitor who quietly fixes things and says nothing?

It's a fair worry, and it's backwards. The competitor fixing things quietly isn't getting credit for reliability — they're getting silence, which a customer reads as nobody home the moment something goes wrong. A polished status page that has never shown an incident doesn't signal "we never break." Everybody knows you break. It signals "we don't tell you when we do."

Customers aren't grading you on whether you have incidents. They're grading you on whether they can trust what you tell them. The first time you're upfront about a problem they hadn't noticed yet, they learn that when something does affect them, they'll hear it from you first. Looking perfect is worth surprisingly little. Being believable is worth almost everything.

I've been on the other side of this, too — and it's where I learned what the silence actually costs.

A few years ago I was the customer. A supplier we depended on hit serious performance problems — bad enough that our own users were feeling it, bad enough that I was having to report on it to our board. I didn't need a fix on the spot. I needed a sense that someone was on it, and some idea of when I'd know more. What I got was a blank wall. Week after week of chasing, and nothing real back.

The part I only understood later is that they were working on it — hard, with good people heads-down on the problem the whole time. But I couldn't see any of that. So as far as I was concerned it might as well not have been happening, and every silent week I went back to my board with nothing, looking like I couldn't manage a supplier. One honest line — "we don't have the root cause yet, but here's what we're doing and when we'll update you" — would have changed everything. It would have given me something to say, and it would have kept my trust. The silence is what lost it. Not the outage.

Where this leads

So that's the discipline. None of it is complicated, and all of it is hard — because the tools ask the most of you at the moment you have the least to give.

That gap is the reason I'm building StayUpfront: to make staying upfront the easy thing instead of the hard one — so the status page is just a view of the incident you're already handling, and being upfront stops being one more thing to remember and becomes what happens by default. I won't pitch it to you here. If the argument landed, you already know what I'm building, and why.

However you do it — separate tools, a shared discipline, or something you've rigged together yourself — staying upfront with your customers is the best habit you've got. I'd genuinely love to hear how you handle it.

— Rob

StayUpfront is in private beta. I'm letting people in a few at a time, so I can work properly with each of them — the earliest customers shape what gets built next.