Should Managers Code?
Judging from the job descriptions I see for management roles, a lot of people think that a “hands-on manager” should be making pull requests and writing production code.
Even managers have a finite number of hours in the day, and need to choose where to focus their time and attention The small slice of code they could be implementing will come at the expense of bigger picture work – building relationships with stakeholders, explaining the relationship between business problems and the work the team is doing, being available to listen when someone is having a problem, and all the other bits that go into the sensemaking function of a manager’s job.
It’s perfectly understandable that those activities hardly look like “work” from the point of view of an individual contributor engineer. Many of us who have moved from engineering roles to management struggled with that at some point – how do we measure our own contribution when there are no lines of code to count and JIRA tickets to close? The problems headed off that didn’t happen, the employees that didn’t leave, the introduction we made that blossomed over time into a cooperative relationship – we can’t see these clearly at the scale of a day or a week.
But it’s something of a red flag when senior management doesn’t appear to recognize management as a discipline itself that needs time and thought to flourish. Mapping out where we’re going and making sure we have the tools to get there is not a part time task, especially in a large organization,. How do these managers have time to code? The things they are leaving undone invisibly slow down their teams more than the velocity of the features they ship. Then, the code and tasks that they’re involved with visibly block other engineers when their attention isn’t present.
But it’s more complicated than that. Managing a technical team does come with some responsibility to understand what work is being done. Being able to do the work yourself is not the bar but being able to provide meaningful feedback to plans and to individuals as they grow is necessary . Managers, too, have to keep growing in technical understanding, and learn more about engineering – even as they hone the craft of management. Even when we’re not first line contributors to new tech, the technical empathy that we develop pays off in the relationships we can build with our teams.
What are some good ways to keep technical skills fresh without writing code for new features? Careful and critical reading of the design documentation that your team is writing is one important element. If there are areas where the decision-making is unclear, that’s an area to dig in. Pair programming often has a teaching function, and that’s just as valid for a manager as for a new hire.
A different approach is to write some code that’s not on the critical path. Maybe there’s some tools you need for yourself, data analysis or reporting. Struggling through those can help develop technical empathy. Another way to do this is to write some test code. You’ll see the internal workings of the pipelines your team uses without slowing down necessary releases.
Every now and again I pick up a personal coding project. This quickly reminds me how much skill and practice I’ve been missing as I’ve concentrated on other things!
All these things help me keep a technical oar in the water, if only to remind myself of how hard the engineering work can be. Hopefully those experiences will keep me from eliding the critical details that go into appropriate designs and accurate estimates.