The CTO’s Crisis Cadence
A crisis is a bandwidth problem. Your engineers have too little and your CEO has too much. Your job is not to fix the system. Your job is to manage the flow between those two.
I’m standing at my kitchen counter at 6 a.m., refreshing our signups dashboard with toothpaste still in my mouth. The number keeps climbing. We launched an AI product six weeks ago and people love it. Dana, our CEO, three weeks into the job, has been forwarding me screenshots of prospects begging for access. Sales is closing deals faster than we can spell “onboarding.” I feel like a rockstar.
Then I notice the green line on the dashboard has gone flat.
Not climbing. Not dipping. Flat. The way a heart monitor goes flat.
A third-party model provider we depend on has changed something upstream, and our inference pipeline is timing out. New customers can’t onboard. Existing ones are staring at spinners. The Slack channel I muted last night has 200 unread messages, and the top one is from Dana: “Are we down?? Customers are emailing me directly. Jumping on a call in 10. Bring the engineers.”
I should have known better than to bring the engineers.
By the time I join, Dana has already pulled Sofia, my strongest backend engineer and the one person who can actually trace the broken dependency, into a live call to explain, in real time, to a non-technical founder, why the system she didn’t break is broken. Sofia is screen-sharing logs. Dana is asking why we didn’t catch this. My other two engineers are typing answers into chat instead of into the codebase.
I watch this for ninety seconds. I have coached hundreds of CTOs on staying calm in exactly this moment. And I open my mouth and I lose it.
“This call is the problem,” I say. Too sharp. “Every minute Sofia spends explaining the outage is a minute she’s not fixing it.”
Dana’s face does something I’ll think about for weeks. She doesn’t get angry. She slips sideways. Her eyes go somewhere else. She’s three weeks in, customers are in her inbox, her CTO just snapped at her in front of the team, and she has no idea whether this company is on fire or whether her CTO is.
One vowel-shaped gap
Later that day I try to repair it. I tell Dana that the two of us need to put real effort into our own relationship before anything else. That when she has a question about engineering, she should bring it to me and not go around me to the team. That a crisis will test us, and we should invest now, while we still can. She nods. The call ends.
An hour later she messages a board advisor that her new CTO thinks there’s going to be “necessary friction” between them.
Effort. Friction. One vowel-shaped gap between what I said and what she carried away.
I told myself we’d cleared it up. We hadn’t.
The text she didn’t send to me
The next morning, one of my newest developers pings me. He’s been with us one week. He forwards a text he just got from Dana, asking how things were going and whether the infrastructure was stable yet. A question that belonged to me, sent around me, to a new guy who’d been on the team for days if not hours.
The part I still can’t get over is this. He came to me before he answered her.
He didn’t have to. He barely knew me. He could have replied to the CEO and moved on. Instead he paused and told me what was happening. Whatever I’d done to bring him into the team, I had at least earned that.
It did not stop me from being livid.
That morning was the closest I came to walking away from the whole thing. The broken dependency. The oversold customers. The founder going around me the day after I asked her not to. I could feel the exit in my chest.
But I knew what walking out would cost me. Relief, and then nothing learned. The same lesson waiting for me at the next company, wearing a different face.
So I did the unglamorous thing. I coached the developers on how to respond, warmly and briefly, and to route the real questions back to me. Then I invited Dana to call me so we could walk through the day’s updates together.
When the conversation reached her text, I asked her plainly why she’d reached out to him. She told me. Her reasons were human and they were fair. She was scared, she wanted ground truth, and I hadn’t been giving her enough of it to feel the floor under her feet.
And then we had the best conversation we’d had since she joined. She asked me for a plan. She asked for visibility. She asked for a real read on customer health. We went deep into the platform struggles, the dependencies we don’t own, the part-time resources stretched too thin, the product sprinting to catch up with what sales had already sold. No translation games. No keeping score.
The outage was never the emergency
That call taught me what the snapped-at engineer and the effort-and-friction slip had been trying to teach me all week.
I was filtering. Out of some instinct to protect Dana, and probably to protect myself, I had been rationing what I sent her. A clean headline here, a reassuring line there. I thought I was sparing her the noise. What I was actually doing was leaving a vacuum, and a frightened founder will always fill a vacuum. If the information doesn’t come from you, it comes from your team, your board, or her own worst imagination.
She wasn’t going behind my back to betray me. She was starving, and I was the one holding the food.
Sofia fixed the dependency in four hours once we left her alone. The outage was the easy part. The emergency was that a determined new CEO and a veteran CTO were standing two feet apart and could not hear each other, in the exact week we most needed to.
I wrote about this in The CTO’s Silent Struggle. Being technically correct is cheap. I was technically correct on that first call. And being right bought me nothing, because I delivered it in a way that made the most anxious person in the company more anxious.
A crisis is a bandwidth problem. Your engineers have too little and your CEO has too much. Your job is not to fix the system. Your job is to manage the flow between those two, and to be the most generous source your CEO has, so she never needs to go find another one.
Why the flat line is coming for all of us
The AI products we are all rushing to ship sit on top of dependencies we do not control. Model providers, vector stores, orchestration layers, rate limits that change without warning. The surface area for a 6 a.m. flat line has never been larger. I argued in The CTO’s Incoming Storms that the storms are coming for how we communicate under pressure, not only for our architecture. This is that storm, arrived in my kitchen.
When the flat line shows up, three things happen at once, and they compound. A key dependency breaks. The people who can fix it get pulled into explaining it. And a CEO with no technical vocabulary fills the silence with the worst story she can imagine. Daniel Kahneman called it WYSIATI, what you see is all there is. Dana could see angry customers and a frozen dashboard. That was her entire universe. She wasn’t being irrational. She was being human with incomplete information, which is the only kind of human there is during an outage.
The instinct in that moment is to throw bodies at the fire. Pull in the contractor, get everyone on the call, loop in the world. Fred Brooks warned us about this back in 1975. Adding people to a late project makes it later, because every new person has to be brought up to speed, and that speed is paid for out of the time of the people who already have it. A crisis call with eight people on it is not a war room. It is eight people watching one person work, and that one person is now performing instead of fixing.
Who fixes, who talks
The teams that handle this well learned it from people whose outages can cost lives or millions. When Google wrote down how it runs incidents in its Site Reliability Engineering book, the first move was to split the work into roles. One person commands the incident. One person fixes it. And one person does nothing but communicate outward, so the fixer never has to. That communications role exists precisely so that no engineer is ever forced to choose between resolving the system and calming the executive.
I had collapsed all three roles into one chaotic call, and then gotten angry that it wasn’t working.
So let me give you the cadence I wish I’d had ready.
Decide who fixes, and protect them like the asset they are.
The moment you identify the person who can resolve the issue, they leave the call. They do not narrate. They do not reassure. They fix. You stand between them and everyone who wants an update, and you absorb every interruption so they never feel one.
Give your CEO a rhythm, not a lecture.
Dana did not need to understand inference timeouts. She needed to know a competent adult had her back and would tell her something true at a predictable interval. “I’ll send you one line every thirty minutes until this is resolved, even when the line is ‘still working, no change.’” The predictability is the medicine. A scheduled “no change” lowers anxiety more than an unscheduled explanation ever will. Remember the fifteen-minute blocks from The CTO’s Perfect Week? Same muscle. A small, reliable beat a frightened person can set their nervous system to.
Over-communicate, and open the door before she looks for a side one.
Under stress, message fidelity falls apart. People hear the scary version of whatever you say, so write the important things down and confirm them back. And invite your CEO in, all the way in, because the alternative is the back channel I earned the hard way. A crisis update needs three things to work. Detail. Frequency. Invitation.
Apologize fast and apologize specifically when you show up badly.
I had to go back to Dana and say the real thing. Not “sorry if that came across wrong.” That I was scared too, that I let it leak out as anger, and that she deserved a CTO who was steady on a morning she couldn’t be. The apology wasn’t weakness. It was the first deposit in the relationship I’d been too proud to invest in before I needed it.
Three names and one sentence
So what do you do with this today, before your dashboard goes flat?
You don’t need a giant incident-response process. You need three names and one sentence.
Write down who your fixer is for your most fragile system. Write down who communicates outward when it fails. They should not be the same person. If your team is small enough that they have to be, the rule gets simpler, not harder: the fixer fixes, you communicate, and you do not interrupt them for status more often than your own cadence allows.
Then write the one sentence your CEO can forward to a customer without you in the room. “We’ve identified an issue affecting onboarding, our team is on it, and we’ll update you by [time].” If your CEO holds that sentence, she stops texting your developers and starts protecting you.
What happens next surprised me. The fire does not go out any faster. Sofia’s four hours were going to be four hours no matter what I did. But the panic goes out almost immediately. And panic, not the outage, is what burns the trust between a CTO and a new CEO to the ground. Buy your fixers four quiet hours and you become the steadiest person in the company. Fill those four hours with a frantic all-hands and you become the problem.
You will also feel less alone, which is the part nobody warns you about. A crisis handled with a cadence stops being a thing happening to you and becomes a thing you are running. That move, from passenger to conductor, is most of the relief.
You are one person. You cannot make your model provider stable, or your CEO calm, or your dependencies bulletproof. What you can do is be the one steady beat in the room when everyone else’s tempo falls apart. Do it once and the team remembers. Do it twice and they keep the cadence without you. A new developer starts forwarding you the text he could have answered himself. That is how a single CTO turns a culture of panic into a culture that holds.
Your dashboard is going to go flat one of these mornings. The only question that matters is whether the people around you will hear a steady voice or a scared one.
Which one have you been practicing?
Etienne
p.s. reach out to me at my coaching company (EXE) if you want to set up some coaching around this subject.