Why Every Tech Founder Needs a Crisis Comms Plan (And Why 9 out of 10 Don't Have One)
Your worst day is the wrong time to decide what to say. Build the plan before you need it.
8 min read
Most founders think about how they'll launch their product, how they'll raise money, and how they'll hire. They don't think about what they'll do when a customer gets physically hurt, their database gets breached, or a senior employee does something indefensible.
In fact, 9/10 founders I talk to don't have even a semblance of a crisis communications plan.
They might work with a PR agency to write a press release and set up interviews around their funding-round announcement, but after the glow fades, they don't think about communications again.
The question of crisis communications hasn't even been asked anywhere near their organization because they don't expect it to be necessary in the first place.
Call it hubris.
I’d definitely call it a vulnerability.
"It would never happen"
I was talking to a founder of an in-home care company, and I asked what they would do if a carer they employed attacked a client. The founder said she didn't think it would ever happen, that she trusted her staff, and that there’s no world, no universe, in which they’d betray anyone’s trust.
I couldn’t find a way to make her see the cold, hard fact of human nature at play: if you have employees going into the homes of vulnerable people, you have to think that one of them is going to abuse one of those people at some point.
The founder knew this, deep down - I’m sure.
They just didn't want to think about it.
And I get it. The nature of founders and entrepreneurship is that you have to believe in your company more than is rational, or you'd never start one in the first place; which makes it almost an identity crisis for founders to imagine their companies in their worst possible state.
They don't write crisis communications plans because they see it as an insult to their business and who they are.
The Delay
When a crisis happens, founders without a crisis communications plan almost always delay. They'll say they're gathering facts, getting legal advice, or trying to pick the best time to say it.
I think most of the time they're scared.
They can pretend that the problem is minor if they haven't put it out there. The Nvidia board is the most recent example. In May, a short seller, Culper Research, released a report questioning Nvidia's revenue from China and the CEO's relationship with a business partner.
I don’t need to get into the sordid details of ~that affair here.
But over the next six months, the directors did not speak publicly. In November, they launched an investigation in the same week the story became national news. By then, analysts had downgraded the stock, and the press was reporting on who the next CEO would be.
I don't know what the directors knew and when. But they knew that this was being reported on in the public domain in May; they didn't speak in November, and every reporter has pointed out the six-month delay.
No matter what you think the problem is, it's only a matter of time before people find out. Your employees will talk, your customers will post screenshots, the short sellers will report on it, the journalists will call. If you wait until the news comes out, you've already lost the race to tell your story.
You Already Know The Answers
Railway hosts applications for a huge number of developers. On October 21, Railway told customers there was a chance a third party may have gained access to their saved credentials. During the investigation, Railway halted its deployment pipeline so customers couldn't deploy.
During the outage, customers asked Railway what they'd do to make it right. One customer wrote on Trustpilot that the customer support team acknowledged that it was Railway's fault, said that customers on the Pro plan didn't get any credits, and refused to offer a $20 goodwill credit. The customer wrote a review about it, and other customers replied in a similar manner. I'm sure that there are good reasons for Railway's decision.
But the question every customer asks during any outage is, "What are you going to do to make it right?" If a senior decision-maker isn't determining the answer to that question and putting it in writing for the support team to communicate, then you're going to end up with a support person making an isolated judgment call based on your terms of service, a customer posting it, and you spending the next week responding to new screenshots on a daily basis.
There are six questions that every customer asks after any incident:
- What happened?
- Did my data or money get affected?
- What do I need to do right now?
- What are you doing to fix this?
- What are you going to do to make it right?
- What are you going to do to prevent this happening again?
You can probably draft most of the answers to these questions already, and you can determine policy, tone, and approvals well in advance. All you need to do on the day is fill in the specific details.
Nobody Inside Is Good At This
The problem is that nobody inside the company is good at this. Most of the PR people I've spoken with have been trained in marketing and are good at communications around announcements. They haven't sat with the engineers to work through a breach, and they don't know what an environment variable is or why it's important not to let one leak.
The journalists who work in PR are often suspicious of tech companies, and they don't use the technology themselves. So I don't think either of those groups are going to improve.
It's not that the engineers inside the company are good at it either. Engineers rate each other by who's building new features. Those guys are highly valued.
The security team is often brought in to talk to the board because that's a cool topic for board members and makes it seem like they're taking cybersecurity seriously. The ops team is highly valued, but not as much as they used to be because founders and investors don't see ops as exciting.
And finally, comms is at the bottom of the food chain. Engineers think that comms is cleaning up after everyone else.
The person who has to represent the company at their worst moment is often the least qualified to draft a pre-established plan for the situation. The engineers who understand the problem don't want to convey it to them, the founder doesn't want to know, and the comms person who drafted the press release for the product launch is just waiting around.
AI is about to make it worse
The so-called non-engineer software developers are now using AI to write code and deploy things on hosting platforms like Vercel and Railway without much regard to the system's architecture or scalability. More companies are relying on fewer vendors. It's gotten to the point where when one of those vendors has a staff member cause an outage or miss a security breach, far more people are affected than five years ago. Engineers also know that AI makes it possible to outsource things that used to be engineer-only tasks. Many of them are pushing back more aggressively against their jobs being usurped. That makes them less likely to listen when the comms person offers ideas when they need them most.
Expect incidents to get worse, bigger, and more public. Founders who build on these services will have to explain and own downtime that they didn't cause or control. They, too, need a pre-established plan for this.
What you can do this week
1. Write down your top 5 worst-case scenarios for your company. Include the one you think is impossible. If you're a marketplace, write down the attack. If you're storing user data, write down the breach. If your company's made you indispensable, write down your personal scandal.
2. Draft an initial response to each of these, in three sentences. What do you know? What are you doing about it? When will you update? Aim for a one-hour turnaround from the moment the problem is confirmed. You can always update with a quick initial response. You can't ever undo a week of silence.
3. Answer the "what will you do for me?" question upfront. What are your credits or refund policies, who can make exceptions, and to what degree? Draft the exact scripts your support will use. If the answer is "nothing", write a sentence your support staff can use without provoking more anger.
4. Specify one person to speak and one person to approve. Include phone numbers at the top of the document. Designate alternates for each, because things break on holidays.
5. Test your comms person. Can they explain your last downtime incident to you in a conversational way? If not, teach them or find someone new. They'll be asked to do the same in front of journalists with a much tighter deadline.
6. Do a tabletop exercise twice a year. Create a private Slack channel and announce a made-up incident. Give your team an hour to work through it. See who panics, who begins to bicker, and which of the six questions goes unanswered. Update your plan accordingly.
Your initial plan is going to be wrong somewhere. Do a tabletop exercise and fix the issues. Writing a better draft on a lazy afternoon will be easier than typing at 2 am with customers screaming in your ears.
