Bad Team Leads and Responsible Adults

Does a team need a team lead?

I've been thinking quite a bit about flat team structures over the past couple of weeks. As is often the case, it's recruitment-driven. I'm going to be blunt here: I've been really disappointed by the prospective tech leads I've been interviewing.

This is odd, because the recent graduates and junior developers coming through that same process fill me with hope for the future of our industry. I always used to worry that I was part of a narrow cohort who grew up with computers that booted to a BASIC prompt and the gradual shift to computing devices as passive content consumption platforms would mean an end to the young hobbyist programmer.

But no: I'm speaking to people who've only just joined the workforce and finding individuals who are enthusiastic, curious, well-rounded and above all technically proficient, often in multiple languages. They're interested in what we do and what our mission is, and the interviews often reach that ideal state where they're a relaxed conversation about the problems we face and how we can solve them.

I wish I could say the same about tech lead interviews. Sadly not. I keep meeting this same profile: someone who can't code because they see their job as management, but also who doesn't really do much of that management - they wait for instructions from some nebulous entity referred to as "the business" or "stakeholders" and relay those to the developers. Maybe once in a while they relay something back. This isn't management, it's acting as store-and-forward messaging system. As for the wider technical picture, ask such people a detail question about security, infrastructure or even basics like performance monitoring and alerting and it's a rabbit-in-headlights moment.

What do I need someone like this for? I don't need a gatekeeper: our junior developers are perfectly capable of working with their non-technical counterparts. More so than me, because they tend to check their clothing for curry stains before the meeting. When a fresh graduate can explain OAuth2 to me in a reasonable level of detail, why do I want someone "experienced" who's never even heard of an Authorization header?

Well... because experience does have some value. I've built those flat teams of entirely young and enthusiastic people before, and they work great up until you find all progress has stalled and the team is on Day 4 of a bikeshed about whether private variables should be prefixed with a _. Or you realise the shiny new cloud solution they've deployed is running six different Linux distributions and has no mechanism for patching. Or indeed any one of a huge number of, "it looked like a good idea, until we did it..." pitfalls that you'll easily stumble into if you approach everything with more confidence than experience.

This is what I usually rely on my tech leads for. The ability to recognise a bikeshed and ask, "is this really important" and/or, "is this helping us deliver value?" The consideration of the stuff that you never worry about on a hobby project. The experience of having made a few mistakes, learnt from them, and worked out how to spot the pattern of well-intentioned error. Most importantly, the ability to know when to stop being confident and start saying, "here be dragons."

But does that person need to be a lead? And is a lead necessarily that person?

Responsible Adults

I think what we're actually looking for here is something subtly different. It's not so much being a lead as it is being the responsible adult. A responsible adult is exactly what it sounds like: the person that the team trust to say, "this isn't a good use of our time" or, "this water is getting a bit deep, we should get some help before we go any further."

One of my colleagues points out to me that when I look for a good programmer with some leadership skills, some security knowledge, some infrastructure knowledge and a little bit of awareness of how everything will fit together, I'm hunting for unicorns - or at least experienced DevOps engineers. Yet I think for a lead, those are essential skills. Where a hierarchy exists you need the respect of the team, and the knowledge to lead it in the right direction. I'd rather have no lead than have a bad one who isn't respected by their team, or who decides they're going to ignore all advice and plough their own furrow. Usually toward a hidden cliff edge.

The responsible adult is a bit different. The team doesn't expect them to be the best, or to always have the answers. There's no hierarchy being imposed, and thus no need for the responsible adult to be "better" in any way. Instead, the team trust their responsible adult to be able to say, "hang on, we don't know enough about this, let's find someone to help" when the right thing to do is consult a chapter lead. The skill is more about knowing what you don't know, both as an individual and collectively as a team.

This relationship is something the team need to codify in their working agreement. Just as in a hierarchical team you'd have an org chart telling you who's tech lead, you need that working agreement to say, "Christina is our responsible adult, we allow her to end unproductive discussions and make us ask for help". And as with anything on the working agreement, the whole team needs to be calling each other out if the responsible adult is being ignored.

The great thing is that anyone can be a responsible adult, once they learn to listen to the small internal voice that says, "hang on, we haven't done this before". At first this is likely to be the most experienced (or possibly most cautious) person within the team, but everyone can learn from example. It's even good to have multiple candidates within a single team, so you can replace anyone who acts like a benevolent dictator. You can even have elections and term limits if you want. After all you want a responsible adult, not a power-mad one.

This approach does mean you need subject matter experts on hand for those responsible adults to consult. But at least you can concentrate that knowledge into specialists and keep them busy, rather than needing multiple leads and senior developers who know a little of everything.

It's not a perfect approach. Knowing when to make those responsible adult calls on bikesheds and asking for help is still a skill that needs to be learnt and honed. Even the best teams will end up ignoring their working agreement and by association their responsible adult when discussion gets heated. But as a way to get around the inability to decide or the preternatural ability to create well-intentioned error of a totally flat team, it's worth trying. And compared to the damage a poor team lead can inflict, it's a huge improvement.

Plus anything that stops me having to spend another few hours talking to people who are ten years in the game but still can't write a unit test is good in my book.