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.
