No privileges, no elites
In Teams, I spend a great deal of time talking about organisational design. It's such an important and fascinating topic to me, I dedicated a whole chapter to it. The way you organise functions and roles inside teams plays a central role in culture too, so let's explore that.
The cultural aspect of organisational design starts with privileges and policies. In most environments, there is some degree of privilege when it comes to specific topics like deployment rights, access to different environments. A common explanation for these privileges is risk mitigation. Those in charge want to minimise the mistakes you can make, so they grant privileged access only to a handful of people. This approach creates a false sense of security, when in fact these companies aren't doing better than any other company out there. They have outages and break things like everybody else. In reality, these privileges create the worst dynamic: it frustrates younger team members because they can't access some obvious knowledge that would increase their seniority. It also makes sure that only seniors can make mistakes. Getting rid of all forms of privilege may sound scary, but there is no need to freak out:
Saying everyone can do anything doesn't mean everyone will.
On average, this doesn't bring much change in terms of risk. You won't get more outages. Why would you? Leaving the doors open increases the chances of getting a smarter team. If you remove all privileges, chances are someone will make mistakes, which is a direct consequence of their ability to access everything. As a leader, you may find yourself wishing a team member didn't have access to that part of the system. The train of thoughts is so common: "If they hadn't had access to the server, that incident wouldn't have happened". It can lead you to believing that a degree of privilege is a practical answer. You would be fooling yourself: trying to avoid mistakes is a silly strategy that builds a silly culture. Mistakes will happen and, as a leader, you must welcome them because you can teach people how to react to them and what they can do so that the problem doesn't occur again. Use mistakes as a learning opportunity by implementing a post-mortems policy.
Apply the "no privileges" policy aggressively. People should not be confined to only one phase of your product development process. Of course, people specialise because they care more about one thing or the other, and it's important they can freely develop in the direction they want. Our systems are too complex for people to know the details of everything. But don't assign those specialties any privilege. In fact, I reject the notion of privilege entirely. If one can do something in a team, everyone else can do it too.
In my career, I couldn't always apply a full "no privilege" policy. That's only possible if the person in charge fully supports the policy. Working in teams that foster a privilege-based culture has been a frustrating experience, but it gave me the opportunity to gather interesting data. I had a chance to A/B test policies. In almost 20 years of data collection, I observed that privileges have no effect on the amount of incidents. Moreover, the people making "big mistakes" were most times the most senior in the team. The same people that would have had the privileges to perform the task anyway if there had been a policy.
Before moving on, I must address a point of confusion that often comes up in conversations around this topic. The word "privileges" has a technical meaning too. Think about granting permissions to drop tables on a database. So I often run into the argument that "no privileges, no elites" isn't a practical approach. The critique comes from focusing on two things:
- Understanding "privilege" as a technical word.
- Ignoring the "no elites" part.
This section is in a chapter called "Culture", and that's my point. There are valid technical reasons to restrict permissions, access, and so on. Often enough, there are even legal reasons to do so. That's not in contrast with "no privileges, no elites". The point is that there are no good cultural reasons to have privileged team members. Those are the ones you want to avoid.