I'm a Chief Data Officer who still writes SQL. When there's a security gap in one of our products, I audit the codebase myself before scoping the fix with my engineers. This is not nostalgia for the tools, and it is not a hobby I protect from the calendar. It is a deliberate operating model, and I think more technical executives should adopt it.
Strategy drifts at the speed of abstraction
The core claim: the moment a technical leader stops understanding the system at implementation level, their strategy starts to drift from reality. Not immediately, and not visibly. The drift happens through a thousand small translations, as every layer of reporting between you and the system simplifies, rounds off, and reframes. Each summary is honest. The accumulation is fiction.
You can see the drift in its symptoms: roadmaps that assume integrations are simpler than they are, risk registers that name the wrong risks, modernisation programmes scoped off diagrams that no longer match the deployed system. None of these require anyone to be wrong on purpose. They only require that nobody at the decision-making table has recently read the code.
The player-coach model
My version of staying close is what I'd call player-coach. I lead teams across data engineering, analytics, security, and technology operations; setting direction, hiring, and being accountable for outcomes is most of the job. But I keep a deliberate, bounded practice of doing the work: writing the pipeline SQL when we need a new pipeline, auditing code when security questions arise, building and operating my own agent infrastructure end to end outside work hours.
The point is not that I could do my engineers' jobs. I could not, and the role does not require it. The point is calibration. Because I have recently touched the real system, I can tell when an estimate is padded, when a vendor claim doesn't survive contact with our architecture, and when a one-line change is actually a one-line change. When I took on the security assessment of an acquired platform, I did the hands-on investigation myself; the remediation scope that followed was credible with the engineers who had to deliver it because it came from the codebase, not from a slide.
What it buys you
- Honest strategy. Plans built at implementation level survive implementation. The distance between what you promised the board and what the system can do stays small enough to manage.
- Credibility in both directions. Engineers extend a different quality of trust to a leader who reads the code, and boards extend a different quality of trust to an executive whose answers about technical risk come from first-hand contact.
- Judgement on new technology. Agentic AI is the current test. I would not sign off autonomy policies for systems I had never built. Running my own agents is what taught me which controls matter and which are theatre, and that judgement transfers directly into how I govern the technology at work.
Making it work without becoming the bottleneck
The obvious objection is that executives who code become bottlenecks, or worse, hobbyists who disrupt their own teams. The failure mode is real, and the answer is boundaries rather than abstinence. What has worked for me:
- Do work that informs decisions you own: an audit before you scope a remediation, a pipeline in a domain you are setting strategy for. Do not take the critical path.
- Keep a system you operate end to end, even if it is your own infrastructure on your own hardware. Operating something, including owning its failure modes, teaches what no review meeting can.
- Let your engineers overrule you in their own domain. Staying close is about your calibration, not your authority.
The standard I'd propose
If you lead a technical organisation, you do not need to ship features. You need recent, first-hand contact with the systems your strategy depends on, frequent enough that your mental model stays truthful. For me that is SQL, code audits, and a rack of containers that pages me when I got something wrong. Choose your own form. But if every fact you know about your systems arrives through three layers of summary, your strategy is already drifting. You just have not found out yet.