Imagine being wheeled into surgery and discovering that your surgeon hasn’t actually held a scalpel in twenty years.
He still wears the white coat, still carries the prestige of his past experience... but for the past two decades, he's been sitting on the sidelines watching other surgeons doing the work, and opining on their technique. He's been around the game, but not in it.
In medicine, we’d never tolerate that kind of distance from the work.
In technology, however, we often do.
This was on my mind recently when I read Charity Majors’ essay on architects. She points out that many architects carry massive prestige, but little current fluency: their technical skills are rusty, their advice is abstract, their authority is more symbolic than practical. Her critique was blunt, but it struck me: this isn’t just about architects. It’s a pattern across senior leadership in technology.
Belonging in technology isn’t about your job title. It’s about proximity to the work. When we drift too far, we stop being technologists and start being bureaucrats.
And we have more than enough bureaucrats.
Before You Come After Me
I’m not suggesting that every VP or CTO should be on call every week or writing production code daily. The point isn’t micromanagement; it’s maintaining enough fluency to make credible, informed decisions. Yet the structure of tech careers often pushes leaders away from the very work that made them effective in the first place! As engineers climb the ladder, influence increasingly comes from meetings, org charts, and strategic memos rather than debugging a service or reviewing a pull request. Prestige and recognition accrue to titles, budgets, and visibility; meanwhile, hands-on skill quietly atrophies. Over time, the system nudges leaders farther from the tools, the processes, and the subtle realities that shape real outcomes — and suddenly, making “good technical decisions” becomes more about opinion than understanding.
What's Wrong With Having An Opinion
Well, nothing... unless it's untethered from understanding. The concept may feel a bit abstract, but the consequences aren’t. When leaders lose touch with the work, decisions start to become unbalanced in subtle ways: priorities get misaligned, timelines stretch.
But the real damage shows up when teams lose trust in guidance that feels detached or uninformed. Engineers begin to notice that architectural mandates ignore reality, tooling choices create more friction than they solve, and roadmaps are set without understanding the real effort required. Small misjudgments quickly compound, creating systemic inefficiencies, frustration, and burnout — and over time, a leader’s engineering atrophy can erode the credibility and influence they’ve worked hard to build. What starts as a gradual drift from the work can quickly become a culture where process and prestige matter more than outcomes, and where the people actually building the systems begin to tune out those calling the shots. Simply put, the atrophy of a leader's engineering skills risks a complete loss of their influence, invalidating all that wisdom they've worked so hard to accumulate... because their credibility is eroded.
There's Still Hope
The good news is that you don't have to take a turn in the oncall rotation or write thousands of lines of code to stay relevant. What you need is deliberate proximity... enough to maintain credibility and keep your decisions informed. Charity Majors calls this the "Architect-Engineer Pendulum": leaders should sort of swing back and forth between hands-on engineering work and architectural or strategic oversight, to ensure that they stay fluent in both practice and design.
The Pendulum doesn’t need to be 50/50 — in fact, I don’t believe it ever should be. Leaders should aim for around 5% hands-on work: enough to experience the impact of their decisions firsthand. The work they take on should be real, but it doesn't have to be critical-path. All you want to do is maintain a tether to reality, so you don’t end up in the ivory tower, drawing the ire of engineers for decisions that make their work harder.
The Journey of A Thousand Miles Begins With...
If our goal is deliberate proximity, here are some practical ideas you as a senior leader might consider as a way to tighten up your tether:
Shadow engineers in action – Sit in on a sprint, a support rotation, or a code review to see firsthand what challenges the team faces. This is a little bit hands-off, but it could be a starting point for you if it's been a long time since you broke out the old "Coding Gloves".
Grab a small spike off the board – Take on a focused experiment or mini-project to explore a system or workflow without derailing critical work. Most teams have things on their boards that are "too big for a story" but "too small for a formal project"... could be a good way to provide tangible benefit. Just don't do it in a vacuum; you don't want them to feel like you're micromanaging them!
Review runbooks and operational guides – Walk through the steps your team follows during incidents or deployments to understand real-world impact. The things they document heavily are indicators of pain... pay close attention to those!
Pick real, but non-critical work – Engage in tasks that produce tangible outcomes, but won’t block the team if you stumble. It’s the tether, not the production output, that matters.
These small, intentional moves keep you connected, preserve credibility, and prevent the slow drift from technologist to bureaucrat — all without turning your calendar into a second on-call rotation.
One Last Note
The title of this post asks an extremely pointed question:
Do You Even Belong In Tech Anymore?
The answer is always yes — as long as you don’t choose to remain disconnected from the technology you influence. Think of it like surgery: you don’t need to wield the scalpel every day, but you do need to know what it feels like to hold it. Staying connected is what keeps your decisions grounded, your credibility intact, and your influence meaningful.
Top comments (0)