Minimum Viable Bureaucracy: Scale, Chaordic Systems & Trust
Recently I came across Laura Thomson’s excellent talk on Minimum Viable Bureaucracy. This is the first in a series of posts writing up Laura’s ideas. Everything in this post should be attributed to her, not me (except if I’ve made any mistakes!)
Posts in the series:
- Introduction
- Scale, Chaordic Systems & Trust
- Practicalities
- Problem Solving and Decision Making
- Goals, scheduling, shipping
- Minimum Viable Bureaucracy: Why have managers?
I chopped up the audio from her talk; you should find the two parts relating to this post below. Slides are here and it’s all backed up at the Internet Archive.
[display_podcast]
Scale
As organisations grow you experience pain.
(Laura Thomson)
When you’re working on your own you don’t need formal processes or things written down. The first pain point you experience is when you’ve got one other person working with you. The second pain point is at around 50 people: that’s when you stop knowing what everyone else is doing. A third pain point comes at 150-250 people where you don’t know everyone’s names. Then around 1,000 there’s a pain point where you say “should we behave like a big company or not?” That’s kind of where Mozilla is now.
Organisational growth is a like scaling a Web app in that the technology you use depends on the number of users you have. Every so often you get to a phase change point and you have to rethink the way that you do things.
Dunbar’s Number is the cognitive limit on number of people with whom you can effectively maintain relationships. It’s supposedly based on the size of part of the brain, with a relationship between species and the size of their minimum cultural unit. Dunbar’s Number says that humans can maintain relationships with around 150-230 people. Laura thinks there’s tools and practices that can increase this number – structuring your organisation so it’s remote and distributed makes that number “a whole lot higher”. Mozilla has ‘dodged’ Dunbar’s number until it reached about 500 people.
Chaordic System
A ‘chaordic’ system is:
any self-organizing, adaptive, nonlinear complex system, whether physical, biological or social, the behavior of which exhibits characteristics of both order and chaos.
(Dee W. Hock)
Chaordic systems have order, but this is not imposed. It’s emergent order from the way we do things and very typical of Open Source projects. Chaordic systems tend to be robust, distributed and failure-tolerant. In fact, chaordic organisations mirror the Internet itself.
People from more corporate organizations than Mozilla say they need processes, paperwork and meetings to “get things done”. Laura says she always asks those kinds of people how many Open Source projects they’re familiar with and what processes they use. It’s usually a lot lighter – e.g. Apache.
Instead of having ‘all your ducks in a row’ the analogy in chaordic management is to have ‘self-organising ducks’. The idea is to give people enough autonomy, knowledge and skill to be able to do the management themselves.
The above is a cartoon version of organisational charts, but Laura says “there’s a lot of truth in this”. Mozilla, she believes, sits in amongst this – “we’ve been more Facebook-like but are getting more Google-ish.”
Trust
If you want self-organising ducks you need to start with trust. Laura mentions that an interesting book about this is The Field Guide to Understanding Human Error by Sidney Dekker, which is actually about plane crashes. Dekker focuses on post-mortems and how to discover how things go wrong when they go wrong. One thing he talks about is how pointless it is to assign blame. No-one goes out of their house in the morning trying to do the worst job they possibly can. They might do a bad job, but they don’t set out to do one. We should start with that, says Laura: when people behave that way at work, they do so for a reason. People don’t act randomly, and tend not to act in an evil way. We should assume that it’s the best they could do with the knowledge and skills they had at the time. That’s the basis of trust in your organisation.
Trusting people helps you stop saying things like “I’d be able to get this done if it wasn’t for IT”. It’s best to step back and ask why IT is acting like that – is it (for example) because they don’t have the resources?
The key thing for building trust is time. We tend to like people to ‘earn’ trust, but Laura encourages people to step back and get people to earn trust in the hiring process. “Once you’ve decided you want to hire someone, you should by default trust them,” she says. Once you’re in, you’re in. You can build trust “by making many small deposits in the trust bank” which is a horse-training analogy. It’s important to have lots of good interactions with people so that one day when things are going really badly you can draw on that. People who have had lots of positive interactions are likely to work more effectively to solve big problems rather than all pointing fingers.
There are two things Laura recommends you can do to build trust in your organisation:
- Begin by trusting others
- Be trustworthy
Don’t commit to things you know you’re not going to be able to do. Be reliable. Show up on time.
Trust should scale within an organisation: if you’ve hired someone then I should trust your decision instead of trying to second-guess them. Once you’ve got trust in an organisation you enable autonomy. This means you don’t feel like you have to micro-manage staff or have lots of meetings. It means leaders can have larger teams. Also, when you give people autonomy they are instantly happier. Nobody likes people looking over their shoulder all the time. You want to be trusted to do your job.
Having worked in schools, a university, and now a tech company, I can see universally-applicable lessons here. What do you think?
You can follow Laura Thomson as @lxt on Twitter.
