Elon Musk reportedly reviews pull requests at X. Mark Zuckerberg still writes code and has spoken publicly about wanting to remain a hands-on engineer, not just a manager. Bill Gates was famous for memorizing his employees’ license plates to track who worked late, but he was also the guy who could sit down and tear apart your code line by line. When someone controls a company worth hundreds of billions of dollars and employs armies of engineers earning serious money, why are they still personally writing software? The answer is less about ego and more about a specific kind of organizational leverage that most people outside of engineering leadership never think about.
It turns out that the decision to keep paying engineers enormous salaries while the founder also codes is not redundant. It reflects something structural about how software organizations actually work.
The Information Asymmetry Problem
Here is the core issue. When you lead a large engineering organization, you are dependent on what your engineers tell you. Every layer of management between you and the codebase is a translation layer, and each translation introduces distortion. A senior VP tells you the new recommendation system is “on track.” What does that actually mean in terms of model accuracy, latency, edge case handling, and technical debt accumulated? You often have no idea unless you can read the code yourself.
Founders who code can bypass these translation layers. When Zuckerberg says he wants to understand a system, he can pull up the repository and actually read it. He can see whether the architecture makes sense, whether corners were cut, and whether what he was told in a meeting matches what is actually shipping. This is not micromanagement. It is information hygiene. The gap between what leadership is told and what is true in the codebase is one of the most underappreciated sources of organizational failure in tech.
This connects directly to why serial founders often fail before suddenly succeeding. Many of the lessons that compound across attempts are fundamentally about closing information gaps, understanding what is really happening in your product versus what your team believes is happening.
Code as a Leadership Language
There is a second, less obvious reason. Writing code keeps technical leaders fluent in the language their engineers actually speak.
Consider what happens in a technical debate when the CEO cannot evaluate competing arguments on their merits. Engineers learn quickly which leaders understand the tradeoffs and which ones are guessing. When leadership cannot tell the difference between a genuinely complex engineering problem and a team that is dragging its feet, the incentives inside the organization shift in unhealthy ways. Teams learn to package information for non-technical leaders rather than solve problems efficiently.
When a founder can sit down and actually engage with the code, meetings change. Debates get more honest. People cannot hide behind jargon. Proposals get evaluated on technical merit rather than on how confidently they were presented. There is a reason the best engineers and founders still reach for a notebook to think through problems, rather than outsourcing cognition to tools. Staying close to raw problem-solving, whether on paper or in a code editor, keeps reasoning sharp in ways that consuming dashboards and summaries simply does not.
The Taste Problem
Beyond information and language, there is something harder to quantify: taste.
Software products have an aesthetic quality that is not reducible to metrics. The difference between an app that feels fast and one that merely benchmarks fast involves hundreds of small decisions baked into the code. The difference between an API that developers love and one they tolerate comes down to choices that seem minor in isolation but accumulate into a coherent sensibility.
Founders like Jobs, Wozniak, and Gates had strong technical taste, and that taste propagated through organizations because they could demonstrate it concretely in code. You cannot credibly insist on elegance if you cannot recognize it. You cannot push your team toward a better technical solution if you cannot articulate why it is better in terms engineers respect.
This is part of why the most technically sophisticated companies tend to produce technically sophisticated products, even in areas that seem unrelated to engineering. The way tech giants think about something as seemingly shallow as color psychology reflects an organizational culture where every layer of the product is subject to rigorous, taste-driven scrutiny. That culture has to start somewhere, and it usually starts with founding teams who could not stop themselves from caring about the details.
The Signal It Sends Internally
There is also a pure signaling function that should not be dismissed.
When engineers know that their CEO can read code, the organizational culture changes. You cannot bluff your way through a technical review with someone who can actually check. You cannot claim a problem is unsolvable to someone who might spend a weekend proving otherwise. This creates a useful kind of accountability that is very difficult to replicate through process or management hierarchy alone.
Satya Nadella at Microsoft is a credible technical voice inside an enormous engineering organization. Jensen Huang at Nvidia is deeply fluent in GPU architecture. Linus Torvalds still reviews and writes code for the Linux kernel, a project running on a significant portion of all computing infrastructure on earth. None of these people need to write code in any economic sense. The leverage argument for their time almost certainly points elsewhere. But they maintain technical credibility deliberately, because the organizational benefits compound in ways that are hard to see on a spreadsheet but easy to feel inside a company.
What This Means for Everyone Else
For founders who are not yet billionaires, the lesson is more urgent. Delegating technical judgment too early is one of the most reliable ways to lose the thread of what you are building. The product vision you started with is encoded in technical decisions, and if you cannot read those decisions, you are trusting someone else’s encoding of your idea.
For engineers, understanding why your CTO still shows up in code reviews is useful context. It is not about distrust. It is about maintaining the connective tissue between organizational decisions and technical reality, a connection that atrophies surprisingly fast once it is no longer actively maintained.
The founders who stay in the code are not doing it because they are control freaks (though some are). They are doing it because they have learned, sometimes through expensive failures, that the map and the territory diverge fast in software, and the only reliable way to keep them aligned is to keep looking at the territory yourself.
