The defense usually sounds like this: “I manage people, not the code. My job is hiring, retention, salary conversations, headcount planning. Whether my team uses git rebase or not — that’s not my concern.”
That logic draws the line in the wrong place.
The question was never whether you can code. It’s whether you can tell when your team is doing good work.
Domain literacy vs. domain mastery
I know a farmer who picked it up two years ago — not professionally, for himself. In those two years he learned how much straw his farm needs to get through winter. The meat yield, by cut, from each animal. Early signals in cattle that take more experience to catch. He didn’t go to agricultural school. He just engaged with the work long enough to understand what “normal” looks like in his domain.
That’s literacy — the ability to read what’s happening.
There’s a level above it, too. When a situation demands more — a technical crisis, a decision that hinges on domain judgment — a manager with real domain literacy can go deeper. Not to professional depth. To a functional level: enough to hold a real conversation, ask the right questions, and make a call. The farmer isn’t a vet. But if something goes wrong with an animal, he’s not going to stand there helpless. He’ll get to a working diagnosis fast enough to know what to do next. Mid-level competency, on demand. Not git rebase on day one. But git rebase in a week if it matters.
Engineering managers who stopped writing code fifteen years ago — the question isn’t how many years have passed. It’s whether in those fifteen years they engaged with the outputs of their teams enough to know when something’s off. Some do. Some drift into org structure and headcount and culture, and slowly lose the ability to read the work itself.
When that happens, they start managing the surface.
What managing the surface looks like
At Amazon I ran a bootcamp for new managers. The first principle we drilled: be fully staffed. It means hiring well and holding onto people. The logic is right — put the right people in the right roles and results follow.
You cannot know if the right people are in the right roles if you can’t evaluate what they’re producing. “Fully staffed” is a judgment call about people and output. That judgment requires domain literacy.
I got this wrong early. I remember thinking my job was the people, and that the results — what the team actually delivered, whether the architecture was holding, whether the velocity was real or borrowed time — were somehow downstream and would sort themselves out. They don’t. The results are yours. The people are the mechanism.
The Staff Engineer objection
In large organizations, Staff and Principal Engineers do the technical evaluation. They set standards, run architecture reviews, catch the things that would break at scale. An EM in that environment might genuinely never need to evaluate a pull request.
But “never evaluate a pull request” and “can’t evaluate the output of your team” are not the same sentence.
Delivery velocity. Whether the team is burning down tech debt or accumulating it. Whether complexity is growing because the problem is genuinely hard or because nobody is pushing back. Whether a reorg would help or just reshuffle the same dysfunction. These are output-level judgments that don’t require code review — but they do require enough domain literacy to know what you’re looking at.
I know someone who runs multiple departments and genuinely doesn’t know how to assess whether one of them is doing good work. He’s managed the surface long enough that he’s lost the signal.
The test
When did you last realize that one of your teams was off track — before someone told you?
Not the moment someone brought you a problem. Not when a metric surfaced it in a review. The moment you sensed it from the texture of what they were producing, the shape of the conversations, the pattern of what kept getting deprioritized.
That’s domain literacy. You either have it or you don’t. And if you don’t, being fully staffed won’t save you.