There is an unspoken rule at the senior end of this industry: at some point, you stop touching production. You move from vim to PowerPoint. You stop reading log lines and start reading board packs. You become, in a phrase I cannot stand, strategic.
I have made a different bet, deliberately, for twenty-eight years. I still write the production PHP. I still harden the Ubuntu boxes. I still keep my own httpd.conf clean. And I sit on advisory bodies that decide what the rest of the industry has to do.
People ask me, kindly, why. The honest answer is that the gap between those two activities is where most cyber security goes wrong, and standing in it on purpose is the only way I know to be useful in both rooms.
What you lose when you stop writing the code
You lose the ability to call your own bluff. The CEO who hasn't shipped anything for six years can still talk fluently about deployment pipelines, but the words have detached from the things. They become a fluent vocabulary with no attached weight. The board never notices. The engineers do, almost immediately.
You lose the cost calibration. If you have not personally argued with a slow query for ninety minutes, you do not have a working intuition for how long it takes to fix things. Your timelines drift. Your sympathy goes with them.
You lose the boredom. The thing that nobody tells you about being a CEO is how little of the day is interesting. Production work is not always interesting either, but it is reliably real. It anchors you. The week you spend on a refactor is a week you have not spent on six meetings about strategy, and you come back to the strategy with the unfair advantage of having done something.
What you get from staying
A working bullshit detector for vendors. There is no substitute for having recently sworn at apt, systemctl, and the same tool you are being sold the enterprise edition of. You know what it really does. You know what it really costs.
The continuing right to disagree. When a junior engineer says we should rewrite the authentication layer, I can ask them three questions that make it clear whether they have thought about it or whether they are repeating something they read on the train. They can ask me three questions back. We will reach an answer in twenty minutes.
A small, real example of craft. The thing on my desk this week is a PHP rewrite of an old triage tool. I have written it carefully — declare(strict_types=1), escaped output everywhere, sessions hardened, mail headers stripped of newlines. None of that will be on a board pack. All of it is the actual work.
The objection
The objection people raise is reasonable: you can't be the best in the building at any one of these things. That is true. I am not the best operator in my company. I am not the most senior figure on the CREST European Council. I am not the strongest writer in any room. I have made a choice to be capable in three rooms instead of brilliant in one.
For the work I actually do — running a small cyber defence company, advising on European standards, occasionally writing this — capable in three rooms is the more useful shape. I have stopped apologising for that.
A note for the people who think they have to stop
You don't. The pressure to become just the executive is mostly external, and mostly wrong. Keep a small thing on your desk that you are personally responsible for shipping. Keep a small terminal open. Keep your fingers in the work.
The board will not punish you for it. They will notice — and quietly trust you more.