Skip to main content
  1. Posts/

Three Things to Focus on as a New Engineering Manager

· loading · loading ·
Jared Lynskey
Author
Jared Lynskey
Emerging leader and software engineer based in Seoul, South Korea

When you start as a new engineering manager, everything feels urgent. Here are three things worth prioritizing first.

Get to know your team
#

Schedule 1:1s with everyone. Ask about their career goals, what frustrates them, and what they wish was different. Listen more than you talk. You’re building trust, and that takes time.

Everyone works differently. Some people want detailed direction. Others want you to get out of their way. Figure out which is which early. Camille Fournier’s “The Manager’s Path” covers this well—empathy and active listening are the foundation of good management.

Learn the company context
#

Understand why things are the way they are. What’s been tried before? What failed? What does the company actually care about?

Every company has unwritten rules about how decisions get made. The faster you learn these, the more effective you’ll be at getting things done for your team. Andrew Grove’s “High Output Management” makes a good point here: you need to understand the bigger picture before you can align your team’s work with it.

Understand the codebase
#

You don’t need to be the best coder on the team, but you should understand the architecture, the pain points, and the technical debt. Read the code. Look at the deployment pipeline. Ask your team what they’d fix if they had a free week.

This does two things: it gives you the context to make good technical decisions, and it shows your team you care about their work, not just the process around it.

Trust your developers
#

Once you’ve built that foundation, the most important thing is to get out of the way. Set context, share goals, and let your team make technical decisions. Your job isn’t to approve every PR—it’s to make sure the team has what they need and is pointed in the right direction.

“The Phoenix Project” by Gene Kim reinforces this: teams that own their decisions move faster and build better software than teams waiting for approval from above.