This is the second post in a series, I’d recommend starting with the introduction. You can find all the other posts in the table of contents.
Let me start by telling you a quick story (or maybe call it a bit of rant).
I had the privilege of being the founding tech lead of the Savings Squad at Monzo. It started out as a minimal squad with a product manager, a backend engineer, two client engineers, a designer and me. No conversation had been had about who was leading the squad, but it was pretty obvious that the product manager and I were largely doing so. Honestly, it was good enough. Fast-forward and the squad had grown, product managers had come and gone (that was tough), we’d even had a business analyst join. For all intents and purposes the squad was running “fine” on a day to day basis, but it was no longer clear to me who was or should be making decisions and who held whom accountable from in and outside the squad. Over time a leadership group emerged organically and started meeting occasionally to chat about the longer-term team health. Other team members probably didn’t know. There was probably someone who should have been in the group (the designer) and wasn’t, and didn’t even know it existed. The leadership system “kind of worked,” but we definitely weren’t operating at peak performance and we didn’t address it for months, yet the days of the early minimal squad were long gone. We needed more clarity. The question is: What could we have done differently? - let’s take a step back and pretend we can start from scratch. (For what its worth, being the longest standing leader throughout this entire experience, I take all the above being fuzzy on me.)
Maybe you’ve just become a tech lead for the very first time, you’ve joined a new company or you’re leading a new squad. Where do you start? One of the first things worth doing is explicitly understanding and stating how leadership for that given squad works.
In my experience it’s often implicit which person or people are the leadership in a squad, but making this explicit unlocks a more transparent and straightforward way of working - for you, the other members of the squad and leadership upwards. This raises a few questions. How do I establish what the leadership is? How do I make it explicit? Why did I do this again? Let’s take these by turn.
One thing to keep in mind is that even though you are making leadership explicit, this does not mean it should be rigid. If you need to adapt or move responsibilities around over time, that is often the right thing to do.
How do I establish what the leadership is?
In my experience there is a wide spectrum of possibilities. On one end you have a squad led solely by the product manager. They set goals, communicate with senior leadership, deal with status updates and are generally the only significant interface between the squad and the rest of the company. On the other end you have a squad led by multiple people, most typically the product manager, tech lead and designer. They work on the higher level goals together and share the interfaces with the rest of the team and senior leadership. In between there are all kinds of combinations, with other roles that may make sense to help guide the squad. In my current squad we have a business analyst representing the commerical side of the business in the leadership group and, given our green field commercial focus, it makes a huge difference.
When figuring out where on this spectrum you and your squad sit, it’s useful to look at what is considered the default within your company. My expectation would be that there is a noticeable tendency towards one end or the other. I’d start from the default position and then figure out what you think would be best - does it make sense for you to proactively maintain interfaces outside the squad or is it more sensible for your product manager to pull on your for insight when they need it? This single question makes it sound easy and to be fair its not. It will just be so specific to what you’re doing that I won’t delve into more depth here. But before I move on, a quick, non-exhaustive list of some things I try to have clear ownership for: team health, communicating with senior leadership, staffing, goal setting, progress tracking, socials and more.
Once you have your opinion formed, you’re in a good position to work with the other people who are likely implicitly helping lead the squad to form a shared opinion. You might assume that people default to wanting to be in that leadership group, but I’ve personally often found that many people actually lean the other way because it buys them focus and less stress (having fewer things to worry about contributes to both). In all the squads I’ve worked in I’ve found that sitting somewhere along the middle works for me (and Monzo). In my current squad the product manager drives the big picture and most external communications and pulling on me when he needs it, but the other disciplines entirely owning the detail and often the delivery itself, maintaining the external interfaces necesssary to support this.
The final step really is to match up your squad’s view of the world with senior leadership. It’s very possible there will be strong opinions here, so this may be collaborative effort, but often if you have a good reason for running your squad the way you’ve suggested (which the last paragraph is about), I’d normally expect fairly immediate buy in. One of the main reasons I believe this is the case is because you’ve proactively decided to nail this down, and that by itself shows leadership. The one thing senior leadership will care most about is the interface through which they receive updates, and in my opinion this should be a meeting lead by the product manager (a single person being better suited to this than a group).
So now you’ve explicitly established who plays what role within the squad leadership, senior leadership is in the loop, but the squad itself is basically none the wiser. When I say, make it explicit, I mean to everyone and this is where the next section comes in.
How do I make it explicit?
This is the easy bit. Write it down unambiguously and share it with the squad. Make sure to include what this means for them and also what they might see you do (or have in your calendar) that relates to your leadership role. For example, at Monzo we use Slack extensively and because one of our core values is to default to transparency, you need a really good reason to have a private Slack channel. Having a safe space to communicate raw or incomplete thoughts is very important to a leadership group in my book, so a private channel is warranted, but I don’t want my team to feel weird or left out. This is the kind of thing I share openly as a result, so they know it exists, what it’s for and what you will and won’t use it for. (I often focus on the ‘anti’ of a point, in this case what we won’t use the private channel for. For example, we don’t use the private channel for goal setting because everyone should be able to contribute in real time, but we will use it for staffing because that is sensitive.) This example is especially useful because being in that channel is the unambiguous way of knowing who has the additional leadership expectations.
Why did I do this again?
Coming back to the implicit leadership, I’d hazard that even without communicating clearly who leads what, you could ask any member of a squad who they thought was leading and they’d give you a pretty close answer. If that’s the case, why have I bothered suggesting that you go through making this explicit in the first place? There are quite a few good reasons, I’ll list them so they’re easy to refer back to:
- You’ve removed ambiguity for other squad members and bought them focus.
- You’ve increased transparency and been able to clearly communicate what leadership responsibilities exist and why others don’t need to worry about them.
- You’ve given senior leadership a clear understanding of what to expect from whom.
- You’ve made the leadership group itself more effective, responsibilities shouldn’t fall through the cracks and now you have a model to iterate on (this is really hard when you don’t talk about it openly). Even additional clarity in your own role makes all this worth it.
- Maybe you’ve even created a psychologically safe space for yourself to communicate with your co-leads. Remember, you put on the tech lead hat in an instant, but learning how to do it well takes time and failure, so optimizing for your own learning and feedback loop is well worth it.
- You’ve just put the “lead” in “tech lead.”
All of this leads nicely into the next part of the series - what is my responsibility as a tech lead? Coming soon 🔜
< Introduction - Team before description >