Always Be Coding (Even If You’re the CTO)
One of the earliest lessons many engineering leaders hear is that, sooner or later, they should put down their IDE. “Your role has changed!” they’re told. You can’t be in the weeds anymore. Delegation is essential. Your time is too valuable to spend hours tweaking a build pipeline or stepping through component code. Whether that message arrives as encouragement, warning, or mandate, it reflects a widespread belief in tech leadership: the path from engineer to CTO involves gradually distancing yourself from the codebase you once lived within. From a particular perspective, this makes sense. As a company grows, the role expands into team building, organizational design, cross-functional alignment, vision setting, and sometimes fundraising and board management. The farther up you go, the more abstract the work becomes.
Something important is lost when that distance becomes complete. Not only a skill or habit, but a kind of empathy and texture that no dashboard can reproduce. CTOs, regardless of company size or maturity, benefit from staying close to the codebase. Not as bottlenecks and not as shadows that lurk over the team, but as participants who maintain fluency with the system, a feel for the work, and keep a direct channel of context open. This isn’t nostalgia for hands-on days. It’s a practical case for effectiveness.
The Risk Of Living Only At Altitude
The higher you operate in an organization, the more your inputs arrive as summaries. You review goals, budgets, hiring plans, and architecture diagrams. You get written updates and even slide decks. These are useful, but they are also lossy. They compress nuance, and they omit friction. In a status report, the development environment never fights you, the test suite never flakes, and the docs are never half a release out of date. None of that minor pain shows up unless someone expends social capital to raise it, and people rarely want to “waste” an executive’s time with problems that look minor in isolation.
Engineering quality and velocity are built from that small stuff. The difference between shipping and stalling, or between confidence and anxiety, is often hidden in setup scripts, build times, and confusing edges that daily contributors silently work around. When you stop writing or reading code entirely, you begin to lose the intuitive sense of where the sand gets between the gears. That detachment makes it easier to overestimate capacity, underestimate complexity, or approve solutions that look clean on paper and turn brittle in production. Staying close to the code functions as a counterweight. Outside the smooth slides and concise summaries, you find the grit and friction. It helps you feel the actual constraints your teams operate under, which is essential if you want a strategy that survives contact with reality.
The Cultural Signal Leaders Send
Culture is shaped as much by what leaders do not do as by what they do. When a CTO treats the codebase like a no-go zone, it suggests that craft is a secondary concern and that engineering is merely a production function. No one needs to say this explicitly for it to color the way people work. On the other hand, when a CTO is willing to open the repository, review the changes from last week, file a bug after using staging, or fix a minor annoyance in a script, it sends a different message. It shows curiosity, respect, and a continued commitment to the thing itself. You aren’t there to out-code your team or to set the bar through heroics. You’re there to demonstrate that the work still tangibly matters to you.
That presence also changes how feedback lands. Advice that arrives from a purely managerial vantage point is easy to discount, even when it’s correct. Advice informed by firsthand familiarity with the environment and the code paths brings a different weight. You aren’t theorizing from afar. You’re engaging with the artifact everyone else engages with, and you’re doing so in a way that honors the team’s ownership of it.
Context That Improves Decisions
Executives rely on judgment more than they rely on keystrokes. Judgment improves with context. Reading a few pull requests each week, stepping through a tricky migration, spinning up the dev environment yourself, or walking through a recent incident write-up will sharpen your sense of tradeoffs. You start to notice recurring patterns that don’t surface in formal updates. Perhaps teams are compensating for an awkward boundary between services. Perhaps certain utilities are being rewritten repeatedly because they’re hard to discover. Perhaps your confidence in a third-party dependency is misplaced. None of this requires you to take over. It only requires you to remain familiar enough to ask better questions, to support the right technical investments, and to protect the schedule from false simplicity.
There is a communication dividend here as well. When you understand how something is built, you can explain why it matters to non-engineers without resorting to hand-waving. Advocacy for internal tooling, reliability work, and developer experience lands more effectively when you can connect those efforts to tangible frictions you’ve personally encountered. That credibility makes it easier to secure time for foundational work that doesn’t show immediate revenue impact but is the difference between slow decline and sustained momentum.
Presence Without Micromanagement
Touching the code doesn’t mean inserting yourself into every decision or rewriting work after it merges. The aim is not control. The aim is presence. You can read diffs without becoming a blocker, and you can ask clarifying questions without undermining ownership. You can pair with a team to understand a complex change, then step out so they can execute. You can explore failure states in staging and record what you saw. You can run a deployment and feel the pauses. You can struggle through the onboarding path exactly as a new hire would and adjust priorities accordingly. None of this requires heavy time investment. It only takes regular, intentional contact.
Striking the right balance is a leadership skill just like hiring or budgeting. It improves with practice. If you find yourself choosing between being absent or being overpowering, choose a third option and calibrate. Agree with your teams on where your involvement helps and where it hinders, then hold yourself to that line. Show them you trust their decisions and expertise (more on this in a future article). The point is to gather context and model care, not to become a hidden dependency.
Coding As A Form Of Listening
Code is a primary source. When you read it, you hear how your organization thinks. You hear what your processes actually produce, beyond what the templates say they should produce. Naming choices reveal the shared vocabulary. Test coverage reveals what people fear. Commit history reveals where the risk lives. That kind of listening doesn’t replace roadmaps or rituals, but it complements them in a way nothing else can. It also improves empathy. If you wrestle with the same rough edges your engineers do, you’ll be much more willing to invest in developer experience and infrastructure. You won’t need to be convinced with a slide. You’ll have felt it.
There’s room for curiosity and joy here, too. A short session building a small internal tool or prototyping a notion you’ve been simmering on can refresh your sense of the material you work with. It keeps you from treating code as an abstract thing that other people do. It keeps you in beginner territory with new frameworks often enough to remember what it’s like to be uncertain. That humility tends to produce gentler processes and stronger teams.
Practical Contact That Scales
The objection that this doesn’t scale is commonplace. It’s true; a CTO can’t behave like a full-time IC in a large organization. It isn’t true that the only alternative is total separation. Light, regular contact scales very well. Reading a few key pull requests doesn’t slow anyone down. Running through the setup guide on a fresh machine once a quarter pays for itself quickly. Joining a pairing session on a strategic project gives you context that no status document can, and it does so without stealing control from your engineers. Trying a deploy or walking through logs from a recent incident may take an hour, but it may save you weeks of misguided prioritization later.
You won’t be measuring the value from this in merged lines. You’ll measure it in the quality of decisions you help the organization to make, in the alignment between strategy and implementation, and in the trust your teams place in your understanding of their reality. All of those outcomes improve when you keep a hand on the source of truth.
Guardrails That Keep You Out Of The Way
There are boundaries worth stating clearly. Don’t override technical decisions that belong to the team unless there’s a pressing business reason and you explain it fully. Don’t drop surprise pull requests that invalidate work already in motion. Don’t siphon interesting tasks from engineers who would grow by tackling them. If you want to contribute code, agree up-front on what kinds of changes are helpful and which areas are off limits. Treat your involvement as a privilege granted by the team for the benefit of the product, not as an entitlement that comes with your title.
If you follow those guardrails, you’ll find that your occasional contributions, even when tiny, have a multiplier effect. They surface gaps no one noticed. They shorten feedback loops. They help teams feel seen. They also keep you honest about the state of your tools and processes, which is the only way to improve them meaningfully.
The ABCs of Proximity
Leadership at scale can drift into a world of abstractions where all the edges are smooth and nothing is sticky. The map isn’t the territory. The status page is not the experience. A CTO who never touches the code loses access to a primary source that would make their strategy sturdier and their communication clearer. Staying close to the code doesn’t mean you’re the fastest engineer in the room or that you spend evenings hunting memory leaks. It means you’re willing to stay fluent in the thing your organization exists to produce. It means you respect the craft enough to keep learning its current shape. It means your decisions are anchored to realities you’ve verified for yourself.
So, always be coding. Not constantly, not competitively, and not as a substitute for the parts of your role that only you can perform. Code enough to retain fluency. Code enough to feel the rough edges your teams live with. Code enough to ask better questions, to notice the early signs of trouble, and to champion the work that sustains long-term project health. That’s not regression. That’s leadership grounded in proximity, and the best engineering organizations I’ve seen are led by people who never gave that up.