I spent more than fifteen years in enterprise security. A large part of that time was spent inside incidents: the call at two in the morning, the war room, the executive asking how bad it is before anyone actually knows. When I became the Founder of Setix, I expected to leave that world behind. Instead I found that running an early company is mostly incident response with a longer time horizon.
An incident and a startup share the same basic shape. Something important is at stake. Information is incomplete. The clock is running. People are watching you to decide how worried they should be. The disciplines that work in one work in the other, and I want to describe three of them.
Calm is a decision, not a temperament
The best incident commanders I worked with were not naturally relaxed people. They had simply decided, long before the incident, that panic produces worse decisions than calm does, and they acted on that decision when it counted. Their teams took the cue. A room takes its temperature from the person running it.
Founders set the temperature the same way. When a deal slips, when a hire falls through, when a system breaks the night before a demo, the team is not really watching the problem. They are watching you. If you treat every setback as an emergency, you train your team to burn energy on fear instead of on the fix. I try to ask the same question I asked in war rooms: what do we actually know, what do we need to know next, and who is doing what in the next hour. It is not sophisticated. It works.
Runbooks beat heroics
Security teams learn early that heroes do not scale. The engineer who can fix anything at three in the morning is an asset until the night they are on a plane. So mature teams write runbooks. They turn the hero's knowledge into a procedure anyone competent can follow, and they improve the procedure after every use.
Early companies resist this. Everything feels too fluid to write down, and the founder is usually the hero in question. That is exactly the problem. If the answer to every hard question lives in my head, the company has a single point of failure, and I built a career on removing those. So I write things down before they feel worth writing down: how we evaluate a partner, how we respond when something breaks, how we decide what not to build. The documents are short and often wrong. Wrong and written is better than right and tribal, because a written mistake can be corrected by anyone who spots it.
Blame is expensive
The most important cultural technology in security is the blameless postmortem. After an incident, the team reconstructs what happened without asking who to punish. The reason is practical, not sentimental. If people expect blame, they hide information, and hidden information is what causes the next incident. Every serious postmortem I have ever run found that the person who made the visible mistake was standing at the end of a long chain of conditions someone else created.
A startup generates failures faster than any production system. Features miss. Messages fall flat. Assumptions collapse on contact with a customer. If the response to each failure is to find its owner, people stop surfacing bad news, and a founder who hears only good news is flying blind. So we do the same thing I did after incidents: write down what happened, what we believed at the time, why the belief was reasonable, and what we will change. Then we move on.
The postmortem I have not written yet
There is one more habit from incident response that I hold onto. Every incident ends. In the middle of it, that fact is hard to believe, but the log always gets closed, the report always gets filed, and the team always learns more from the incident than from the quiet months around it.
Building a company feels permanent while you are inside it, the way an incident feels permanent at hour six. It is not. It is a sequence of situations to be understood, decisions to be made calmly, procedures to be improved, and lessons to be recorded without blame. My years in enterprise security did not teach me how to sell or how to raise money. They taught me how to behave when things are uncertain and the stakes are real. So far, that has been the more useful education.