I did not use AI to write or review this. These are my own half-baked thoughts.
EMs own their team’s software development process.
EMs own the quality of their teams’ output.
EMs are responsible for ensuring the team works efficiently.
EMs are accountable to commitments and estimates.
From these responsibilities emerge opportunities to apply technical expertise.
This diagram applies to Engineering Managers, too.
EMs own their team’s software development process
- You have to know where the bottlenecks are at every step in the software lifecycle. This means being able to dive deep into any step and critique it, including code reviews, implementation, design, testing, and being able to coach the team on how to discover bottlenecks themselves. You can delegate some of this work to others, but you still have to "trust but verify": know which questions to ask, know what/when to delegate, know which battles to pick, and know when to roll up your sleeves and explore hands-on. Going through the team's software process yourself helps you empathize and lead more effectively.
EMs own the quality of their teams’ output
- You are the "QA Manager" on your team.
- You are responsible for ensuring that the team builds quality into the product starting with early design and requirements gathering.
- You ensure the team adheres to the processes, practices, and architectures that they agree to. You can delegate this to some degree, but you should audit it from time to time.
- You'll delegate a lot of testing to the team, but take time to test some features yourself (black-box and white-box testing). Your team gets the credit for the successes, you assume responsibility for the failures.
- You are the "PM" of observability. Use Datadog and Cloudwatch, query databases, know the main failure points and interface boundaries, use monitoring tools, narrow down answers empirically by trying things in the product. Offer and prioritize suggestions for improvement to observability tools, consider offering small PRs from time to time.
EMs are responsible for ensuring the team works efficiently.
- You assess individual contributors' performance. How much are they producing compared to your technical understanding of and expectations for the work? You can rely on peers for this and you should be able to assess it to some degree yourself. Study their technical contributions and approaches.
- Coaching is a part of management. You have to challenge and motivate engineers. You can choose to delegate some of the technical coaching to engineers, but then you still have to coach engineers how to coach. This requires some level of technical proficiency.
- You meet 1:1 with engineers weekly. You're in daily standups, reading code, testing the product, responding to product questions, reviewing architecture documents, refining Jira tickets. These activities enable you to spread knowledge, connect dots, load balance, provide coverage, challenge scope, find bottlenecks, give feedback, coach, and lead more effectively. All of this helps the team work more efficiently.
- By understanding the technical domain, you can offer ideas and constraints of your own to foster innovation. Delegating is not enough. In your role as manager you have a breadth of context that makes your own ideas uniquely valuable. Try designing solutions yourself internally, observe what the team comes up with, and use the delta to challenge assumptions and approaches.
- Interruptions and context switching drain engineers' productivity. As a manager, you can context switch so that engineers can stay focused. By taking on initial incident triage and early ticket refinement, you can help prioritize and prepare work so that when engineers switch to it they have enough context to act.
- Occasionally, you should be able to review a PR, or add a unit test for a bug, or write a small utility to help the team out. But keep in mind that you will be context switching away in a few minutes, so don't sign up to write production code that's on a time-sensitive, critical path.
- You can be the "developer of last resort" to pitch in on small areas or unblock in unusual circumstances. But do this sparingly; if you’re doing it too much there’s an imbalance you should address somewhere else.
- Spread technical knowledge across teams to boost the broader org’s efficiency.
EMs are accountable to commitments and estimates.
- You're the General Contractor. You need to know when an estimate is too high or too low based on your aligned understanding of the problem. Sometimes this requires asking hard technical questions and prompting for alternative solutions. Story pointing exercises and crowd-sourcing estimates help, and you should have an opinion yourself. Be able to challenge the wisdom of the crowd when appropriate.
- You need to be able to speak to the engineering team's estimates confidently when asked. You can delegate the finer details, but you should still have a grasp of the bigger picture to facilitate conversations and unblock progress. Follow your own technical curiosity and doubt.
- You need to be able to provide rough swag estimates and details about the "how" to speed up initial discovery/sizing/prioritization. You need to know when it's appropriate to provide a swag, and when the cost is justified to delegate swag estimation to someone else.
Balance in All Things
Some will say that as a manager you can take on tasks to "shield" the team. This is OK to some extent, but beware of taking it too far. The team needs to be part of product feedback loops to understand the impact of their work on customers. Contain fires, create optionality, reduce frequent context switching for engineers. But don't insulate the team.
Conclusion
Roll up your sleeves, learn the code, review PRs, write unit tests, code some experiments, architect solutions, use Datadog, diagnose bugs, share technical opinions, question the details, fix documentation, pitch in on the line, deploy to prod.
Your team will be more efficient, produce a higher quality output, have a higher likelihood of achieving their commitments, and be more innovative, motivated, and inspired when you embrace the technical domain in moderation. Remember that part of your job is to context switch and keep an eye on the big picture. Don’t let your technical ambitions block critical paths.