Introduction

Great engineering leads (any lead) constantly encourage input from all Scrum members (everyone) and help manifest democracy whenever and wherever they can. Great engineering leads constantly encourage input from all Scrum members because they want everyone involved in a team effort, including and especially introverts and those who lack confidence in speaking within a group; know that typically the more opinions and insights offered, the higher the probability that a better solution will emerge; recognize they often need the assistance of their teammates! They also constantly encourage democracy for the reasons just mentioned, but also because they know there is no reason to ‘lead’ if the team is collectively producing sound solutions. Before I expand on the reasons great leads encourage input and democracy let me first flick away a typical slippery slope fallacy.

Fallacy: A leader who encourages input or democracy too much is not a leader

Some may feel that a lead is to do precisely that: lead! Yes: a defining characteristic of a lead is that they have the insight to produce effective solutions under pressure, a skill wielded by usually the more experienced (and _possibly_1 more intelligent) engineers, however the SRE solution space is extremely well-covered and mature so if a lead’s team isn’t independently arriving at roughly the same solutions then the lead needs to train the team up (one of the rare times a lead is useful). In other words if a lead’s solutions are typically a departure from the team’s then likely the lead isn’t handling the first of their two main responsibilites: training (the other is paperwork); finally, if a lead’s solutions aren’t that much of a departure from the team’s (with the exception of maybe nuance in security, library, etc.) then encouraging input and democracy will likely hasten the emergence of an effective solution and thus a ‘lead who does not lead a lot is not a lead’ argument is a mere slippery slope fallacy.

Great leads want everyone involved

A great lead knows that diversity == strength so they want everyone: red, brown, black, yellow, white, trans, non-binary, gay, straight, differently abled, introverted, non-engineer, etc., involved. Regardless of background, a great lead wants everybody in. When these backgrounds merge, great solutions emerge because the history of science and engineering is, despite what some may assume, an expansive tapestry of groups and cultures from all around this earth innovating to survive and thrive. A great lead knows that manifesting this tapestry microcosmically within their team can produce the very same conditions which has historically given rise to such brilliance.

Great leads want a lot of insights and opinions

Great leads like to get a lot of insights and opinions from their teammates. As the number of insights and opinions go up, convergence upon an efficacious solution tends to go up. Additionally, a great lead will use this abundance of discussion as a catalyst to train those who are unable, including themself, to give input on particular topics.

Great leads need assistance

Great leads need and want their teammates help because they have a QA mindset: they’re not comfortable never having their architectural diagrams, ideas or presentations critiqued and reviewed. Yes, a great lead should have the skillset to make complex decisions under pressure with a very high degree of independence…but they recognize that a second pair of eyes is almost always twice as clarifying as their own review. Finally, great leads strive to develop and master their craft, so they don’t hesitate to ask a teammate, no matter how junior, for help, when they think a learning opportunity is possible.

Great leads constantly encourage democracy

The truth is great leads want as little hierarchy and distinctions as is possible because they want everyone involved, sharing lots of insights and opinions, and assisting one another, all of which sums to democracy. The goal of a lead should be to free the team of the lead in as many situations as is possible and democracy is an excellent framework for achieving this because it empowers teammembers to give their input, ‘cast their votes’ and dissent, sometimes against all others on the team, including management.

1 - Being a lead is not mutually inclusive of being a so-called rockstar. I’m going to write a post on this eventually, but the reason whyis because the solution space for SRE work is extremely mature and well-covered so being a lead is less about innovation and more about having a deep understanding of SRE fundamentals.