Prologue
So you made it through the Tech Lead phase, nice job! Maybe it felt like you’d finally learned how to juggle chainsaws and not lose a limb. You handled tricky code reviews, tight deadlines, and got your team working together without too much drama. Now it’s time for the next challenge: becoming an Engineering Manager (EM).
This is where the job description adds a friendly, invisible disclaimer: WARNING: This Role Contains More Humans Than Code. As a Tech Lead, you got a small taste of people management. But as EM, you’re stepping into a bigger world: less time in your code editor, more time talking, listening, and helping people grow.
Before start, I will suggest to look at these posts Charting Your Path Beyond the Code and Stories behind “Charting Your Path Beyond the Code”. It will build more context for this one.
Act 1: Broader Horizons
As an Engineering Manager, you still care about architecture and code quality, just don’t expect to do all the coding yourself. Your main mission: create an environment where your engineers feel supported, can tackle tough problems, and come out smiling (most days, anyway).
I remember, I tried to keep coding just as much. I thought I could manage people and still commit a bunch of PRs every week. Guess what happened? I got behind on my 1:1s, communication suffered, and I missed clues that one dev was feeling totally burned out. After that, I learned to put the team’s needs first. Turns out, giving them the spotlight makes them stronger, and frees you up to help in more meaningful ways.
Shift from Doing to Enabling
You’ll write fewer lines of code, but have a bigger impact. Instead of fixing every bug yourself, you’ll guide your engineers to find their own solutions. Think of it like being a soccer coach rather than the star player. You’re making sure the team is set up to win, not scoring all the goals by yourself.
Communication is Key (No, Seriously)
Some engineers will tell you exactly what’s wrong. Others will be quieter than a powered-down server. As an EM, you’ll learn to listen for what’s not being said. Create safe spaces, be patient, and show you care.
I remember one time when a developer who never raised any issues suddenly quit. I tried to get to the bottom of it, but he was already mentally checked out. At first, I didn’t understand, he’d received raises, worked on interesting tasks, and seemed happy enough. It wasn’t until after he left that I realized the issue.
That experience hit me hard. I realized I needed to make 1:1s more relaxed, honest, and intentional. It’s amazing how much you can prevent with open, judgment-free conversations. And yes, you’re probably still wondering what went wrong with that guy. Turns out, he wanted to pursue a completely different path in his career, but he never mentioned it, and I never caught it.
Since then, I’ve made it a point during one-on-ones to ask questions like: “Do you feel like you’re on the right path?” or “Would you like to explore another role, frontend, backend, DevOps, or something else entirely?” It’s a simple addition, but it has made a world of difference in helping my team feel heard and supported.
And, as I’ve said before, one-on-ones are a whole topic in themselves. Maybe in the future, I’ll write about that in a more dedicated manner too.
Act 2: The Wild World of Stakeholders
You’re not just dealing with your team anymore. Product managers, HR folks, other department heads, they all want a piece of your time. Think of it like being the director of a theater production. You’ve got actors (your team), stage crew (HR), scriptwriters (product managers), and producers (upper management), all with their own priorities and demands. The actors need clear direction, the crew wants to ensure everything runs smoothly, the scriptwriters are pushing their vision, and the producers are focused on the budget and audience reception. Your role is to coordinate all these moving parts, ensure everyone stays aligned, and keep the production on track, while also onboarding new cast and crew members seamlessly into the mix. It’s about managing expectations, resolving conflicts, and bringing diverse goals together into one successful performance.(I really out done my self with this example)
I remember a product manager who wanted a major new feature built “yesterday.” (oh I hate this phrase btw) Meanwhile, the team was still struggling with performance issues on existing features. By calmly explaining or better communicating the trade-offs and showing some quick data (like the current bug counts and capacity), we found a compromise that didn’t burn everyone out and pushed the release date further. A little transparency and empathy can go a long way.
Learn to Speak “Business” and “Engineer”
You’re the translator now. Business talks in Cha-Ching, you know? Money, and timelines; engineers talk in tickets, complexity and technology. Your job is to make sure both sides understand each other without rolling their eyes too hard. If you can keep everyone aligned, you reduce pointless debates and nightmares.
Prioritize Like a Pro
You can’t say yes to everything. Sometimes, you’ll have to tell the product team, “Not this sprint,” and back it up with reasons. Or you might have to let your engineers know that they can’t refactor half the codebase right now. By focusing on what truly matters, you help the team deliver consistently without burnout. Less chaos, more actual progress.
I remember one time when a product manager approached me with an urgent feature request. The team was already stretched thin, so I had to say, “Not this sprint.” They weren’t happy and escalated the issue, insisting it was critical for an upcoming launch. On top of that, it was tied to a government regulation, and skipping it could mean missing a massive growth opportunity for the company.
“OK, let me see” I said. Instead of leaving it at a no, I set up a meeting with the PM, Architect and the team to revisit the request. (Spoiler: the team wasn’t happy about the situation either, so tensions were already high.) After hashing it out, we realized we didn’t need the full feature, just a much simplified version to meet the immediate requirements for the launch. By reassigning a few tasks, temporarily shifting some engineers, and delaying a less critical refactor and some projects, we made room to deliver the essentials on time.
The PM got what they needed, and while the team did feel a bit of pressure, we avoided burnout and safeguarded the company’s future. It was a great reminder that saying no doesn’t have to be the end of the conversation, it’s often the beginning of finding a better solution.
Act 3: Career Counselor and Culture Builder
Your job now includes helping your engineers grow, not just in technical skills, but in their careers. That might mean suggesting a conference to attend, sharing books that inspired you, or simply talking through their long-term goals.
I remember one engineer who was on the fence about moving from Frontend to Backend. After a few chats, we reached out to a team working on a related project and asked if they could share their work with her. She started sitting in on their meetings and contributing to smaller tasks. You want me to say: “A year later, she thrived as a Backend Leader, taking on multiple projects and driving real impact.” Right? But here’s the twist, she discovered a passion for Data Engineering after a month or two. At the end of that year, she was designing models and loving it. The thing is, helping people find their path is incredibly rewarding. It’s not about walking the path for them or pushing them in a direction, it’s about showing them the options and being there to support them as they explore. When you see someone thrive because you gave them space and encouragement, it’s the best feeling ever.
One important thing to mention here is that you need to remember these are also resources the company is investing in. In my case, she was successful in all the positions she moved through and completed her tasks well, but she wasn’t fully satisfied until she found her true calling. What I’m saying is that you need to be vigilant about these transitions to avoid wasting time or resources. It’s all about finding the right fit quickly, so remember to fail fast and adjust as needed.
Feedback Early and Often
Don’t wait for some “performance review” months away. If something’s off, talk about it now and in private. Also, remember to call out good work in public if possible. Positive feedback can be a huge morale booster. I once saw a developer beam for hours after I publicly thanked them in a team meeting for refactoring a tricky chunk of code. A little kindness goes a long way.
Roll with the Punches
Change happens, priorities shift, top engineers leave, new hires join mid-sprint. It’s okay. The best EMs adapt and keep everyone calm. Once, we lost two senior devs right before a release. I panicked could not sleep that night thinking how can I do this, I sat with team and other EMs and talk about how we can rearrange the workload to buy time till we can find replacements, and everyone chipped in. We got through it and even learned how to handle chaos more gracefully next time.
Finale
Becoming an Engineering Manager is about seeing the bigger picture. It’s not just about the code, it’s about the people writing it and about people wanting those code to be written. The challenges will be different, messier, and more human. But helping your team grow and succeed is worth every awkward conversation and tricky meeting.
I always have this in my head from Archibald Wheeler about Einstein’s work: “There were three additional rules of Einstein’s work that stand out for use in our science, our problems, and our times. First, out of clutter find simplicity. Second, from discord make harmony. Third, in the middle of difficulty lies opportunity.”
For now, enjoy this phase. Embrace the humans, the chaos, the learning. That’s what being an EM is all about.