The Critical Question CTOs Rarely Ask
When stepping into the role of CTO, one of your first priorities is to understand the company's systems deeply. This involves asking a myriad of questions:
- How many people are in the company?
- How many engineers do we have?
- What's the budget?
You'd inquire about data centers, incidents, bugs, the agile setup, and much more. Yet, there's one crucial question that rarely gets asked—or, if it does, seldom receives a satisfactory answer:
How many lines of code does the organization have?
- How many lines of code were added or removed last year?
- Can we track how much code each engineer has written?
These questions often go unanswered because many organizations rely on decentralized source code systems like GitHub or Bitbucket, designed for open-source projects. When these tools are used without proper structure or "social design," they fragment the codebase, making it nearly impossible to gather meaningful data, disabling companies to find insights on work traffic jam that's responsible for much of the issues. Post on decentralized code management system increases collaboration at team level and kills it at enterprise level by taking all oversight and governance away from management.
A Real Example
In one instance, a CTO couldn't believe their company lacked visibility into its codebase. I challenged their team to provide data—within 10 days—restricted to code in production or supporting production. This excluded hackathon projects, forks, and any code without economic value.
The CTO quickly realized why this was an impossible task under their current setup. When I explained the fragmentation caused by their source code management system, they understood the issue immediately.
Why Does This Matter?
Your company's performance—productivity, quality, cost of operations, and even project success—starts with code. Think of the company as a system:
- Business as a System(BAAS) contains Product Development Lifecycle (PDLC) as a System(PAAS).
- PAAS contains Software Development Lifecycle (SDLC) as a System (SAAS)
- SAAS contains Code Development Lifecycle (CDLC) as a System. (CAAS)
If your CDLC As A System(CAAS) is broken, meaning your factory is in crazy problem, no amount of improvement to the SDLC or PDLC will help. Reason Agile and other methodology fails, because they mostly focus on improving how to organize tickets, people , story pointing etc. that too at a team level which is different than managing whole enterprise. So the helpless CEO and leadership often resort to controlling visible costs in P&L instead of addressing systemic inefficiencies caused by poor CDLC management which blocks value creation.
The Dangers of Misinterpreting Code Data
Gathering CDLC data is fraught with risks, especially for teams that lack a systems understanding. Misuse of this data often leads to misguided comparisons, like ranking engineers based on the volume of code written—a classic example of bad metrics leading to poor decisions.
For instance:
- Writing too little code or too much code can both indicate something to be investigation.
- The best engineers—those focused on mentoring, code reviews, or critical oversight—might appear to write minimal code.
Using code metrics without context is like giving a monkey a sword to protect a king—it can backfire spectacularly.
A Case Study
At one company, collecting code data revealed that several high-cost contractors wrote almost no code for months. This discovery shocked the VP, who had approved these hires to accelerate projects. What we found was terrible, but there was no cheating or malfeasance—the issue lay in how the CDLC system was designed and understood. By uncovering this, the VP gained insights they previously lacked and avoided future inefficiencies and instantly saved few millions in cost, instantly affecting P&L. Can't go in details.
In the same company, we found that many developers have written crazy half a million of so lines of new code. Again, no one was was doing anything wrong intentionally, but path to hell are paved with good intention. In general company of problems are highly correlated to developers not writing[not able to write] meaning ful code, or developers writing waaaaaay too much code, but code growth unless intentional and for true economic value is early sign of broken system and future problems to come.
The most valuable insight from code data is its ability to reveal work queues building up at the repository level. This provides CTOs and their teams with a clear understanding of how each project becomes stuck in what we call "work traffic jams." Importantly, we focus not on queues at the developer or team level but at the repository level, which developers serve. This approach is inspired by Donald Reinertsen's book Flow, where he identifies invisible queue build-ups as the root cause of project delivery failures. These patterns become strikingly clear when analyzing enterprise-wide repository and code metrics, offering a perspective far richer than individual repositories alone. The whole system exhibits emergent properties that individual parts do not, often showing how improving a single team's efficiency can inadvertently make the entire system less efficient—but that's a discussion for another day.
Why This Should Be a CTO's Priority
After understanding the company's budget, people, and infrastructure, your next step as a CTO should be analyzing your code data. This information tells stories no survey or report can match. Some of the best companies use this data not just to track performance but also for evaluations. After all, as knowledge workers, encoding knowledge into code is a fundamental part of the job.But chances of one can get this data with high fidelity is very low if you use poly repo based SCM systems.
A Word of Caution
For engineers, the idea of measuring code can be unsettling—often because they don't trust management to interpret the data correctly. Their skepticism highlights a deeper issue: many managers lack the understanding of CDLC systems required to make sound, data-informed decisions. If someone decided to promote people on how much code they have written than problem is not data, problem is understanding of how to interpret the data. The solution is then how to improve managers understanding or evaluate who shall be the managers.
Remember: Decisions should be understanding-driven, not just data-driven. Here is the post
