The Transition From Code to Management
Ten years. That's how long it takes to truly understand a job. An engineering manager just shared their assessment after a decade in this role, and their observations run counter to many received ideas in the tech industry.
The initial observation is brutal: the transition from developer to manager is one of the most poorly prepared in the industry. We promote the best coders to positions where code becomes secondary, with no real training for the new job.
Technical Competence: Necessary But Insufficient
First myth to deconstruct: the technical manager must remain a technical expert. This is true... and false.
Yes, understanding code, architecture, and technical choices remains essential. Without this understanding, it's impossible to properly evaluate work, challenge estimates, or spot early signals of accumulating technical debt.
But the trap is staying too technical. The manager who continues coding "to stay relevant" often creates more problems than they solve. They become a bottleneck on code reviews. They make technical decisions without the complete context. They signal that only code matters.
A manager's real technical skill is knowing when to get into details and when to trust their team.
People, Not Processes
Second counterintuitive lesson: processes matter less than people.
The industry is obsessed with methodologies. Scrum, Kanban, SAFe, Shape Upāthe variants are endless. Agile consultants make fortunes selling frameworks.
The reality after 10 years: a team of competent, motivated people with a broken process will produce better results than a mediocre team with a perfect process.
This doesn't mean processes are useless. They create a framework, habits, predictability. But they cannot compensate for fundamental human problems: bad hiring, lack of trust, unclear objectives, toxic culture.
Time spent perfecting processes would often be better invested in recruiting, individual coaching, and building a healthy team culture.
Recruiting Is Your Main Job
If you're an engineering manager who thinks recruiting is "HR's job with a bit of help from you," you've got it wrong.
Recruiting is probably the highest-impact decision you'll make. A good hire can transform a team. A bad hire can destroy it. The effects are felt for years.
After 10 years, the conclusion is clear: spend more time on recruiting than you think necessary. Refine your criteria. Develop your ability to evaluate soft skills, not just technical abilities. Learn to identify subtle red flags.
And above all: don't compromise due to urgency. A position vacant for three extra months costs less than a bad hire who stays for two years.
Managing Up
New managers focus on managing their team. Experienced managers understand that managing up is equally crucial.
"Managing up" doesn't mean politics or flattery. It means: communicating effectively with your hierarchy, anticipating their information needs, protecting your team from erratic directional changes, negotiating necessary resources.
Your team depends on your ability to navigate the organization. If you don't know how to influence decisions above you, you can't create success conditions for your team.
This aspect is often ignored in management training, which focuses on top-down "leadership."
Difficult Feedback
Giving negative feedback is uncomfortable. The temptation is to avoid it, dilute it, postpone it.
After 10 years, the main regret: not giving that feedback earlier and more directly. Every time a performance issue was left unaddressed for months, the situation deteriorated.
Difficult feedback given early, with empathy but clarity, is a gift. It gives the person a chance to improve. Absence of feedback is a form of disrespect: it deprives the person of crucial information about their performance.
The key is separating behavior from the person. It's not "you're incompetent," it's "on this project, deadlines weren't met and here are the impacts."
Exhaustion Is Real
Burnout in technical management is endemic and under-discussed. You absorb your team's stress, you're responsible for results you don't directly control, you juggle contradictory demands.
After 10 years, the hard-learned lesson: your professional durability depends on your ability to set boundaries. Not symbolic boundariesāreal ones.
This includes: saying no to unrealistic projects, protecting your personal time, developing systems to delegate effectively, and accepting that perfection is impossible.
Managers who last aren't those who work the most, but those who work sustainably.
The Impact Question
The recurring frustration of managers: you no longer produce anything tangible. No code committed, no feature shipped. Your impact is indirect, often invisible.
This is a difficult psychological adjustment for someone coming from development, where feedback is immediate (code compiles or not, tests pass or not).
After 10 years, the reconciliation: impact is measured differently. A team that works well, delivers regularly, remains stableāthat's your work. The careers you helped build, the difficult decisions you made, the crises you managed without anyone knowing.
It's less visible than a commit. It's potentially more impactful.
Conclusion
Technical management isn't a promotionāit's a career change. The skills that made you a good developer won't automatically make you a good manager.
After 10 years, the main advice: treat this role with the seriousness of a new job to learn. Read, get training, find mentors, accept that you'll make mistakes.
And if after a few years you realize it's not for you, returning to individual contributor isn't failure. It's a rational career decision. The industry needs excellent developers as much as excellent managers.