As a manager of software teams, I’ve been asked many times about the transition from building software to managing the people who build it. It’s an existential question for a lot of engineers as they think about career growth: Do I become a manager, or do I stay technical?
That framing has always bothered me, because it assumes something I don’t believe to be true: that managing and continuing to develop technical depth are mutually exclusive.
It’s certainly possible to manage a software project with only surface-level technical knowledge. Plenty of organizations do exactly that. But in my experience, truly understanding the systems your engineers are working on is invaluable, both to the team and to the outcomes they deliver.
What Changes When You Become a Manager
The real shift isn’t from technical to non-technical. It’s a shift in how and where your technical skills are applied.
As an engineer, your leverage comes from the code you write. As a manager, your leverage comes from the decisions you enable, the risks you surface early, and the technical tradeoffs you help your team navigate.
That requires more than vocabulary-level familiarity. It requires enough depth to ask the right questions, recognize when complexity is creeping in, and understand when a problem is architectural versus organizational.
Why Technical Depth Still Matters
Teams know very quickly whether their manager actually understands the work. Not at the level of “could I implement this myself,” but at the level of “do you understand why this is hard, risky, or worth doing.”
Technical depth enables better judgment calls:
- When a deadline is unrealistic versus merely uncomfortable.
- When an incident is a one-off versus a systemic design issue.
- When adding people will help, and when it will slow everything down.
It also builds trust. Engineers are far more willing to accept hard tradeoffs when they believe those decisions are informed by real understanding rather than abstraction.
The False Choice
The idea that you must choose between management and technical growth is mostly a product of how organizations structure careers, not a law of nature.
Some managers stop developing technically because their role no longer demands it. Others continue learning because it makes them better at prioritization, architecture discussions, and long-term planning.
I’ve always believed that the best engineering leaders stay close enough to the technology to understand its constraints, even if they are no longer the primary authors of the code.
Where I Landed
For me, management was not a departure from engineering. It was an expansion of scope.
The tools changed. The feedback loops got longer. But the core skill, understanding complex systems and helping them work better, remained the same.
If you’re an engineer facing this decision, my advice is simple: don’t assume you’re choosing between people and technology. The best managers I’ve worked with never did.
NOTICE: The thoughts and statements in this article are mine alone and do not represent those of any past or present employer. This content reflects personal experience and opinion.