courses.reviews logo
I launched a free website to help you find the best courses with reviews & discounts.
Up to date
Published
4 min read

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.


Found this article helpful? You might enjoy my free newsletter. I share dev tips and insights to help you grow your coding skills and advance your tech career.

Interested in supporting this blog in exchange for a shoutout? Get in touch.


Liked this post?

Check out these related articles that might be useful for you. They cover similar topics and provide additional insights.

Reflections
7 min read

The Real Cost of Meetings: What FAANG Companies Do Differently

Discover how FAANG companies like Amazon, Google, and Netflix reduce the hidden costs of meetings by embracing written communication and minimizing unnecessary gatherings.

Sep 17, 2024
Read article
Reflections
3 min read

Barnacle Strategy for Startups

As a founder, you're always on the lookout for smart ways to grow your startup without burning through your limited resources. That's where the barnacle strategy comes in.

Oct 3, 2024
Read article
Reflections
2 min read

Don't bullshit

Be the authentic voice in a world of manufactured personas

Feb 12, 2025
Read article
Reflections
3 min read

When Tasked with a Problem, Start with the Bigger Picture

When faced with a challenge, I always step back to see the whole picture first. It's like pausing a complex strategy game to study the map. You might lose a few seconds of play time, but you gain a crucial understanding of the battlefield.

Oct 3, 2024
Read article
Reflections
7 min read

Evolve or Become Irrelevant

Why staying relevant in tech means constantly adapting to new technologies and trends

Sep 15, 2024
Read article
Reflections
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
Reflections
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
Reflections
4 min read

Unrealistic Deadlines In Software Engineering

Unrealistic deadlines are more than just stressful—they set engineers up for failure

Sep 7, 2024
Read article
Reflections
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

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.