Anarchy & Order: Team Leads

Originally published July 26, 2016 on cocktailmonkey.blog

The Anarchist, Chaos & Order.

When I was young I used to hang out with an anarchist. I would pepper him with questions about his beliefs. Why anarchy? Why tear everything down? Why not build things up? He stated that it was his job to tear structures down: governments, societies, religions. Someone else, he asserted, would come along and build the new stuff. That was none of his concern. I left these conversations feeling off kilter, disconcerted, unsatisfied. I later discovered that as much as I love tearing things down, I also enjoy building their replacements.

It turns out that builder and breaker mindsets are applicable at the organizational level, as much as they are when we build software. It is this cycle of building up and tearing down the lightest structures to move from chaos to a small amount of order, over and again through growth, that is immensely satisfying. What structures do you really need in your organization to keep everyone just over the line from chaos? What structures should you destroy?

Team Leads

I work at a company that used to have team leads, but I couldn’t figure out why.

I started to study them in order to figure out what they were responsible for. One team lead spent all of his time trying to keep the performance tests running, desperately trying to get numbers out at the end. Another team lead triaged incoming bugs, and after observation, I found that most of them did this. One lead ran the bi-weekly tech talk series. All of the leads ran their teams’ retrospectives at sprint end.

The more behavior I observed, the more confused I got. The leads were all some shade of miserable. Most didn’t write much code. What was going on?

I finally asked the VP of Engineering what was up. What exactly were the duties of these team leads? He said they were supposed to get the teams to be agile, to self organize, to collaborate. He wanted the team leads to act as scrum masters.

And yet, somehow, instead of coaching their teams into collaborative, self-organizing bliss, these team leads managed to take on the miserable job of janitor, cleaning up all of the crap no one else wanted to touch! I used to have a job that involved the cleaning of lots of crap: production operations systems administrator at a first year startup. What did we do with all the crap? We rotated it around to the whole team!

I’m a big fan of having a person be “on point” for a week or a sprint in the engineering teams that I coach. That point duty rotates to each team member in turn. I encourage my teams to adopt this structure, and many do. Eventually, they make a checklist of the duties that changes as time goes on. This generally happens when a new person joins the team, finds out they are on point, and doesn’t know what the responsibilities are. Then they ask and create the checklist. Even new hires join in the rotation. They pair with someone who knows what’s going on at first, but after a few days, they are generally self-sufficient.

I also coach all of my team members to lead to the degree that they are able. I have high expectations for each person’s growth in that area. Since each team here had a “lead,” I needed to coach those I worked with to allow and encourage the other team members to lead. The first team lead I worked with got the concept right away. He realized that the true challenge of leading was learning to let others step up and move an effort forward. He did that job brilliantly. The team became very robust in their ability to work as a collective. That team lead ended up adopting broader organizational responsibilities which took him away from the team more and more frequently. Eventually, he was just not on the team, and although we missed having lunch with him, the team did not function at any lower level in his absence.

Over time we grew and teams changed. Although we never officially declared that we didn’t have team leads anymore, we just didn’t one day.

We do have team members step up to take on various special roles as needed. Every time we hire an engineer, we ask for someone to volunteer as their buddy. We also occasionally need an engineer to work with a poor performer who is on a plan. In many cases, these volunteers are not the most senior engineer on the team, nor the person who would have been the “team lead” before we didn’t have them. They are instead the person who is suited to the task, and who has the interest and energy to do the job well, at the point in time the job needs doing.

If you want all of your engineers to learn to be leaders in their own way, create the structures that enable that to happen. Get rid of any structure that doesn’t serve that end. Tear down, build up, observe, adjust, repeat.

Leave a comment