Should an engineering manager code?
You may wonder if an engineering manager (particularly those who manage a single team) should contribute code. At some companies, there is an expectation that managers should continue to contribute to the codebase in addition to their other people manager responsibilities. This expectation is particular to different company cultures and not universal.
There are 4 main value propositions for why a manager should code. Let’s explore each of them.
- “It keeps me close to the craft. I need to maintain my technical skills”
- “It helps the team deliver”
- “It builds empathy for the day-to-day of my team”
- “I need to set an example for my team”
How will I maintain my technical skills as a people manager?
A common concern that comes up among engineering team managers, especially new managers, is “How will I maintain my technical skills?” The fear driving this is that we will lose our ability to code and, more critically, our credibility. Our credibility does not (and should not) hinge on our code production. The role of an engineering team manager is to make sure the right people are shipping the right thing at the right time.
It is important to remember that technical skills include more than the ability to write code. This is why coding is just a portion of a technical interview loop. Technical skills include the ability to make critical choices about technology and architecture and then the ability to communicate effectively about why those choices are reasonable. In fact, at Amazon, what distinguishes engineers from senior engineers is not their coding ability, but their problem-solving ability. Can you navigate ambiguous requirements? Can you break down complex problems into smaller ones?
A people manager’s core technical functions are to
- Coach engineers in their technical growth
- Audit the team’s technical choices
- Ensure the right tradeoffs are being considered. Understand what’s an “implementation detail” vs what will have consequences
- Balance technical investment/debt management
- Understand the engineering effort required and evaluated the complexity of design/implementation
- Understand the impact of choices on Latency
- Understand the impact of choices at Scale
- Understand the impact of choice on the user experience
Coding helps the team deliver. What should managers deliver?
I challenge this idea. Teams should be able to deliver code without their manager stepping in to speed up the process.
The day to day of a software engineering manager focuses on delivering through the team. Not only do most managers not have the time to code, it is not the most impactful use of their time. As a people manager, it is no longer your job responsibility to ship code for the product. Managers serve a key function on the team which functions in conjunction with the engineers: they are responsible for the delivery and decisions of the team. They are responsible for the code delivered, its quality, and its functionality.
Be wary of being a manager the team depends on for key technical decisions. A team with extreme dependency on a manager for all its technical decisions operates in a failure mode. I witnessed this once, as a dependency team trying to interface with a team’s services. The engineers were unable to answer detailed questions about their services with confidence independently. The team required their manager in every meeting.
Build empathy for engineers
This is a good reason to get into the codebase as an engineering manager. The intention is always in service of how to help the team deliver better. At a minimum Engineering managers should
- Have their teams core codebases on their local machine
- Build/Run their teams core codebases
- Know how to use the key tools your team depends on day to day
I would encourage managers to do this as part of their onboarding to a new team. I would encourage them to revisit this activity at least once a year. As a manager, a key concern should be how the team is spending time and if that time is effective. If the team spends an inordinate amount of time fighting the tools, the deployment pipelines and the build systems then these are blocking problems you need to know about.
Taking time to live in the shoes of my team has helped me uncover problems in workflows that are blocking my team. For example ““why does it take so long to ship an approved code review to production?” Further digging led me to discover that our pipelines were very flakey. I advocated for a small team to be put together to address the problems over the course of a month and reduce the build times by at least half and prevent engineers from needing to hit retry on tests every build.
Building empathy for engineers does not mean a manager should own and ship bugs or features. A good opportunity to get in the code and try things out is during hack days (if that is a part of your company culture)
I need to set an example for my team
It is true that managers set the culture for the team. Doing an engineer’s job alongside them is not the same as coaching. As a people manager, these are activities that you should do regularly and coach with your team.
- Read code reviews
- Review and respond to technical designs
- Pair with my team on coding and technical writing
- Audit the team’s work breakdowns and task issues
As an alternative to being the example themselves, managers should coach the senior members of the team in leadership skills. Coach them to become mentors and set an example for the team. Find opportunities for engineers to be a mentor and a mentee. Help build relationships between your team members.
Should an engineering manager code?
No.
They should not own features. They should not be expected to ship on any regular cadence.
They should stay technical but coding is not the way to demonstrate technical credibility.
They should know the tools the team uses. They should know how to run the team’s code.
