This the seventh post in a larger series, the introduction is a good place to get started. Read the table of contents to see them all.
A slightly provocative title - so let me start by saying that there are exceptional times when not writing any code for an extended period of time is the right thing to do, but this post is about my opinion on the general sense.
By far the most common question I get asked by engineers considering the tech lead route is whether becoming a tech lead means an end to writing code. Let’s not mince words, it almost certainly means the amount of code you write decreases (remember, all the other things you need to be doing require time and concentration of their own), but it does not mean it disappears from your life.
When I first became a tech lead I actually used the amount of time I spent writing code as a positive success metric. If I had time to write code and my team was happy, productive and building quality systems, then I was doing a good job. It meant that I’d focused on high impact things, done those things efficiently and had prioritised well. It also meant that I was being intentional about balancing my manager time, with maker time. Not an easy thing to do without a good carrot! Like any metric, it isn’t perfect, but this one kept me grounded and comfortable. Grounded because code was one of my happy places (still is) and comfortable because it put to rest the “tech leads don’t get to write code/be technically competent” that was on repeat in the back of my mind.
Writing all the code, or all the most interesting code, is definitely an anti-pattern. Even writing too much code is probably an anti-pattern. If code is a happy place for you, and something tells me it is, writing it is something you can and should use strategically. It’s an anti-pattern if you use it to hide from your other responsibilities or things you’re scared of. It’s an advantage if you use this happy place strategically to level yourself out or claw back some headspace, or even to just enjoy it when you’re having a tough week. This is a fine line, but one I think is worth treading and challenging yourself on, because when you get it right, it’s so worth it.
Writing code is also a great opportunity to lead by example, something I plan to write a post about in its own right.
A few other thoughts that didn’t fit anywhere logically:
- As one who falls in “the martyr” anti-pattern easily, I sometimes find myself taking the boring tickets, writing the boilerplate, as some attempt to enjoy writing code and taking the burden off the team. I can say this doesn’t pay off beyond the short term, if even in the short term. Let yourself have a fun ticket sometimes too, even if it takes you a little longer because of other commitments.
- One way I mitigated the point above is to work on something totally unrelated to my squad’s deliverables (though that was not the main motivation, it happened by coincidence). This makes it harder to balance your own work, but if it’s the right kind of project, the time pressure is different and it might even be an opportunity to work on something different from your day to day, also a nice change. In my case this is working on Monzo’s internal Kafka client library. It has all the absolute “must have” features, so I can tinker on it with others around the company to make it nicer and add really cool things (yes, they are also genuinely valuable, not building things for the sake of it I promise). I realise this might be difficult depending on where you are, even at Monzo I recognize it as a privilege.
< Technical confidence first - Be intentional about habits >