Technical Credibility When You Haven't Coded in Five Years

There’s a version of the technical credibility problem that engineers talk about openly: the executive who sat in one architecture meeting, heard the word “microservices,” and now mentions microservices in every subsequent conversation as proof of engagement. This person is easy to spot. The damage they do is real but bounded, because senior engineers learn quickly to route around them on anything that actually matters.

The harder version is the technical leader who was genuinely excellent five or eight years ago, and who has spent the intervening time close enough to technical work to believe they’re still current. This person is harder to spot because they’re not faking — they’re extrapolating from real experience that’s no longer representative. The framework they’re using to evaluate technical decisions was formed when the stack, the tooling, and the problem domain were different enough that their intuitions are systematically wrong in ways that aren’t obvious to them or to the people around them.

I’ve been both of these people at different points. The second version is worse.

What technical credibility actually requires

It doesn’t require writing production code. It requires understanding the texture of the decisions your engineers are actually making — the tradeoffs, the constraints, the irreversible choices embedded in an architecture that looks simple on a diagram but contains three years of accumulated judgment.

The way I’ve stayed current without staying hands-on is specific: I spend time with the actual artifacts. Not slide decks summarizing the architecture. The architecture itself. Pull requests. Incident timelines. The comments in a design doc where two senior engineers disagreed about an approach and resolved it by trying both. The commit history of a service that’s been through three major revisions.

You learn a lot from reading what engineers write to each other when they think the audience is other engineers. The language changes. The level of specificity changes. The things they worry about are different from the things they worry about in a roadmap review. That gap — between how technical work is represented to leadership and how it’s discussed among engineers — is where a lot of organizational dysfunction lives, and you can only see it if you’re reading the right documents.

The specific things that signal false credibility

Naming technologies without understanding tradeoffs. If you can say “we should look at Kafka for this” but you can’t explain what you’d be taking on operationally when you do, you’re signaling that you read tech news rather than that you understand engineering decisions. Senior engineers hear this immediately and it costs you.

Underestimating the cost of context switching. Non-technical leaders consistently underestimate how expensive it is for an engineer to be pulled off deep work. They also consistently overestimate how much can be parallelized. If you’re making staffing and scheduling decisions that treat engineering work like a grid of independent tasks, your credibility on technical judgment will erode regardless of how technically sophisticated your vocabulary is.

Confusing velocity with health. A team shipping fast is not necessarily a team building well. Some of the most technically credible leaders I know are the ones who can look at a release velocity number and immediately ask: what are we accumulating to sustain that rate? Is that a good investment or a bad one? That question signals that you understand technical debt as a real phenomenon with a real balance sheet, not as a consulting concept.

The underrated credibility lever

The highest-leverage thing a technical leader can do for their credibility — and this took me an embarrassingly long time to figure out — is to admit the boundary of their knowledge accurately and specifically. Not generically. Not “I’m not close enough to the code to have a view on this.” But: “I understood this problem domain well in 2019 when we were doing X, but the shift to Y changed the constraint set in ways I haven’t caught up with. Walk me through your model.”

That statement does several things simultaneously. It signals that you have an accurate map of your own knowledge rather than a inflated one. It signals that you’re asking a real question rather than a credentialing exercise. And it creates space for your engineers to explain their thinking to someone who will actually hear it — which is often the thing they most need and rarely get.

Technical credibility, in the end, is not about what you know. It’s about whether your engineers trust that your judgment — on priorities, on tradeoffs, on what’s worth the cost — will survive contact with the actual difficulty of the work. That trust is built by being honest about what you see and what you don’t, not by performing a fluency you haven’t maintained.