This is part five of my series “Tech lead 101”. If you’re new here, check out the introduction first. Visit the table of contents for a full overview.
About 1.5 years ago Monzo started to formalize the concept of a tech lead. We started by writing down high level expectations for what is expected of someone in this role (we call it a hat, because its not a promotion, but rather a function in the team instead of a sign of seniority). I helped review these and couldn’t shake the feeling that someone was missing. I’d been tech leading for about half a year, having had the privilege of being one of the first at the company with the label, and as much as the expectations felt right I struggled to relate to them. I mulled it over and eventually realised that when I started out, the thing that would have helped me most was not an understanding of what to do, but rather an understanding of what things I might be tempted to do but shouldn’t. We added them and to this day they are enshrined as the “tech lead anti-patterns.” They include things like “the faux product manager” and “the martyr.”
In this post I want to encourage you to identify your own anti-patterns. What are the behaviors that you default to when things get tough or ambiguous for the team, that actually cause more harm than good? The reason why I’d encourage you to do this is that once you’re cognisant of them, it becomes much easier to catch yourself when falling back starts. Even better, you can share them with your team and ask them to help keep you accountable and aware of falling back into these behaviors. For what it’s worth, this will absolutely happen - you will revert to default behaviors that aren’t good for you or the team, and that’s okay because its a big part of the journey you’re on. This hints at an additional, more subtle, reason for identifying your personal anti-patterns.
You will fail and fall back into these bad habits. It’s important to not optimise for lack of failure because then you won’t take risk or experiment. Instead, its important to optimise for compassion for yourself. When you default back to one of your anti-patterns, the goal is to recognise it without judgment, rectify it as best you can and move on. Not to berate yourself or put yourself down. Doing this with understanding for yourself is much easier if you anticipate it happening, and you can only do that if you know what to anticipate. You’re anticipating your personal anti-patterns.
To help illustrate this point I want to share one of my personal anti-patterns and a very recent example of falling back into it. The single anti-pattern I find myself doing most by far is being “the martyr,” so named because if you look at the behaviors its clear that you’re martyring yourself for your team unintentionally. For me this often takes the form of keeping all the work I perceive as boring, uninteresting or worst of all distracting, for myself, so the team can maintain focus. I’ve always thought this might be one of the downsides with my slight obsessive people focus, conclusion still pending here. When I do this, it tends to lead to two dominant consequences. The first is I get very stressed and start feeling demotivated, largely because often there is a fair amount of this kind of work at any time, I end up parallelizing too much and feel utterly overwhelmed. This eventually bleeds into the team, but I bare most of the downside (hence the name again). The second is that I stop sharing context. I have too much on my mind/to do, I’m already stressed and begin to perceive context sharing as taking too much time. I stop sharing, others have less visibility on what I’m doing and how they can help. A real vicious circle kicks in and the squad starts seeing negatives too as I inevitably don’t get things done on time and nobody can proactively help. Plus my performance across the board gets worse, as I try to do all the other parts of my job whilst sating this vicious circle. I’ve already lost count of how many times I’ve caught myself doing this one, so honestly don’t feel bad if you find an anti-pattern you’ve been doing for years.
My team has been working against very ambitious deadlines for a while, a prime time for me to default back to “‘enabling’ others by destroying myself,” a less catchy name for the same anti-pattern. Inevitably this happened, but because the engineers on my team know about this tendency, one of them helped me spot that I was already pretty far along this path before I’d even realised it myself. This was step one. I’m very aware of this anti-pattern, and because it has a concrete label and something I can recognise clearly, I was able to quickly stop doing it without blaming myself. This was step two, a step you can really only leverage if you take the time to identify yours for yourself. I recommend giving them a genuine catchy name, it makes them easier to talk about, remember, and ultimately recognise.
In case it helps, I’ll list a few other anti-patterns I’ve seen in myself and/or other tech leads:
- The individual contributor: forgetting your job is to enable others and falling back to writing the majority of the code. Focusing on getting your code reviewed before others and more. (I want to add here that I’m not implying you don’t write code, you absolutely should, I have another post planned about this.) This might happen when a tech lead is stressed and is looking for a safe space, somewhere they feel confident.
- The everything architect: designing all the systems for the engineers in your team to build, rather than allowing them to design them or designing them together. This might happen if you’re solving a particularly difficult problem or working with a more junior team. It’s easier to design and hand out work in the short term.
- The faux product designer: doing the job of your designer. This is similar to “The individual contributor” but for a tech lead that enjoys design. (Again, getting involved with design and making design changes is amazing when it’s done right).
- The faux product manager: no longer being a tech lead and instead product managing a squad (assuming you have a product manager). This might happen if you have unclear leadership/division of responsibilities, or if you’re working on too much in parallel as a team.
There are many more and I’ll try to come back and add them as I see them! Feel free to email me if you’ve seen others and I’ll add them in.
In conclusion, identify your personal anti-patterns, share them with your team and when you inevitably find yourself falling into one - compassionately acknowledge it and stop, no need to be hard on yourself.
Next up we’ll be looking at technical confidence, why it matters and when to get it.
< Put people first - Technical confidence first >