When Should Engineering Managers Write Code?

When great engineers show signs of being great leaders too, they’re often promoted into engineering manager roles. In these roles, they get to practice people skills and business skills like scheduling, managing budgets, hiring, communicating team updates, and empowering individual team members to also grow in their careers.

But with all these new responsibilities, does that mean an engineering manager now has to leave their old skills behind? In this new role, can they continue coding?

While these managers won’t be able to do as much as they used to, there are some opportunities when they’ll still be able to make use of the tactical coding side of their brain. 

• What is writing code?
• Engineering manager roles and responsibilities
• When is it okay for engineering managers to write code?
• Benefits of engineering managers writing code
• When should engineering managers not write code?
• Why engineering managers want to write code

What is writing code?

Writing code, coding, programming—it all means the same thing. 

Coding is the practice of building a software application or tool. It’s done through writing code using a specific coding language on a specified framework. Some of the most common languages today are Python, Java, PHP, C#, and Go, among others. 

Engineering managers usually get into their roles by being great coders, to begin with, meaning that they’ve had extensive experience working on software and web development projects, likely with a wide variety of coding languages. 

Engineering manager roles and responsibilities 

Once moved into a managerial role, the general day-to-day responsibilities shift a lot. Instead of spending the day coding, engineering managers need to shift their mindsets to become more people and business oriented. This means typical roles and responsibilities of an engineering manager include:

• Designing and optimizing processes for building, testing, and deploying code
• Assigning tasks to technical team members
• Estimating, gaining approvals, and ensuring sufficient resources are in place to ensure the project continues on schedule and on/under budget
• Being the middleman to communicate requirements and status updates between technical and non-technical stakeholders in the project
• Collaborating on cross-departmental projects, presentations, and meetings

When is it okay for engineering managers to write code? 

• Fixing bugs
• Unit testing
• Code reviewing
• Code monitoring
• Onboarding

1 Fixing bugs

If there are a few quick bugs in the latest deployment, go for it. Since some bugs can take a lot longer to patch than others, it’s best to have the manager pop in only when these are quick fixes that won’t take a considerable amount of time (that is, they’ll take half a day or less). If the team manager can help take care of these small patches, it allows the team’s developers to spend more time in deep focus mode to build new features.

2 Unit testing

Unit testing is an approach in software development teams where smaller sections of code (units) are checked as the larger set of code is being written. Generally, the smaller unit tests are, the better—smaller unit tests can be done more quickly and more frequently across the full set of source code. 

Engineering managers can support unit testing and write code on small fixes that they come across. Having this in the process means that the developers don’t need to do half their work for minor fixes. Instead, the small fix can be applied, the manager can communicate the change to the developers, and the whole team can continue moving forward with the project.

3 Code reviewing

Conducting a code review, similar to unit testing, is another way to check the code for bugs before it’s released to production. However, code review is slightly different in that teams (usually of two) will take turns reading each other’s code to ensure quality. If you find yourself in a temporary situation with an odd number of developers (for example, if one is sick or on vacation), the engineering manager can jump in as a code review partner. However, it’s best not to make this a continuous practice in the long term, as it can take away from the other responsibilities of being the manager.

4 Code monitoring 

Monitoring your code is the action of observing the tools that are installed in your code to ensure that everything is active without errors or shutdown. As an engineering manager, it might make sense to check in on these tools more frequently to ensure that everything is going smoothly. If a small issue comes up and developers are head first into a big project, this is an okay time to solve the issue yourself. Just remember to always notify your team of any changes as the engineers who work on the code regularly might have information to help you apply the proper solution.

5 Onboarding

As you onboard onto the team, taking a bit of time to code into the application can help you build familiarity with how the team runs its systems. This is especially true if you’re joining a completely new company for the first time as an engineering manager. 

As well, as you onboard new employees, you might need to take some time to code with them or fix bugs together. Doing so helps your new employee also understand the systems and feel confident in your technical abilities to support them if needed later down the line.

Benefits of engineering managers writing code 

Having managers that can write code is helpful, especially when:

• The team needs to have a strong technical manager who is up to date with modern coding practices.
• There is high turnover or understaffed teams, and high-priority projects with tight deadlines.
• There has been recent onboarding of new staff, particularly juniors, who need mentorship, coding support, and more frequent code reviews.

As well, having a manager who is equipped with the same skills as their team ensures that the manager is more likely to create realistic timelines and budgets for the project as they have first-hand experience of what it’s like to do that type of work.

When should engineering managers not write code? 

• When coding features in your backlog
• When you’re taking work away from your engineers
• When you’re prioritizing coding over management

1 When coding features in your backlog 

Tackling your backlog is your third priority, and maybe it doesn’t even make it that high on some teams’ lists. Of course, ahead of coding features from the backlog, you should be confident that your team members are happy and that they’re working on features that are vital to the success of your product. 

If you find yourself in a position to have free time (although, is that even a thing for a manager!?), consider investing this time into researching, optimizing processes, or learning more about what your team wants to achieve someday. As a manager, this information will give you strategic insights to help you build better, stronger engineering teams.

2 When you’re taking work away from your engineers

Sometimes, doing the tactical work yourself takes away from the feeling of purpose that your engineers should have about their jobs. Instead, giving autonomy to your engineers and encouraging them to take on new coding projects can be great ways to motivate your team. If you’re working with junior developers who are looking to expand their experience, consider giving them new bugs that they haven’t fixed before or pairing them with a more senior engineer in coding reviews. Any opportunity to help your team be independent and learn from each other is a great opportunity to take!

3 When you’re prioritizing coding over management

When you step away from being a developer and get into a managerial role, you agree to prioritize new responsibilities. This includes ensuring the well-being of your team, championing for better resources for your projects from higher-ups, and coordinating resources to ensure your projects deliver on time and on budget. If any of these elements are falling behind and you’re still coding, you need to stop and re-evaluate your work priorities. 

In some cases, especially in understaffed teams, it might be impossible to balance your management responsibilities with the new feature requirements in the schedule. If this sounds like your situation, it might be worth talking to your manager to see what you can do to hire more team members or create a more realistic workload for your team.

Why engineering managers want to write code 

1. They like doing it. Before moving into a management position, being a good coder is what helped them excel in their career. It’s the work responsibility that they became interested in and curious enough to practice day in, and day out. 

2. Feedback loops are slower. Being the person who reviews and corrects the code can make the process of building code a lot quicker. While this isn’t sustainable over the long term, it can help lighten the load on other developers’ plates temporarily.

3. They want to maintain skills (of knowing how to write code). This goes back to the first point. Knowing that you’ve still got it in you to do what you used to do very well is empowering! It’s a helpful way to see that their skill base is growing over the years, rather than feeling like they lost other capabilities when taking on new ones.

4. It’s a break from managing. Coding is a great outlet for creative thinking. It requires some use of imagination to solve problems in new ways, and you get to see the results of the solution in real time, which can be quite gratifying. In comparison, in management, sometimes results can’t be seen until weeks or even months down the line.

Parting advice

Whether you’re an engineering manager yourself or you’re leading an engineering manager, knowing when to join in on the coding fun and when to sit out is a critical insight to help your engineering processes move as efficiently as possible. When engineering managers can jump in on the action for small bits of the week, it’s a great way to connect with your team, maintain technical knowledge, and get a creative break! Just make sure to maintain strong self-awareness about how much time is spent on coding versus management activities so your projects remain on track.