Moving Up Shouldn’t Mean Moving Away
How we confused career progression with technical distance and organizational size.

For a long time, career progression in engineering leadership followed a fairly predictable path. You started as an engineer, became a tech lead, moved into management, and slowly took on bigger teams and organizations.
At every step you were expected to spend less time on technology and more time on people, processes, budgets, and organizational complexity.
Somewhere along the way, we started treating technical distance as a sign of leadership maturity, and the size of your organization as a measure of how successful you were. I’ve been wondering whether we took both ideas too far.
When leadership meant stepping away
There were good reasons for this. Engineering managers had to learn to delegate, develop people, build good teams, and stop being the bottleneck for every technical decision. That’s all still part of the job.
But delegating technical decisions is not the same as losing touch with technology.
In some organizations, moving into management slowly meant nobody expected you to be technically involved anymore. The higher you went, the less your technical understanding seemed to matter.
That leaves us with a strange contradiction. We hold engineering leaders accountable for technology outcomes while pushing them further away from the technology behind those outcomes.
A leader doesn’t need to be the best engineer in the room, and shouldn’t be making every architecture decision. But they should understand the trade-offs, challenge assumptions, spot technical risks, and notice when technology could change how a problem gets solved.
Technical leadership isn’t about making every technical decision. It’s about having the judgment to make better decisions possible.
When bigger became better
At the same time, another assumption took hold: successful engineering leaders run ever larger organizations. More engineers, more teams, bigger budgets, more layers of management. That became the natural way to show you were moving up.
For years it made sense. Companies were growing fast, hiring was a competitive advantage, and coordinating large engineering teams took real leadership skill.
But the size of an organization and the impact of its leader aren’t the same thing.
If one leader helps 50 engineers achieve what used to take 100, is that a smaller achievement than growing a team from 50 to 100? It should depend on the value created, not on headcount.
With AI, that question matters even more. Teams are finding new ways to expand their capabilities without necessarily expanding their headcount. Whether that translates into greater value is another question, but it makes organizational size an even less reliable measure of leadership success.
Yet a lot of career structures still reward growth more visibly than effectiveness. Which makes me wonder whether we sometimes reward leaders for managing complexity instead of for reducing the need for it.
The rules are changing
I recently listened to Will Larson talk about how the unwritten rules of engineering management have changed since the 2010s. A lot of what he said matched questions I’d already been thinking about.
He describes a time when hiring and keeping engineers was a major competitive advantage, and engineering managers were often encouraged to stay out of technical decisions. That’s changing now.
AI is speeding this up, but I don’t think it explains everything. Economic pressure, different expectations from investors, and much better engineering tools are all pushing companies to rethink how they create value.
Hiring more people can no longer be the default answer to every capacity problem. And a leader who understands the technology has more options than one whose only tools are org charts, processes, and more headcount.
When leaders become disconnected from technology, they risk solving engineering problems with organizational solutions simply because those are the tools they know best.
AI also lowers the cost of staying technical. A manager can now explore an idea, make sense of code they didn’t write, or build a quick prototype in an afternoon. Staying technically engaged still takes effort, but AI is making it easier to remain curious, explore ideas, and understand the systems our teams are building.
It works the other way too. A leader who doesn’t understand AI will struggle to judge what their teams are doing with it. It gets hard to tell a real improvement from activity that only looks like progress, or to know where AI helps and where it just adds risk.
That doesn’t mean engineering managers should go back to writing code every day. It means staying technically relevant is becoming a bigger part of being a good engineering leader. Understanding new technologies, questioning how things are done today, and seeing where engineering work could be simpler are leadership skills now, not side interests.
Rethinking what career progression means
I think the biggest change is less about what engineering leaders do and more about how we define their success.
We shouldn’t have to choose between being a good leader and staying a good technologist. Developing people, building trust, creating autonomous teams, and understanding how organizations work still matter. So do technical judgment, curiosity, and knowing when a technical solution beats an organizational one.
We also need to stop thinking about engineering leaders primarily through their position in the organizational hierarchy. Leadership is still about building. What changes over time is what we build: first software, then teams, systems, and the conditions that allow others to do their best work.
I think the best engineering leaders never really stop being builders. They may spend less time writing code, but they don’t lose touch with the technology or the problems their teams are solving.
The leaders who matter most in the next few years may not be the ones running the biggest organizations. They’ll be the ones who can bring technology, people, and organizational design together to build teams that keep getting more capable.
That probably means rethinking a career model we’ve taken for granted for a long time.
Moving up shouldn’t mean you stop building. And success shouldn’t be measured by how many people report to you, but by what you help them build.