This is my fourth post on Laura Thomson’s excellent talk Minimum Viable Bureaucracy. In this one I’m focusing on the section she entitled ‘Practicalities’. All of the ideas in this post should be ascribed to Laura, apart from my random musings which I’ve tried to make obvious.
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 Laura’s talk; you should find the part relating to this post below. Slides are here and it’s all backed up at the Internet Archive.
[display_podcast]
Self-organising does not equal democracy. Just because no-one is in charge doesn’t mean everyone has an equal vote.
(Laura Thomson)
Decision Making
How do we solve problems in a chaordic environment? People coming from a traditional company might wonder how decisions can be made. The short answer is that subject matter experts emerge. People gravitate towards projects they’re passionate about and become experts in that subject.
The second part of this is that there shouldn’t be a single person who knows or can do everything – there should be a ‘failover’. You should actively fight against there only being one person who knows or does everything. After all, if that person gets headhunted by Facebook or hit by a truck then suddenly you’re left with something that nobody understands. Leaving it at this isn’t enough, however, as there are some things that nobody wants to do – e.g. running weekly team meeting. These things should be rotated so it’s not too much of a burden on any one person.
What do an OSS decision-making processes look like? Well, says Laura, they all tend to converge on a model that looks a lot like this:
This is a reasonable structure for decision-making in any context: have one person who knows everything with (more) other people knowing almost as much. Things get done this way.
Laura adds a note in parentheses to this: ‘self-organising’ does not equal democracy. Just because no-one is in charge doesn’t mean everyone has an equal vote. But then, on the other hand, nor does self-organising equal anarchy. Self-organising systems emerge and converge on a structure, but they are not structureless.
Problem solving
“You should never have all of your time filled with things that other people have made for you to do.”
(Laura Thomson)
Many architectural problems are like bikesheds, says Laura: they’re the thing you talk about over beers with the team or every workweek – but you never get around to doing. People have many different, possibly divergent ideas and think it’s too hard to get to a solution. As a leader, therefore, you should pick someone and give them a week to go away and have a go at it. Get them to see how far they get with making a prototype. The important thing to remember is not to leave them too long in isolation as they can go down “a hell of a rabbit hole”. It’s good to have a time box for this kind of thing.
Laura’s advice is that you that you should ‘come with code’ for bikeshedding problems. This means you can point to something and say “hey, I built this”. People who don’t like it will no doubt say that they would have done it differently but when it exists, it’s much easier to just agree with something. The problem then kind of goes away. Many of the hardest problems get to 80% by one person over a two-day marathon giving the project a proof-of-concept and some momentum. In turn, this gives other people motivation and clears the path.
The moral? Give people room to do this and be innovative.
Moving on, Laura says she sees some things that are “really toxic”. Things like having an innovation department where all the ‘innovative’ work is done. This is “silly”. Another management anti-pattern is giving engineers a number of tickets without giving the engineer space to think about the product. It’s true they may not understand the users, but they understand the product pretty well.
Depending on the company, a portion of time has to be spent by the engineer doing the thing that they think is most important. It might be 100% of the time, or 60%, 40%, one day per week – but it should never be zero. “You should never have all of your time filled with things that other people have made for you to do,” says Laura. There are so many reasons for this. One of them is you miss out on some of the most innovative ways of doing things. The second is that it’s toxic for engineering morale. It will make people leave. It’s a ‘super-critical item’.
This is true not only for engineers but for anyone in an pretty much any kind of organisation. Spending all day just implementing other people’s ideas doesn’t lead to a sense of agency or happiness.
In summary, there are three things to remember about problem solving in a chaordic environment:
- Push responsibility to the edges
- Adopt open source models
- Give people freedom to innovate.
For the things that aren’t ‘bikesheds’ figure out where the interfaces are. Interface design is more critical than component design. For example, your API is more important than the implementation, every single time. This makes everything more modular, allowing you to drop innovative things in more easily.
In non-technical language, this is about looking at how ideas and projects connect. This is important as it helps the organisation communication well internally and externally, helping things move forward smoothly.
Laura’s architectural goals:
- Decouple replaceable components
- Have clear interfaces and APIs
- Make sure you have good tests for each component
For operational problems within an open source environment, the same principles apply, with two additions:
- Evidence > guts
- Immerse yourself in problems
In other words, use evidence to make your decisions rather than gut feelings. And when you’ve got a problem, set aside time for you (or someone on your team) to be fully immersed in it and understand it.
You can follow Laura Thomson as @lxt on Twitter.
Images CC BY-SA Pierre-Yves Beaudouin & John Myers
![[INCOMING] #BelshawBlackOps13](https://dougbelshaw.com/blog/wp-content/uploads/2013/10/light-incoming-280x150.png)
