Vanta Logo
SPONSOR
Automate SOC 2 & ISO 27001 compliance with Vanta. Get $1,000 off.
Published
4 min read
Up to date

Trevor I. Lasn

Staff Software Engineer, Engineering Manager

Advice to New Engineering Managers

Tips for being an effective engineering leader and how to avoid common pitfalls

Engineering management requires a different mindset from software development. The skills that made you an excellent developer won’t necessarily make you an effective manager. Let’s explore what matters.

[1] This article is full of opinions and advice. Take what resonates with you and leave the rest. There’s no one-size-fits-all approach.

[2] I strongly believe engineer managers should code. It helps you understand your team’s work and provide technical guidance. But remember, your primary role is to lead, not to code. If an emergency arises, you can jump in, but don’t make it a habit.

You MUST learn how to delegate

The biggest mistake many new managers make is struggling with letting go of coding. I understand, it’s familiar territory and provides clear metrics of success. But holding onto only technical work creates bottlenecks and stunts team growth.

Here’s why delegation matters:

[1] When you delegate effectively, knowledge spreads across the team. This means no more emergency calls when you’re on vacation because you’re the only one who understands a critical system.

[2] Your team members gain confidence through hands-on experience. Letting them tackle challenging tasks - even if they might struggle initially - builds their problem-solving abilities. They learn to make decisions independently rather than always seeking your approval.

[3] You free up time for strategic work. As a manager, you need space to think about team direction, process improvements, and upcoming challenges. You can’t do this effectively if you’re constantly buried in code reviews or debugging sessions.

[4] Most importantly, delegation prevents you from becoming the bottleneck. Your team’s growth and velocity depend on their ability to move forward without waiting for your input on every decision. By holding onto too much technical work, you’re actually making your entire team less effective.

Here’s how to delegate in a way that works for software teams:

[1] Set clear boundaries and expectations up front. No engineer likes micromanagement or vague requirements. When delegating work, I make sure everyone knows: “Here’s what success looks like for this project” — Maybe it’s improved performance metrics, cleaner architecture, or specific user outcomes.

[2] Skip the fluff and be specific. “You have full autonomy on the technical approach, but let’s sync before making any changes to the public API” - define where they can move fast and where they need to slow down for alignment. “I’d like updates in our weekly 1:1s, but ping me earlier if you hit any blockers” - clear communication patterns prevent anxiety on both sides.

[3] Connect work to growth. Pay attention to what lights up your engineers in 1:1s. When someone’s excited about learning Rust, look for opportunities in upcoming projects. If they’re curious about system design, hand them the reins on architecting that new service. Let them own technical decisions - even if you would have done it differently.

[4] Accept that others will do things differently. Your way isn’t the only way to solve problems. Give people room to find their own solutions, even if they differ from your approach. This builds confidence and encourages innovation.

High-performing teams require psychological safety

Innovation dies in toxic environments. If your engineers fear criticism, mockery, or blame, they’ll stick to safe choices. They’ll avoid suggesting new approaches or pointing out potential issues.

A thriving team has an environment where it’s safe to:

  • Question existing approaches and suggest improvements
  • Admit knowledge gaps
  • Surface potential problems early
  • Try new technologies
  • Share half-formed ideas

When someone raises a concern in your architecture review, thank them for speaking up. When a junior engineer admits they don’t understand part of the system, treat it as an opportunity to improve documentation.

When a deployment goes wrong, focus on improving the system rather than finding someone to blame. Safety nets aren’t just about preventing mistakes; they’re about creating a culture where people feel comfortable taking risks and learning from failures.

Watch out for subtle behaviors that kill psychological safety:

  • Interrupting or talking over people in meetings
  • Dismissing ideas without discussion
  • Responding to questions with “that’s obvious” or “everybody knows that”
  • Making technical disagreements personal
  • Allowing “brilliant jerk” behavior because someone is technically strong

Good ideas can come from anywhere. That new grad might spot a critical flaw in your architecture. That quiet engineer might have the perfect solution to your scaling problem. But you’ll never hear these insights if people don’t feel safe speaking up.

If you found this article helpful, you might enjoy my free newsletter. I share developer tips and insights to help you grow your skills and career.


More Articles You Might Enjoy

If you enjoyed this article, you might find these related pieces interesting as well. If you like what I have to say, please check out the sponsors who are supporting me. Much appreciated!

Leadership
4 min read

Users Can Be Fired

Letting go of difficult or harmful users can be the key to maintaining the health and growth of your product

Sep 19, 2024
Read article
Leadership
4 min read

Write Documentation Like a Journalist

Create comprehensive, engaging documentation by adopting journalistic techniques for research and storytelling

Sep 26, 2024
Read article
Leadership
3 min read

Engineering Managers Should Write Code

Engineering managers who stop writing code lose touch with their teams and become ineffective leaders

Sep 18, 2024
Read article
Leadership
6 min read

The Monday Morning Test to Measure Engineering Team Health

Why the first day back can reveal everything about your engineering team's health

Nov 4, 2024
Read article
Leadership
4 min read

It's More Fun to Be Competent

Once you're competent, everything changes. You stop second-guessing yourself. You stop panicking every time you encounter a new problem. And you start taking on bigger challenges with excitement rather than dread.

Sep 20, 2024
Read article
Leadership
3 min read

Code Wins Arguments

How Meta and other companies use the 'code wins arguments' mindset to turn ideas into reality

Sep 19, 2024
Read article
Leadership
5 min read

Company Culture Happens Outside Management

Why real company culture grows from the ground up, not top down.

Sep 14, 2024
Read article
Leadership
7 min read

Technical Debt Is Killing Your Business

And it will be your downfall if you choose to ignore it

Jul 31, 2024
Read article
Leadership
4 min read

Make It Work First Before Optimizing

Users don't care how elegant your code is. They care if it solves their problem.

Sep 27, 2024
Read article

Become a better engineer

Here are engineering resources I've personally vetted and use. They focus on skills you'll actually need to build and scale real projects - the kind of experience that gets you hired or promoted.

Many companies have a fixed annual stipend per engineer (e.g. $2,000) for use towards learning resources. If your company offers this stipend, you can forward them your invoices directly for reimbursement. By using my affiliate links, you support my work and get a discount at the same!


This article was originally published on https://www.trevorlasn.com/blog/advice-to-new-engineering-managers. It was written by a human and polished using grammar tools for clarity.