How much coding should a manager do?

In my day job we use Slack as a key communication tool – for those who haven’t used it, it’s basically a corporate version of IRC with good UX. In a private channel for those in leadership positions, there was a question about how to transition from Software Engineer to Engineering Manager; what to consider when moving from a predominantly individual contributor (IC) specialisation to a team management focused role.

 

My reply got an upvote from about 10% of the channel, so thought it a good start for my first blog post on the subject of management*:

 

Q: How much coding responsibility is it wise to take on as a manager? How much time do you spend on the doing as opposed to the planning?

A: I like to think of the role of an Engineering Manager as sitting somewhere on the sliding scale between pure management (no coding) and pure IC (no management). Engineering Managers and Principal Engineers both have some people management, and some technical work. We choose to a certain extent the balance between the two. There’s therefore no right answer as to how much you should be doing – a lot is down to personal preference.

During my management mentoring, <senior manager at our company> helped me come to terms with no longer spending the majority of my time writing code. This is a big deal because essentially it’s a life skill you’ve been getting better at for 10, 15, maybe 20 years or more and for the first time since starting you’re consciously deciding to stop / slow down. I conducted a pre-screen interview for an engineering manager candidate who, when asked to write a simple function processing a list of strings, answered with, “I haven’t programmed for 5 years. I’m a manager now.” This person would not be able to command the respect of a team of engineers because they got the balance badly wrong. As already stated by others, your priority as a manager has to be away from the critical path. You cannot contribute quality code to solve complex problems unless you’re free from distraction and able to resist context switching. If there are randomly occurring decisions that you alone must take, meetings that you cannot delegate, or blocking interruptions from direct reports, you will not be able to attack the complex problems _and_ be a good manager.

Engineering Managers’ main focus and responsibility is successfully solving business problems as part of a team. The role you take within that team, and how much coding you can do, very much depends on the team itself. From working for <other senior manager in our company> I’ve become an advocate of the strategy of trying to make yourself redundant within the team – the theory being once you’re no longer needed, you can progress to something bigger/better/more interesting. This will involve examining the strengths and weaknesses of the engineers in the team and developing them where required. You need to plug the gaps. If the squad lacks strong, experienced programmers then you can help out there. However, if the squad are all great coders, does it make sense for them to own the bulk of the programming while you help develop their other skills? If you can’t code as much as you want to in the office, ensure you don’t become one of those “I haven’t programmed for 5 years” managers by finding a project or two outwith the team, maybe outwith the company altogether.

TL;DR – the amount of coding you do is part personal preference, but more important is how much the team needs you to do (and that might be none, or close to none).

 

 

*management: small postscript because it’s been a while

After becoming an engineering manager, I pretty much stopped blogging. Partly I’ve been finding more fun things to do with my time but also I believed I had less that was worthy of sharing. I’ve been doing small programming projects and having random thoughts about software development for years, but management… I’ve only been doing that for a couple of years.

 

Even though I generally believe, “There’s nothing new under the sun.” and most things are repeating patterns, it’s still worth writing down your viewpoint because it may well not be new, but others might not have heard it.

 

To be clear on what “management” is, I saw little of it at the companies I worked for within the financial services industry. There the team lead, or manager, was usually the most senior (longest serving) programmer. They did the biggest architectural software changes, had an eye a little further ahead on the project roadmap, and had a couple of extra meetings to catch up with direct reports every now and then. But they were essentially still software engineers 90% of the time and not managers. They had no significant training in motivating and developing people, delegation, providing feedback, supporting teams and individuals through change, coaching, conflict resolution, understanding team dynamics – just some of the many elements that a good manager should be able to deliver. I’m still learning, and trying to ensure I am a good manager, but I feel comfortable enough to begin blogging about it.