Should engineering managers write code? Wrong question.

By eleith

I spend a lot of my time advising engineering managers and “How much code should I write?” gets asked by a lot of folks new to the role.

Many good essays propose one line answers ranging from no all the way to 30% of your time.

However, focusing on how much code managers should write distracts from the intent of why managers want to write code to begin with.

Being a great manager means you need to prioritize all work directly related to managing and interacting with people on your team. You need to develop managerial skills, and my favorite one is empathy. Being able to empathize requires understanding the perspective that engineers face in their day-to-day work.

Many great engineering managers were once engineers themselves, helping them to empathize directly with their team. However, the field of engineering constantly evolves and as a manager, staying in touch with these changes enables them to continue to empathize with their team.

So instead of asking “How much code should I write?” instead ask “Where can I write code?”.

At Coursera, our managers embody this approach directly. In doing so, we retain our engineering skill set while focusing on increasing empathy for engineers on our team.

Where to NOT write code

Sometimes the best way to answer a tough question is to answer the anti-question, “Where should I not write code?”.

If people are a top priority for managers, role modeling great engineering through code requires a huge amount of attention to tests, monitoring, code reviewing, design documents and more.

Those tasks require time and space which full time engineers have while managers do not. If managers write code and then expect others on the team to do all the other heavy lifting (testing, debugging, documentation, reviewing, monitoring, maintaining, etc. etc.), a manager will lose the ability to motivate great engineering on their team.

Engineering managers should not write code on the critical path for their team. While this does seem restricting, it also opens up new opportunities.

Where to write code

Code at work: code reviews

Programming is 10% keyboarding and 90% design, communicating, testing, reading and more.

Thus, one way for a manager to “code”, involves not writing code at all.

Code reviewing helps build empathy with the team while also strengthening programming skills and building an understanding of the product. Code reviewing requires both the ability to read and understand code — arguably one of the most important aspects of a great engineer.

However, managers should avoid being the sole reviewer on any commit to acknowledge that other managerial work may interrupt.

Code at work: super tiny bug fixes

Occasionally, managers have an opportunity to roll up their sleeves to fix super tiny bugs (1–2 line bugs). Like with code reviewing, this approach doesn’t require writing much code.

Instead, it requires reading the code around the bug and requires a working development environment.

Managers should exercise caution and not introduce new bugs, model positive engineering practices and write tests if the functionality changes enough. Try and avoid fixing bugs that the team recently introduced to encourage ownership.

Reserve this approach for bug fixing in areas where the team has a bus factor, on very old bugs or trivial issues that would merely take away time from an overburdened teammate.

While a team focuses on building a great product, many opportunities exist to improve the tooling used to engineer great products. Improving those tools through automation or new internal tools provides both engineers and managers a great opportunity to have impact.

As an example, Nick Dellamaggiore (Coursera’s Infrastructure Lead) noticed that engineers were using heavy boilerplate to monitor events in our eventing pipeline. He wanted to reduce this boilerplate and remove the requirement to re-deploy a service for each new monitor. His work accomplished all of the above and much more.

As of today, we exclusively use this approach to quickly monitor new events in our ever evolving product from performance monitoring to product usage monitoring.

However, if one of these tools becomes popular or essential, maintenance and feature requests may become a burden for the manager in the future. To avoid this situation, managers should find a home and ownership for this tool.

Instead of finding opportunities outside managerial tasks, managers can find ways to build tools to help them do their own jobs better! As a manager, a number of tasks or roles may be automated or improved through their own code.

1. Google Scripts

A few quarters ago, I found myself going through all of our previous post mortems to identify trends and determine our strength at following up on preventative issues.

Our post mortems were not centralized in one place and copying numeric data out of each post mortem was time consuming and boring.

To reduce my own work and that of future managers, I created my first google drive script. Now, at Coursera, engineers simply fill out a google form that asks a standard set of post mortem questions and a post mortem document gets auto-generated while also populating a central spreadsheet of valuable post mortem metrics.

Not only did data analysis on our past post-mortems improve, but i’ve heard from engineers that filing post-mortems takes less time.

More recently, Priyank Chodesetti (Engineering Manager on the Learning Experience Team) wrote his own google script to automate how our teams run sprint retrospectives before each sprint meeting. Sprint retrospective participation has gone up considerably since he launched these scripts.

2. JIRA

At Coursera, we rely on JIRA for bug tracking and sprint planning.

Jerry Charumilind (Learning Experience Platform Team Lead) put together a report on our team’s effectiveness at addressing support tickets.

While JIRA can do many things, it is difficult to pull up historical data through their built-in plugins. However, with python and the ever-useful matplotlib, he was able to visually tell a story of how well our engineering organization was responding to support issues.

More recently, Jerry is back at it again, writing an automated script that re-pings issue owners on issues that are ageing and need re-consideration for prioritization.

3. Slack

Writing slackbots can give managers an opportunity to code while also attempting to improve productivity (or entertainment) on the team.

Last year, I had fun creating three slackbots:

• Buggy — create, search and assign jira issues
• Foody — query our lunch and dinner menus
• Booky — search engineering documentation on gitbook

4. Phabricator

Enforcing great engineering practices can also benefit from some programming. Mustafa Furniturewala (Engineering Manager on the Learning Experience Team) faced this scenario when he wanted to improve the testing culture on his team.

When reviewing code at Coursera, we automate linting to block commits that don’t follow our coding style guides. Taking advantage of this type of gate, Mustafa wrote a script to enforce all new components to come with at least one unit test.

This has enabled managers to spend less time manually inspecting commits and more time thinking deeply about how to motivate investing in healthy unit and integration tests.

5. Company Hack-a-thons

Lastly, at Coursera, make-a-thons (our version of hackathons) are the most fun way for managers to write code. In the last three quarters, almost every engineering manager has participated. In fact, Richard Wong (Director of Coursera Engineering) won an award for best of show at the last make-a-thon for his project that auto generated translated audio from video transcripts. His live demo was amazing!

Some engineering managers like to work on pet projects, side businesses or even open source contributions (for example, i maintain the very unpopular emailjs). These options provide space for anyone to write a lot of great code.

While outside work can be a fun place to write code, engineering organizations should consider a more holistic approach to encourage their managers to find time to code on the job, particularly to encourage healthy work+life balance.

Are engineering managers coding enough?

I’ve suggested different places where managers can write code; it’s not a definitive checklist. Great engineering managers can develop empathy for their teams with only 1 or 2 of these approaches.

Once managers feel comfortable with where to write code, they can now better answer the more intangible questions of when and how much code to write.

I don’t believe there is one correct answer. Rather, it is up to each manager to determine whether or not they feel enough empathy to fulfill their role in motivating an awesome engineering team to build great products.

Last week, an engineer on my team asked me for help in debugging a bug she found. We spent about 20 minutes digging through the code and trying various inputs and finally located the root of the bug together. When my team feels comfortable approaching me for problem solving help, these kinds of interactions tell me that I’m coding enough.

Originally published at building.coursera.org on December 1, 2016.