I started writing this on a flight somewhere over the Carolinas, heading home from a week at Disney World with my family. My laptop is open, and I've been staring at a blinking cursor for the better part of half an hour. I want to write…but writer's block. The real kind, not the kind where you have too many ideas and can't pick one. The kind where your brain has been in vacation mode for seven days and refuses to shift back into anything resembling professional thought.
A week at Disney will do that to you. Your internal clock resets to a rhythm of FastPass windows and show times. Your decision-making framework narrows to "which park are we hitting tomorrow" and "is it worth waiting 90 minutes for this ride." Your threat model becomes sunburn and overpriced turkey legs. The most consequential decision I made all week was whether to do Flight of Passage twice or go back for another round on the Safari. (Flight of Passage won. No regrets.) It's wonderful. It's also terrible preparation for sitting down to write something coherent about information security leadership.
I love that week, I need that week. But the reentry is rough. You go from a place where the biggest risk is your kid spending too much on souvenirs to a plane seat where your brain is supposed to produce something worth reading by people who deal with real risk every day. The transition doesn't happen gracefully.
So I did what any reasonable person does when they can't write. I stopped trying and started streaming TV. Specifically, I started catching up on Star Trek: Strange New Worlds, which I'd fallen behind on during the trip. During the "previously on" recap, they called back to a Season 3 episode called "The Sehlat Who Ate Its Tail," and it made me pause and find the full episode for context. Somewhere around the forty-minute mark, Captain Pike said something to a young James T. Kirk that made me close the episode and reopen this document.
The setup: Kirk has been thrust into command of a damaged ship. He makes a bold call that backfires. People get hurt. He spirals, questions himself, temporarily walks away from the chair. Eventually, with help from Spock, he pulls himself together and leads the crew through it. At the end, Pike tells Kirk that the choices he has to make in that chair are his to make, and what comes after is his to live with. That some decisions will follow him for the rest of his life, but he still has to make them.
I sat there in seat 2A with my tray table down and my son asleep next to me and thought: that's the article.
Not because it's a particularly novel insight. Leaders make hard calls, that's not news. But because of how rarely we talk about it honestly in our industry. We talk about frameworks and methodologies and risk matrices and decision trees. We talk about "data-driven decision-making" as though every hard call comes with a spreadsheet that tells you what to do. We talk about leadership in the abstract, as a set of competencies to be developed, a maturity model to be climbed. What we don't talk about enough is what it actually feels like to make a call you're not sure about, live with the consequences, and then get up the next morning and do it again.
I've been in information security and information technology for over twenty years. In that time, I've made a lot of decisions. Some of them were good and some of them were bad (a few were bad in ways I didn't fully understand until much later). The good ones, honestly, I barely remember. They just became part of the background, absorbed into the normal rhythm of things working the way they're supposed to. The bad ones I remember in detail. The meeting where I made the call. The moment I realized it was wrong. The conversation I had to have afterward. Those memories don't fade the way the good ones do. For me, they sharpen.
I think every security leader has a version of this. A decision that seemed right at the time, made with the information available, under the pressure that existed, that turned out to be wrong. The exact decision itself doesn't matter as much, but for reference: maybe you delayed a patch because the business couldn't afford the downtime, and the vulnerability got exploited. Maybe you approved a vendor that turned out to have security practices that didn't match their sales pitch. Maybe you pushed back on the control the auditors wanted, and the finding showed up in a way that made leadership question your judgment. Maybe you staffed for the wrong risk, or prioritized the wrong project, or trusted the wrong assessment. All of these are decisions that may have seemed right at the time but turned out wrong.
The specifics vary between every leader. The feeling doesn't. It's the moment when you realize that the outcome is yours, that nobody else made this call, and that knowing you did your best with what you had doesn't actually make the pit in your stomach go away.
Pike's line lands because it acknowledges something that leadership literature usually glosses over: regret is part of the job. Not the failure part exactly, though sometimes it's that too. It's the regret. The specific, personal, 3am-staring-at-the-ceiling knowledge that you chose wrong, and people were affected by it. No framework prepares you for that. No certification prepares you for that. The only thing that prepares you for that is having done it before and survived.
I want to be careful here, because there's a version of this article that turns into toxic leadership mythology. I don't want this to come across as the "lonely at the top" narrative where the leader is a solitary figure bearing impossible burdens with stoic grace while music swells around them. That's not what I'm describing, and it's not what Pike is describing either. What I think he's telling Kirk is something more honest and less romantic: this is the job. You will make calls. Some will be wrong. You will live with them, but you still have to make them. It's not heroic. It's just the reality of being the person in the chair.
In information security, the chair comes with some specific flavors of difficulty worth naming, because they're different from the leadership challenges in most other disciplines.
First, we make decisions with incomplete information almost every time. By the time you have complete information about a threat, the window to act on it has usually closed. The patch decision, the incident response call, the "do we shut this system down or keep it running" question during an active event. Those decisions get made in fog. You're working with partial telemetry, conflicting reports, vendor advisories that may or may not apply to your specific environment, and a clock that doesn't stop while you figure it out. The people who have never been in that position assume there's a clear right answer and you either found it or didn't. The people who have been there know that sometimes there are only wrong answers and you're just trying to pick the least wrong one.
I remember early in my career thinking that seniority would fix this. That the more experienced I got, the clearer the right call would become. That wasn't my experience. The calls don't get clearer. You just get more practiced at moving forward without waiting for certainty that's never going to arrive.
Second, the consequences of our decisions are often invisible until they aren't. A good security decision looks like nothing happened. You patched the vulnerability, the exploit never landed, and nobody noticed because the absence of an incident is not a story anyone tells. A bad security decision can also look like nothing happened. Until the day it doesn't, and then suddenly everyone wants to know why you made the call you made six months ago, as though the decision should have been obvious at the time. The asymmetry is brutal: success is invisible, failure is front-page.
Third, we operate in an environment where second-guessing comes from every direction. Business thinks we're too cautious. Auditors think we're not cautious enough. Some boards want assurance that we're fully protected, while the operations team wants assurance that we won't break anything. Every one of those audiences has a different definition of "the right call," and you can't satisfy all of them simultaneously. Leadership in security is not about making everyone happy. It's about making a defensible decision and being willing to explain it to people who disagree.
I've learned some things about living with hard calls over the years. I want to share them not because I've got it figured out, but because nobody shared them with me when I was coming up, and I wish someone had.
The first thing I learned is that documenting your reasoning matters as much as documenting your decision. When a call goes wrong (and some will), the question you'll face isn't just "what did you decide" but "why did you decide that." If you can point to the information you had, the risks you weighed, the alternatives you considered, and the rationale for the path you chose, you're in a fundamentally different position than if you're reconstructing it from memory six months later. I've been in post-incident reviews where the decision-maker couldn't explain their own reasoning because they'd made the call on instinct and never wrote it down. That's not a character flaw. That's what happens under pressure. Building the habit of even a brief written record (what I knew, what I decided, why I decided it) has saved me more than once.
The second thing I learned is that speed and certainty are not the same thing, and confusing them is dangerous. There's pressure in security leadership to be decisive, to make the call quickly and move. I've felt that pressure. Sometimes speed is genuinely necessary: an active incident, a critical vulnerability with known exploitation, a time-sensitive business decision waiting on your input. Most decisions are not actually as time-sensitive as they feel in the moment. I've made bad calls because I treated a decision as urgent when it was merely uncomfortable, and I rushed to resolve the discomfort rather than sitting with the uncertainty long enough to think it through. The willingness to say "I need another hour" or "I need to talk to one more person before I commit" is not indecisiveness. It's discipline. Learning the difference between those two things took me longer than I'd like to admit.
The third thing, and this is the one I still struggle with, is that forgiving yourself for a bad call is not the same as excusing it. You can hold yourself accountable for a decision that went wrong and still extend yourself some grace for making it. Those aren't contradictory. They're both necessary. I've watched good leaders destroy themselves over a single bad call, replaying it endlessly, letting it erode their confidence in every subsequent decision. I still relive my own bad calls in my head, years after they were made and years after I've left those organizations. Some people become hesitant, second-guessing themselves on calls that should be straightforward, because the ghost of one bad outcome has colonized their judgment. I've also watched leaders wave away consequences as though accountability is for other people. They never revisit a decision, never adjust, never absorb the lesson because they never admit there was one. Neither path leads anywhere good. You need to own it, learn from it, adjust your approach, and then let it become part of your experience instead of your identity.
The fourth thing is that the best leaders I've worked with are the ones who are honest about uncertainty. Not the ones who project confidence they don't feel. The ones who say, "here's what I think we should do, here's what I'm not sure about, and here's what would change my mind." That kind of transparency isn't weakness. It invites the team to contribute information you might not have. It creates space for someone to say, "actually, I have data that changes this picture." I've been in rooms where the leader had already made up their mind and the meeting was performance, not deliberation. I've also been in rooms where the leader genuinely wanted input, and the collective intelligence of the team produced a better outcome than any individual would have achieved. The people in those rooms know which kind they're in.
This is connected to something Pike models in Strange New Worlds that I think is underrated. His style of command is to ask his crew what they think. "Who's got ideas?" is practically his catchphrase. He doesn't do it because he lacks confidence. He does it because he understands that being the person who makes the final call doesn't mean being the person who has all the answers. The chair gives you authority, but it doesn't give you omniscience. The leaders who confuse those two things are the ones who make the worst decisions, because they've cut themselves off from the very people who could have helped them make better ones.
I've been that person. Early in my career, I thought leadership meant having the answer. I'd walk into meetings with my mind made up and spend the discussion defending my position instead of testing it. It took a few expensive lessons to learn that the smartest thing I could do in most situations was shut up, listen, and let the people closest to the problem tell me what I was missing. That shift didn't come naturally. It came from getting it wrong enough times that stubbornness started losing to basic pattern recognition.
I think about Kirk in that episode, the moment where he walks away from the chair. He makes a call that goes badly, people get hurt, and his response is to question whether he should be making calls at all. It's the most human reaction in the world. I've felt it. Not dramatically, not in a way that anyone would put in a TV episode, but in the quiet way where you close your laptop after a bad day and think "maybe I'm not the right person for this."
The answer, and I think this is what Pike is ultimately telling Kirk, is that doubt itself is part of what makes you the right person. The leader who never questions their own judgment is the one you should be worried about. The one who feels the weight of a bad call, who loses sleep over it, who carries it forward as a lesson rather than a wound… that's the one I want making decisions. Not because suffering makes you wise (it doesn't, automatically), but because the awareness that you can be wrong is the only thing that keeps you honest about your own limitations.
I'm not going to pretend that watching a Star Trek episode on a plane constitutes a profound leadership experience. But the reason Pike's words hit me the way they did is because they describe something I've lived through and never heard articulated quite that cleanly. The choices are yours. The consequences are yours. Some of them you'll regret. Yet you still have to make them.
In information security, we talk a lot about risk. We build entire programs around identifying, measuring, and mitigating organizational risk. What we don't talk about as often is the personal risk of leadership itself. The risk that you'll be wrong. The risk that being wrong will cost something real. The risk that you'll have to look someone in the eye and explain why you made the call you made, and the explanation won't feel like enough. The risk that the decision you're most proud of today becomes the one you most regret tomorrow, because something changed that you couldn't have predicted.
Nobody puts that risk on the heat map. Nobody assigns it a likelihood and impact score. Yet every security leader carries it, and it shapes how they show up every day in ways that no maturity model will ever capture.
I don't have a framework for that, and I don't think one exists. What I have is twenty-plus years of making calls, getting some right, getting some wrong, and showing up the next day to make more. What I have is a slowly growing comfort with the fact that certainty is not a prerequisite for action, and that a decision made thoughtfully and in good faith is not a failure just because it didn't produce the outcome I wanted.
What I have, apparently, is a Star Trek quote I can't stop thinking about and a plane that's starting its descent into Philly.
Turns out I had something to write about after all. Pike was right. The chair doesn't come with a guarantee that you'll get it right. It comes with the responsibility to try, the humility to learn when you don't, and the courage to sit back down tomorrow.
That's the job. For starship captains, for security leaders, and for anyone who's ever had to make a call and live with what comes after.