Is Self-Organisation a Myth?

Introduction

No, the title isn’t just clickbait, it’s a serious question. Early in my agile career I attended a meet-up where the speaker observed that “No-one is allowed to criticise agile, so it never gets any better”. Ironic eh?

So in the spirit of continuous improvement, I’m going to plough on and accept that I might be in for some outraged comments. And in truth I don’t think there’s a simple answer — hence the blog post!

When it works

Early in my career I certainly believed in self-organisation because I watched it happen. However, I failed to recognise why it worked and that those prerequisites don’t exist by default.

There were two conditions that enabled self-organisation:

1. Ownership — by luck rather than design we had a large number of people with a strong sense of ownership. They were proactive, they used their initiative and they took responsibility for making things happen. In addition, many of those people were strongly influential within their teams. They were respected and their peers were inclined to follow their lead.
2. Tech Team Leads — we had designated leads within the teams. The key word here is within — these people worked hands on alongside their teammates, they were not simply overseeing and managing. Creating these leadership roles meant there were clear expectations and accountability within the teams.

Since that early experience I have seen self-organisation fail more often than not which is why I’ve started to question it.

When it doesn’t work

Rather than self-organisation, what I see more often is that everyone is responsible so no-one’s responsible.

If you haven’t deliberately hired people with a strong sense of ownership, you won’t automatically have people that take responsibility for self-organising. What’s more, when you do have those people they don’t always have the necessary influence within their team. In other cases they lack confidence — in flat structures, people can feel taking the lead is overstepping the mark.

Making it work

So is self-organisation a myth? Not entirely — my early experiences proved that it is possible. The myth is that self-organisation will “just happen”.

Self-organisation can work, but we need to create the conditions to make it work rather than expect it to magically evolve. So how do we do that?

Google’s Project Aristotle set out to define what makes teams effective. Amongst the five characteristics they identified were:

• Dependability: On dependable teams, members reliably complete quality work on time (vs the opposite — shirking responsibilities)
• Structure and clarity: An individual’s understanding of job expectations, the process for fulfilling these expectations, and the consequences of one’s performance are important for team effectiveness.

To me these get to the heart of making self-organisation work. Dependability requires people to take ownership, not to “shirk responsibility”. Structure and clarity involves defining clear expectations.

Optimising for self-organisation means seeking out people with a strong sense of ownership. You can also increase ownership by holding people accountable — but that depends on setting expectations first.

In my experience, defining roles and responsibilities is a good way to set expectations. This avoids the trap whereby everyone is responsible so no-one is responsible. There is no one-size fits all here and your approach will depend on your organisation and culture, but one way or another, clear expectations and accountabilities have to be defined.

Some approaches that I’ve found helpful include:

Create Tech Team Leads

In less mature organisations I’ve seen this make a big difference fast. The key to this role is leading, not managing. It can include line management, but it doesn’t have to — I’ve seen it work well both ways.

As with any leadership role, you need to choose someone with good leadership qualities — this is about leadership not dictatorship. One organisation I worked with found that using the Team Lead title gave people a “God complex”. I’d suggest this was caused by poor choice of leaders rather than by the title itself.

Choosing good leaders may mean hiring for the role rather than promoting internally. If you consistently find that you lack strong candidates internally, it’s worth revisiting your recruitment and assessment process — consistently hiring people that lack leadership qualities is a problem in itself.

Creating the role is not enough. To set your leads up to be effective, provide a clear description of the role. What activities do you expect them to undertake or lead? What are they accountable for? Provide the “structure and clarity” that will set your leads up for success.

Define roles and responsibilities

An alternative to team leads is to take a similar approach but apply it to senior team members instead. As with team leads, set clear expectations by defining the responsibilities of the role.

One note of caution — where multiple team members share the same set of responsibilities this can lead once again to everyone being responsible and things falling between the cracks. To avoid this, senior team members will need to align and coordinate; if you don’t see that happen you may need to instigate it.

Use “rotating scrum masters”

Delivery is often an area of weakness in cross-functional teams because it is unclear who takes ownership for the team’s process. The answer is that, in a self-organising team, everyone takes ownership. In reality it is more common that no-one does.

Some organisations address this by using dedicated scrum masters or delivery managers. This may or may not lead to self-organisation — a team is not really self-organising if it relies on this dedicated support long term.

An alternative approach is to define a scrum master/delivery manager role which rotates around the team. The key here is that, as with any other role, it is clearly defined — activities and responsibilities are clear. When the role is undefined it becomes merely ceremonial.

Responsibilities vs accountabilities

In cross-functional teams, it can be helpful to define accountabilities versus responsibilities. For example, a Product Manager might be accountable for ensuring the team is creating maximum value, but she is responsible for the health and quality of the technical platform. Conversely a Principal Engineer or Tech Team Lead might be accountable for the health and quality of the technical platform, but responsible for ensuring the team is creating maximum value.

I find it helpful to define accountabilities and responsibilities as “leading” and “supporting”.

For example, the Principal Engineer would be accountable for identifying the need to upgrade a software framework, but the Product Manager is responsible for enabling that by making space for it on the backlog. That doesn’t mean the Principal gets what she wants by default — there should be a healthy push and pull to ensure the work offers some value and to define when it actually needs to happen. The key here is that a Product Manager shouldn’t be expected to identify the needs of the technical platform, but nor should they be able to evade responsibility for a healthy platform.

Define accountabilities and responsibilities across the workflow

Another approach I’ve used is to define the team’s end to end workflow, and work with the team to define who leads and supports activities at each step.

For example a Product Manager might lead a kick-off while the rest of the team supports this activity by attending and contributing.

Likewise a Tech Team Lead might lead a technical design session, while the rest of the team are responsible for supporting this activity by attending or being available to answer questions and provide clarification.

Hold people accountable

All the approaches outlined involve setting expectations in some form or other. But there is no point setting expectations if you don’t hold people accountable to them. An expectation for which someone is not accountable is optional…and an optional expectation is not an expectation!

Holding people accountable can be uncomfortable, but it cannot be shirked. Self-organisation devolves power to a team and with that power must come responsibility. A failure to hold people accountable is as damaging as failing to set expectations in the first place.

Conclusion

Self-organisation can work, but it doesn’t just happen. You need to create the conditions that enable self-organisation.

But why does self-organisation matter? Should we even care? It matters because autonomous working environments depend upon it. Empowering people to work autonomously leads to better products and services delivered faster. It also improves engagement. Working autonomously depends on self-organisation.

If we recognise the importance of self-organisation we can start creating the conditions to make it work rather than hoping it will evolve organically.

Are you looking to improve self-organisation in your business? I am a Business Agility Coach & Consultant helping organisations to grow, scale and deliver value fast.

Find out more at betterfasterhappier.com.