The Manager's Paradox

There's a common piece of career advice given to new engineering managers: stop being an engineer. Step back from the technical details. Focus on people and process. Let your team do the building.

It's wrong. Or at least, it's incomplete in a way that produces a specific kind of organizational failure — and I've watched it play out enough times to take it seriously.

I've spent years managing engineering teams across SurveyMonkey, McAfee, and Philips — and before that, a decade growing from individual contributor to architect to manager at Intel. The transition from builder to leader is real, and it is genuinely significant. But the idea that you leave technical thinking behind is a misreading of what technical thinking actually is at the leadership level.

What "technical" really means at the leadership level

When people say engineering managers should "stay technical," they usually mean one of two things — both of which are slightly wrong.

The first interpretation: managers should still be able to write code. This is often misguided. It can create bottlenecks, undermine the team's ownership, and send confusing signals about where accountability sits. A manager who is also the best engineer in the room frequently prevents the team from growing into the space where they should be operating.

The second interpretation: managers should be able to review technical decisions. Better, but still incomplete. This positions the manager as a gate or a judge, which creates a different problem: teams that optimize for leadership approval rather than engineering correctness.

The right interpretation is something else entirely: managers should be able to ask the questions that surface the hidden assumptions in a technical decision. That requires deep technical fluency — but it looks different from individual contribution. It looks like asking: "What does this system assume about the volume of data in three years?" or "What happens to this architecture when we add the next two product lines?" or "Why are we solving this problem at this layer of the stack?"

These questions don't require writing code. They require having written enough code — and having seen enough systems succeed and fail — to know which questions are worth asking.

The danger of abstraction

Here's the failure mode I've watched play out in organizations: as leaders get more senior, they become more abstract. They talk about strategy and alignment and organizational health. They attend fewer technical reviews. They rely more heavily on second-order information — what their engineers tell them, what the metrics show, what the product managers report.

None of this is inherently wrong. But there's a cost, and the cost is judgment.

Judgment — the ability to sense when something is off — when the "this is technically feasible" answer is technically true but practically false, when the timeline estimate reflects optimism rather than analysis, when the architecture decision is driven by team familiarity rather than genuine fit — doesn't come from reading dashboards. It comes from having been close enough to the problem, recently enough, to feel its texture.

That kind of judgment atrophies if you don't actively maintain it. I've seen senior engineering leaders lose their ability to detect when they're being told a comfortable story instead of an accurate one, simply because they stopped spending time close to the work.

What staying close actually looks like

During my time at McAfee, I made a deliberate choice to stay involved in architectural discussions — not as a decision-maker, but as a thinking partner. I'd sit in design reviews not to approve or reject, but to ask questions. The questions that emerged from my own experience — having built privacy pipelines, having debugged NLP models, having shipped features into a security product used by millions of people — were different from the questions a generalist leader would ask.

That difference mattered. Not every week, and not in ways that made it into any project documentation. But at the critical junctures — when a decision would shape the system for the next two or three years — it mattered significantly. The team could tell when a question came from genuine technical intuition versus managerial concern about delivery timelines. The distinction affected how the conversation went.

At Philips, staying close meant something different: immersing myself in the user context. Radiologists are expert users with highly developed workflows. Understanding their environment — the pressure they're under, the cognitive load of reviewing large study queues, how they think about the information our software surfaced — wasn't optional for building good tools. It required time that could easily have been spent on stakeholder reports and roadmap reviews. I chose the user context. Those choices added up.

The culture signal

There's another reason engineering leaders should stay close to the problem: it signals what the culture values.

When a manager asks thoughtful technical questions, the team understands that technical thinking is valued all the way up the organizational chain. When a manager is visibly curious about how a problem is being solved — not just whether it's being solved — it creates a different environment than one where managers focus exclusively on delivery status and headcount allocation.

The culture of an engineering organization is set not by values statements or all-hands presentations, but by what leaders pay attention to, what they ask about, and what they celebrate. I've watched teams transform when they saw their manager genuinely engaged with the technical work — not to control it, but to understand it. The conversation shifts from status reporting to problem-solving. Engineers stop translating their thinking into non-technical language for leadership, because leadership meets them partway.

That shift is subtle. But it compounds over time into something significant: a team that communicates more honestly, surfaces problems earlier, and trusts leadership's judgment when hard decisions have to be made.

The trap of your own expertise

There's a harder version of this that I've had to reckon with personally: staying close to the problem doesn't mean staying attached to your own expertise.

For the first several years of management, I was largely operating in the domain I knew best — Windows security, C# and .NET systems, the architecture patterns I'd honed at Intel. My "staying close" was, in retrospect, staying close to familiar territory. It felt like technical rigor. It was partly intellectual comfort.

Moving into new domains — healthcare AI at Philips, Go-based backend systems at McAfee, Python and cloud-native architectures at SurveyMonkey — required a different kind of humility. I couldn't rely on domain expertise. I had to rely on first principles, on asking better questions, on trusting the judgment of people who knew things I didn't while maintaining enough fluency to recognize when their reasoning had significant gaps.

That's the real skill. Not knowing the answer, but knowing how to help the team find it. Not having the expertise, but having the judgment to recognize good thinking when you see it — and to sense, without always being able to articulate why, when something is being papered over.

What I've learned

The manager's paradox is this: the further you move from individual technical contribution, the more important your technical judgment becomes. Not your expertise — your judgment.

Expertise is perishable. The frameworks I knew intimately in 2010 are legacy systems today. The architecture patterns I pioneered at Intel are now textbook material, applied by engineers half my age. My knowledge of specific technologies has a shelf life.

Judgment is different. The accumulated pattern-matching from having built many systems, led many teams through difficult decisions, and watched many architectural choices play out across years rather than sprints — that doesn't expire. It compounds.

The work of a senior engineering leader is to make that judgment available to the organization. Not as a bottleneck, not as an approver, but as a thinking partner who asks the questions that others haven't thought to ask yet — and who has earned the credibility, through years of being close to the work, to be trusted when they do.

That's the job. It requires staying close to the problem, even as you step back from the solution.