Technical Credibility Without Staying Hands-On
The question isn't whether you can still code. It's whether your engineers believe you understand what they're living inside of. Those are different questions — and confusing them costs you.
The two failure modes
Easy to spot
The vocabulary performer
Sat in one architecture meeting, heard "microservices," now mentions microservices in every conversation as proof of engagement. Damage is real but bounded — senior engineers learn to route around them on anything that matters.
Harder to spot — and worse
The extrapolator
Was genuinely excellent 5–8 years ago. Has stayed close enough to technical work to believe they're current. Uses frameworks formed when the stack and problem domain were different enough that their intuitions are now systematically wrong in ways neither they nor their team can easily see.
What staying current actually looks like
Not writing production code. Reading the actual artifacts — not slides summarising the architecture, but the architecture itself.
Pull requests
How engineers frame tradeoffs when the audience is other engineers, not leadership
Incident timelines
What the system actually values vs. what the slide decks say it values
Design doc comments
Where senior engineers disagreed about an approach and how they resolved it
Commit history on aging services
Accumulated judgment embedded in a system that looks simple on a diagram
Post-mortem action items
Whether accountability is real or performed — check for the same root cause appearing twice
Signals that destroy credibility — fast
Naming technologies without understanding tradeoffs
If you say "we should look at Kafka for this" but can't explain what you'd be taking on operationally, you're signalling that you read tech news. Senior engineers hear this immediately.
Underestimating the cost of context switching
Non-technical leaders consistently treat engineering work like a grid of independent tasks. If your staffing and scheduling decisions reflect that model, your technical judgment credibility erodes regardless of vocabulary.
Confusing velocity with health
A team shipping fast is not necessarily a team building well. The credible question is: "What are we accumulating to sustain that rate? Is that a good investment?" That question signals you understand technical debt as a real balance sheet.
The highest-leverage move
Admit the boundary of your knowledge accurately and specifically. Not generically.
Generic — doesn't work
"I'm not close enough to the code to have a view on this."
Specific — builds trust
"I understood this 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."
This signals you have an accurate map of your own knowledge. It creates space for engineers to explain their thinking to someone who will actually hear it — which is often the thing they most need and rarely get.