Becoming an engineering manager is a paradigm shift that many struggle with at first. I think that one of the psychological difficulties for new engineering managers, and certainly one that I was having, is that of perceived productivity. To a developer, managing people can feel mind-numbingly unproductive because you seemingly “cannot get anything done”.
This is not surprising when you consider the clear metrics of productivity, or rather units of work, you enjoy as a developer: You can count the number of commits you did, the number of lines of code changed or added, the number of features implemented, of bugs fixed, etc. Over years, your sensors for productivity have been calibrated towards those things. You feel productive when you sit at your computer and code. Maybe not all the time, but again and again.
When you manage a team of developers, most of this goes away. If I, or most other engineering managers, used any of the above metrics for myself, I would have to conclude that my productivity is exactly zero on most days. As a manager, sitting at your computer can actually be detrimental to your productivity. Let me explain.
Management is about communication. As a manager, you have to have a lot of conversations. At any given moment, Peter might be pushing for a role change, Paul might be having a conflict with somebody that they cannot resolve by themselves, Mary is new and has to be mentored, and Joel has been showing weak performance for some time, and you do not know the reason. These are all issues that need to be actively taken care of, i.e., managed.
Some (especially new) managers will still choose to sit at their desk and behave like they are individual contributors, trying to get some more “real work” done before they half-heartedly try to take care of the people issues that plague their teams. They argue that they do not want to leave all the work to the team, or act like “a boss”, but get their hands dirty alongside their people, and help them however they can.
However, this is a misconception: Your team needs management, and you will not help, but harm your team by failing to tackle management work. Issues will not be resolved by you sitting at your desk and writing code. Peter will wonder if you are serious about supporting him in his wish for a role change, and this pondering will distract him. Paul will brood over the unresolved conflict he has. Mary will be unsure if she is doing ok and fulfilling everybody’s expectations. And Joel’s teammates will become impatient with him and wonder why nothing is done about it. All of this will hurt your team’s productivity and focus.
And it is not getting better, because the problems will only pile up over time. Peter will start looking for a role change in a different company. Paul’s interpersonal conflict that started out as minor and fixable? It will balloon into a toxic atmosphere that affects entire teams. Joel, who has been underperforming for weeks? Before you know it, it will be months, and nothing really has improved, because he did not receive any valuable feedback. By now, all his teammates are annoyed, and do (or re-do) his work for them.
Like I said, all these problems kill your team’s productivity. But your team’s productivity is your productivity. Your productivity as a manager is measured as the productivity of your team. This is why, above, I wrote that sitting at your desk can be detrimental to your productivity. If you spend your time coding at your desk when you should be caring for your people’s problems, their - and, hence, your - productivity will decrease.
So, if a fresh engineering manager says that they feel guilty not coding along with the team when there is time pressure and things get tight, my answer is: You have to learn to deal with it. And if you can’t, you (and your boss) should ask yourself if this is the right role for you.
So, I hope we can agree that management is something that needs to be done, and done well. Then, how do you get around the misperception of being unproductive? How do you recalibrate your productivity sensors that have been trained during years or decades doing software development? I am tempted to say that the more time you spend away from your desk, the better, but that is an oversimplification, of course. Quiet time to think and strategize is also important.
I think the key principle is putting your team’s productivity first, instead of your own, individual productivity. Remember, you are a communication hub and a multiplier. Think about what is best for others, and think about the things you can delegate vs. the things that only you can do.
If you spend a lot of your time coding, you are preferring an activity that somebody else could do to one which only you can do.
What could a productive management day look like?
Activities during a productive day as an engineering manager might include:
- Learn something about one of your people that you did not know before.
- Help somebody find the right person who has the expertise they need at the moment.
- Help somebody manoeuvre through organizational bureaucracy to reach a goal.
- Give feedback to somebody, be it praise or constructive criticism.
- Delegate some work. Agree on what success looks like, and when you talk again.
- Have one or two good one-on-ones.
- Establish consensus on something where people had different ways of doing things (e.g., rules for merge request comments).
- Help an employee develop a vague idea into something more tangible and actionable.
- Teach somebody something.
- Through your position of power, help somebody make or implement a decision.
- Get somebody the equipment they need, or un-block them in another way.
- Design a training plan for your employees.
- Do pair programming with an employee to better get to know her way of working.
Usually, the more people you reach or affect with your actions, the better. However, if you help one person develop a brilliant idea into something tangible, this might also be of tremendous value for your organization. Therefore, it is hard to derive a clear productivity score from the above activities. Observe their outcomes over time, look back on the past week, take a lot of notes or write a journal, and reflect. With more experience, you will get a feeling for what is effective, and what is not.
Most likely, this will take a bit of time. After all, it is scary to leave the well-known world of coding, where everything is crisp, precise, and clear, where you can clearly tell a productive day from an unproductive one, and move into the realm of unpredictable, problematic, and illogical human behaviour. During my first weeks in my new role, more than once I would look back at the end of a day and wonder: What did I even do today? If you ever feel that way, and if you truly work for your people instead of hiding at your desk, just tell yourself: What I accomplished today is not yet visible. But it will be.
This blog post took me about 4 hours to write. Some of the writing was done in a bus heading for trivago’s amazing once-a-year internal tech conference, the Tech GetTogether.