A coworker called me a thought leader a few weeks ago… right to my face… in the middle of the office, in front of other people. I didn't know what to do with it, so I laughed it off and changed the subject, which is what I do anytime someone says something nice about me that I don't know how to process. Then, a few days later, somebody else referenced my blog and said something about how I was building a brand as an information security influencer — in their defense they meant it as a compliment… me being me took it like an accusation.
I need to clear something up, because if anyone is reading what I write and thinking "this guy has it figured out," I want to correct that misunderstanding before it hardens into something neither of us can fix. I am not a thought leader. I don't have a methodology or a manifesto. I don't have some grand unified theory of information security that I'm unveiling one blog post at a time. There is no course on my website selling dark leadership secrets that will jettison you to the top. What I do have is twenty-plus years of being in rooms where things went wrong, a reasonable memory for the details of how they went wrong, and a laptop with Microsoft Word (sorry, Linux fans). That's my whole operation.
There is no brand strategy behind this. There's no editorial calendar mapped to engagement metrics. There's no content funnel designed to convert readers into followers into subscribers into customers of whatever it is that thought leaders sell. There's just me, trying to write down what I've learned from doing this job for a long time, in the hope that somebody earlier in their career reads it and thinks "okay, I won't do that."
That's it. That's my entire mission statement around this blog… learn from my mistakes.
I started writing because I like writing — it's that simple. Before there was a podcast, before there was a blog, there were just random posts in forums, before anyone was calling me anything. I just liked putting words together about things I cared about. Information security happens to be the thing I care about not just professionally but personally, so that's what I write about. If I'd spent twenty years as a plumber, I'd probably be writing about the time I flooded a basement and what I learned from it. The words would be different. I think the instinct would be the same.
There's also something writing does for me that I didn't expect when I started. It forces me to be precise about what I actually think. When a half-formed opinion is floating around in my head, it can feel solid, coherent, defensible. Then I try to write it down and realize it's got holes in it I never noticed. The act of translating a thought into sentences exposes the gaps. I can't tell you how many times I've started drafting an article with a clear thesis and ended up in a completely different place because the writing process showed me that my original thoughts didn't hold up.
But the thing that turned a hobby into something I actually cared about sharing was a realization I had a few years ago that keeps getting reinforced every time I sit down to write: I have been part of, or directly witnessed, a remarkable number of suboptimal decisions during my career. Not catastrophic ones, necessarily (though a few qualify). Just decisions that seemed reasonable at the time and turned out to be wrong in ways that were preventable, if someone had asked a different question or challenged a comfortable assumption or simply known what the last person in that same situation learned the hard way.
That's the gap I'm trying to fill. Not with wisdom… with scar tissue.
When I wrote about the Iran-linked attacks on water systems in Minnesota, I wasn't writing because I'm an OT security expert. I'm not — I said so in the piece. I wrote it because the pattern I saw there, a nation-state actor exploiting embarrassingly basic vulnerabilities in systems that nobody had invested time or money to secure properly, was the same pattern I've seen play out in enterprise IT environments my entire career. The technology changes. The controls change. The failure doesn't. We keep skipping the basics because the basics are boring and unfunded and nobody gets promoted for changing a default password. I'm not immune. I've been guilty of that lack of vision. I've prioritized the interesting project over the fundamental one. I've let basic hygiene slide because there was always something more urgent, more visible, more exciting to work on. The water plants in Braham, Minnesota are not my world, but the mistake is one I recognize because I've made a version of it myself.
When I wrote about OWAReaper and the death of the "don't click" era, I wasn't writing because I had some exclusive insight into Russian tradecraft. I was writing because I sat in a meeting once — okay, more than once — and told leadership that our security awareness training was a meaningful control against email-based compromise. I believed it at the time. I had metrics to back it up. Phishing click rates were down. Reporting rates were up. The program looked like it was working. OWAReaper didn't exist yet, but the class of attack it represents was always a possibility, and I didn't spend enough time thinking about what our strategy looked like if the user stopped being the control point. I built a defense around user behavior and didn't invest enough in the infrastructure behind it. That article wasn't me pointing fingers at anyone. It was me pointing fingers at the mirror and hoping other people recognized the reflection.
When I wrote about AI adoption and the organizations racing to implement something they haven't thought through, I was writing from direct experience of watching technology get deployed because someone important was excited about it, not because someone rigorous had validated the need for it. I've been in those rooms. I've been part of those decisions. I've approved security tool purchases that solved a problem I was worried about rather than a problem I could prove existed. Fear-driven spending versus need-driven spending. I know the difference now. I didn't always.
When I wrote about Pike's speech to Kirk and what it means to sit in the chair and live with the calls you make, I was writing from a plane seat after a week at Disney World because a fictional starship captain articulated something I've felt for years and never said out loud: that some of the decisions I've made in my career were wrong, and that being wrong didn't kill me, and that the willingness to make the next call knowing that I might be wrong again is not courage or leadership or any of the other words we use to make it sound heroic… it's just the job. It's just what happens when you're the person who has to decide and you decide to stay in the chair.
Every piece I write starts in the same mental place. Not "what does the industry need to hear" (the thought leader question) but "what did I get wrong, what did I see go wrong, and what would I tell someone who's about to make the same mistake" (the honest question). Those are very different starting points, and they produce very different writing. The thought leader version is polished, authoritative, and positioned for maximum credibility. The honest version is messy, self-implicating, and frequently uncomfortable to write because it requires admitting things that don't look great on a resume.
I've read a lot of thought leadership content in this industry. Most of it follows the same template: here's a problem, here's why it's important, here's a framework for solving it, here are five steps, here's a call to action. The author is positioned as the expert who identified the problem and is now generously sharing the solution. It's a clean professional piece. It's also, in my experience, mostly useless to the person in the middle of the actual problem, because the actual problem never looks like the template. The actual problem involves a budget constraint the framework didn't account for, or a political dynamic the five steps don't address, or a legacy system that won't cooperate with the elegant architecture in the diagram. The actual problem is messy, and messy problems require messy honesty, not polished frameworks.
I'd rather write the messy version. I'd rather say "I was in this situation and here's what I did wrong" than "here are ten best practices for handling this situation." Best practices are fine, and they exist for a reason, but they don't teach you what it feels like to be the person making the call when none of the best practices quite fit what you're dealing with. Experience teaches you that. Other people's honest accounts of their experience can teach you that too, if they're willing to be honest. That's the bet I'm making with every piece I write: that honesty is more useful than authority.
The "influencer" comment bothers me more than the "thought leader" one, and I've been thinking about why. I think it's because "influencer" implies that the goal of writing is to affect other people's perception of me. That the blog exists to build a personal brand. That the whole thing is ultimately a marketing exercise with a personality attached to it.
I see people do this in our industry and I don't blame them or dissuade them. They build a platform, curate a persona, post for engagement, optimize for reach. Some of them produce genuinely useful content — some I hang on every word. But I want to make it clear that's not what I'm doing, and I want to be explicit about the distinction because I think it matters. The moment the writing becomes about the writer instead of the reader, it stops being useful. The moment I'm optimizing for how I come across instead of whether the thing I'm saying is true and helpful, the whole exercise is broken. I'd rather have fifty readers who got something real out of an article than five thousand who liked a post because it was clever. (Though I do want to be clever.)
What keeps me doing it is that I genuinely believe the lessons I've learned from getting things wrong are more valuable than the things I've gotten right. The things I've gotten right are boring because they're the expected outcome. Nobody wants to read an article about the time I patched a vulnerability and nothing bad happened. That's not a story worth telling… that's a Tuesday. The industry is full of success stories. Conference keynotes are built on them. Case studies are polished into them. Vendor marketing runs on them. What the industry doesn't have enough of is honest failure stories, told by the people who were in the room when the failure happened, without the retrospective spin that makes it sound like the failure was secretly a strategic learning opportunity all along. Sometimes the failure was just a failure. Sometimes you just got it wrong. The value is in saying so clearly enough that someone else can learn from it.
The time I delayed a patch because the business couldn't afford the downtime and the vulnerability got exploited? That's a lesson worth writing about. The time I trusted a vendor's security assessment without validating it myself? That's a lesson. The time I built a detection capability that generated a wall of alerts and nobody could find the real incidents in the noise? That's a lesson. The time I presented a risk assessment to leadership and realized halfway through that I'd been measuring the wrong things? That's a lesson.
Those are the stories worth telling, not because they make me look good — they don't — but because somewhere out there is a security leader three years into the job who's about to make the same call I made, and if they happen to read the thing I wrote about making that call and it gives them one additional data point that changes the outcome, then the writing was worth doing. That's the bar I hold myself to. Not engagement metrics, not follower counts, not any of the influencer stuff. One person, one decision, slightly better information. Everything else is vanity.
I think the reason "thought leader" and "influencer" land wrong on me is that they both imply I'm ahead of the audience. That I know something they don't, and I'm generously sharing it from a position of expertise. That framing makes my skin crawl, not because expertise doesn't exist but because my particular version of it is built almost entirely on mistakes. I'm not ahead of anyone. I'm just further along in the specific journey of having screwed things up and lived to talk about it. That's not thought leadership… that's just being old.
I'm still learning. I need to say that plainly because it's true and because the moment I stop saying it is the moment the writing starts to calcify into something I don't recognize. Every week I read something that changes how I think about a problem. Every month I have a conversation with someone on my team who sees something I missed. Every quarter I look back at a decision I made and realize I'd make it differently now. If that process ever stops, it means I've either figured everything out (unlikely) or I've stopped paying attention (much more likely). The best leaders I've worked with are the ones who are still visibly learning in year twenty. The worst ones are the ones who decided somewhere around year eight that they'd learned enough.
I wrote an article recently about responsible AI adoption where I called out organizations for racing to implement AI without understanding what problem they were solving. Solid argument. Felt good writing it. Then, a week later, I caught myself doing something uncomfortably similar in my own program — evaluating a tool because it was interesting, not because I'd validated the need for it. The same pattern I'd just spent a thousand words criticizing. Writing about mistakes doesn't immunize you from making them. It just makes you slightly more likely to notice when you're repeating one. Slightly. Not always fast enough.
That kind of thing happens to me regularly, and I think it's important to admit that it does. The person writing the articles is the same person still making the mistakes. Those aren't different people. They're the same guy at different points in the same week. If the writing ever starts to sound like I've transcended the problems I'm describing, that's the signal that something's gone wrong with the writing, not that something's gone right with me.
I don't have a framework for how to be a good security leader. I know what the certifications teach (I have the CISSP, it's on the wall, it taught me things, it also didn't teach me things). I know what the conferences say. I know what maturity models suggest. What I've actually learned about leadership in this field came mostly from watching people I respect handle situations I found difficult, and from handling situations badly myself and figuring out what I should have done differently. That's not a methodology. It's just paying attention over a long period of time.
The blog started as a place to write that stuff down. It still is. The fact that people read it is flattering and occasionally terrifying. Flattering because it means the writing connects with something real. Terrifying because it means people might actually take my advice, and I'm not always sure my advice is good. I try to be honest about that in the writing itself. I hedge. I self-implicate. I say "I've been guilty of this" and "I'm not sure" and "this is what I think, but I could be wrong" — because those aren't performative humility. They're accurate disclaimers.
If that makes me a bad influencer, I'm comfortable with that trade.
Someone asked me recently what I want the blog to become. I didn't have a good answer at the time, but I've been thinking about it since, and I think the most honest answer is: I want it to be the thing I wish existed when I was coming up. A place where someone with experience talks openly and honestly about what they got wrong, why they got it wrong, and what they learned from it. Not wrapped in a success narrative. Not sanitized for professional consumption. Not positioned as a case study with a tidy resolution. Just… here's what happened, here's what I should have done, here's what I'd tell you if you were sitting across from me at lunch and asked for my honest opinion.
That's the version of mentorship that actually works, in my experience. Not the polished keynote version. The lunch version. The one where someone you respect leans across the table and says "yeah, I tried that, it was a disaster, here's why."
I write because I like writing. I write about security because that's what I know. I write about failure because that's where the lessons are. I write in first person because I don't trust anyone who only talks about other people's mistakes. I write in a conversational voice because I think the industry has enough white papers and not enough honest conversations.
I'm not a role model. I'm not someone to look up to. I'm a guy with a career's worth of lessons learned, a blog, and a willingness to admit in public that I don't have it all figured out. If that resonates with you, great. If it helps you make one better decision somewhere down the line, even better.
If it doesn't, that's fine too. I'll still be here next week, writing about the next thing I got wrong.
Because there will always be another thing. That's not just failure — that's the job. Get back up, learn from it, and keep making decisions.