Imperfect #9 - Why and when to code as a manager
Keeping our skills sharp without blocking anyone
Hello again!
We haven’t talked since March, and I have fresh new ideas to share. I recently coded a proof of concept for one of my teams, which gave me some nice hands-on time and I thought I’d write about it.
Engineering leaders need to work on things that improve the outcome of entire teams. Coding is rarely the right way to achieve that, but it can be useful sometimes. Today I dive into what I do and when, which is fixing bugs and doing proofs of concept. Those are two things that work for me and my teams, as long as I’m careful not to overdo them.
Becoming an engineering manager is a career change. Delivering value via the outcomes generated by other people is very different from cutting code. For that reason, I usually advise new managers to stop coding as soon as possible, focusing instead on people, process and communication.
But writing code can be very helpful:
Especially in smaller teams, we might reasonably be expected to cut code or fix issues, regardless of title. Think of the “CTO” of a two-person startup, or the “head of engineering” of a company with a single dev team. It makes sense to be hands-on.
Code reviews are great ways to share knowledge - general knowledge from us to individual contributors, and codebase-specific knowledge from them to us. It’s easier to do good reviews if we’re all familiar with the codebase.
Getting familiar with the day-to-day reality of our direct reports is very important. It gives us insight into their experience and how things are actually going for them.
It builds credibility. People tend to expect their direct manager to have expertise in their line of work. It always helps our relationship to “jump in the trenches” and get our hands dirty together.
I go so far as to suggest that EMs new to a team might benefit from doing a stint as regular developers, before transitioning to fully managerial duties.
Of course, a manager picking up coding tasks regularly creates problems. Tasks usually come with deadlines and dependencies. Deadlines are hard to meet when other urgent things keep coming up. Keeping those tasks waiting hurts people who depend on them, which hurts the entire team. At best it affects sprint metrics, at worst it prevents releases. Causing those failures is very damaging to our credibility as managers. I’ve been there, and noticed that this can be a silent failure mode: not everyone is willing to call out their managers. Resentment can build up slowly and quietly, and it’s a lot of work to come back from that.
But coding is very alluring. It’s a nice place to hide from the strife, conflict and uncertainty of management work. New managers face a very high risk of failure due to the pull of that perceived safety. This is because time spent coding is time not spent aligning stakeholders, reviewing architecture and design, planning career paths, delivering feedback and generally tending to the garden that is a software delivery team.
So how can a manager code without blocking everyone or reverting to full Individual Contributor behavior?
There are many ways but my favourite are fixing bugs and doing Proofs of Concept (PoC).
1. Fixing bugs
Low priority bugs from the backlog are a great way to keep our skills sharp, develop our understanding of the codebase and associated build and deployment systems, and build rapport with our reports at a very low level while doing useful work. Because they’re low priority, no one cares how long it takes to fix them. But each bug fixed is one less annoyance for everyone.
The downsides:
Risk of becoming the designated bug fixer.
Be mindful of not dropping too many review request on your team, which can disrupt their time planning.
2. Proofs of Concept
Sometimes there are initiatives in the near future which the team doesn’t yet know how to tackle. Often involving some new tool or technology that is expected to work, but no one has done it before. If the timeline is long enough, that’s a great opportunity for a manager to go ahead and brave the path, explore ideas and share what they learn.
The downsides:
Exploration and experimentation are important activities for the team. They help develop problem solving skills. Don’t take them all for yourself.
PoCs can be fun breaks from the stress of deadline-driven feature delivery. You don’t want to be seen as taking all the fun work for yourself.
As long as we can avoid or minimise the downsides, these are two ways I found to keep my coding skills sharp and keep my technical credibility high. Things change when managing managers, but every now and then I still find myself driving a small PoC whenever some specific experience that I have makes it possible to deliver it much quicker than others could. Of course that is — as it should be — a very rare occasion.
Hope this helps someone out there!
I’m very curious to hear other people’s stories about coding as a manager. If you read it this far, why don’t you write a comment or email me back with how much you still code?
Looking forward to hearing from you.