The questions your CTO can't answer (and why that's not a firing offense)

Before telescopes, the best astronomer in the world and a reasonably attentive shepherd had access to exactly the same sky. The astronomer knew MORE — better models, better math, better guesses — but their raw data was identical: whatever the naked eye could catch. Galileo didn't out-think his predecessors so much as out-instrument them. Point a tube of glass at Jupiter and suddenly there are moons that the smartest person in history couldn't have seen the night before.

Keep that in mind, because this post makes a claim that sounds like an attack and isn't: your CTO cannot answer some of the most important questions about your codebase. Not because they're bad at their job. Because they're an astronomer without a telescope, and everyone — including them, including you — has been grading them on eyesight.

The honest unknowns

Here are questions a genuinely excellent CTO, running a genuinely well-managed team, still cannot answer with confidence. If you're a founder, resist the urge to test your CTO with these over lunch. (Or don't. But buy the lunch.)

1. "Which of our code is fragile AND load-bearing?" Your CTO can name fragile code — everyone remembers the module that fights back. And they can name important flows. But the intersection, weighted by actual production traffic? That requires knowing per-function traffic (Part 14 of this series: nobody knows this) and per-function failure behavior (Part 16: normalized out of view). The scariest set in the whole system is computable only from two datasets no one has.

2. "What does the AI-assisted module actually do?" This one is new, and it's growing. A meaningful share of your recent code was drafted by a model — prompted, skimmed, merged. GitClear's analysis of hundreds of millions of changed lines documents the shift in what's entering codebases in the AI era: more churn, more duplication, more code that no human ever held in their head at any point in its life. Peter Naur argued in "Programming as Theory Building" that a program IS the theory of it in its builders' minds. For machine-drafted code there was never a builder's mind. Your CTO isn't failing to retain that knowledge; the knowledge was never instantiated in a human. Asking anyone what that module "really does" is asking who remembers a meeting that no one attended.

3. "How much of the codebase did any work this quarter?" Dormancy (Part 13) is invisible from the org chart and mostly invisible from static analysis. Your CTO's estimate of the dead share is a guess, and — in CodeNSM's own fleet telemetry, where the first census routinely surprises the most senior person in the room — the guess is usually generous in the wrong direction.

4. "Is the system getting slower?" Not "is it slow today" — trending, per function, against baselines from a year ago (Part 15). Without retained per-function history, this question has no data behind it, only impressions. Impressions renormalize. That's what makes them impressions.

5. "Where would a departure hurt most?" The real map from engineers to the code only-they-understand. Your CTO holds a version of this map, but Adam Tornhill's Your Code as a Crime Scene work on knowledge maps shows the mined-from-git reality reliably diverges from the folk version — people remember who WROTE things, not who last understood them.

Why the role can't contain the answer

Notice the pattern in those five questions. None of them is a judgment question. Every one is an observation question — a "what is currently true in production" question — and observation doesn't scale with seniority. It scales with instruments.

A CTO's actual toolkit for "knowing the codebase" is: what they personally wrote (years ago now), what they review (a sampling, shrinking as the team grows), what breaks loudly (a biased sample), and what their reports tell them (compressed, filtered, and — per the SPACE framework authors' warning about activity metrics — usually denominated in commits and story points, numbers that measure motion rather than condition). That toolkit builds a good model of the TEAM. It cannot build an accurate model of a two-million-line system that changes hundreds of times a week. There is no amount of talent that substitutes for data you don't have; Galileo with cataracts still beats no telescope, but not by much.

And here's the part that actually damages companies: everyone politely pretends otherwise. The founder assumes the CTO knows (that's their job, right?). The CTO, asked a question from the list above, produces a confident-sounding synthesis — because "I cannot know that" feels like failing, even when it's just physics. The board hears the synthesis and files it as fact. Nobody lied. A guess simply got promoted to knowledge somewhere between the whiteboard and the board deck, the way guesses do when no instrument exists to embarrass them.

The two jobs hiding inside "knowing the code"

The resolution is to notice that "my CTO knows the codebase" has always quietly bundled two different jobs:

1. Observation — what is the system doing? Which functions ran, failed, slowed, went silent? This is sensing. It is mechanical, continuous, and boring.
2. Judgment — given what the system is doing, what should we do? This is expensive, contextual, deeply human, and the actual reason you pay your CTO.

We staffed both jobs with the same human, then acted surprised that the human excels at the second and cannot physically perform the first past about fifty thousand lines of code. No other executive is asked to BE their own instrument. Your CFO doesn't personally observe every transaction; the ledger observes, the CFO judges. Your CTO is the only chief officer expected to serve as their own measurement apparatus — and the expectation is so normalized that CTOs themselves apologize for the gap, in the tone of someone apologizing for not having memorized the phone book. (Separating those jobs — an instrument that does the observing, continuously and per-function, so the human can spend entirely on judgment — is the whole design premise of CodeNSM. One sentence, moving on.)

What changes when the telescope shows up

The astronomy version has a happy ending worth borrowing. Telescopes didn't make astronomers obsolete; they made astronomy possible. The shepherd and the professor stopped having the same data, and the professor's training suddenly had something to grip.

Same shape here. Give a strong CTO the actual hot-path map, the actual dormancy census, the actual fragile-and-load-bearing intersection, and their judgment — all that expensive, hard-won taste — finally gets applied to the real system instead of to a memory of it. The five unanswerable questions become Tuesday-morning reading. And one more thing quietly improves: the founder-CTO conversation stops being a trust exercise. "How's the codebase?" currently has only one possible answer ("pretty good, some debt, we're managing it") because it's a question about an unobserved system, and unobserved systems all sound the same. With shared instruments it becomes a question with a NUMBER in the answer, and numbers can be discussed by two people without either one having to simply believe the other.

So no — this was never about what your CTO can't tell you. It's about what nobody could tell anybody, for fifty years, because the telescope hadn't been built. The unknowns were honest.

Keeping them is now a choice.