Tag: Laura Thomson

Minimum Viable Bureaucracy: Practicalities

Posted on October 14, 2013August 3, 2017 by Doug Belshaw

This is my third post on Laura Thomson’s marvellous 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 the fanciful interpretation of them (which is all mine – I’ve tried to make this 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 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]

Communication practices are called practices for a reason.

(Laura Thomson)

In the previous section of her talk, Laura talked about the importance of scale, chaordic systems and trust. In this section she’s focusing on implementing these ideas in practice. She starts by talking about the importance of over-communicate everything, especially if working remotely. Tell people what you’re going to do, what you’re doing, and then when you’ve done it (and, importantly, how it went). A good tip: if you have face-to-face or IRC conversation and others aren’t present, then you should document it for the benefit of the rest of the team. This is important in non-technical environments too. Keep people in the loop.

Encouraging a culture of collaborative note-taking allows for what Laura calls ‘asynchony’ – in other words “I shouldn’t have to be physically present in time and space to know what happened.” She points to a presentation by John O’Duinn that you can access here (PDF) Interestingly, John’s presentation focuses on the importance of having ‘groups’ of remoties and makes a case for ‘aqui-hires’.

If you’re working in an office and some members of your team don’t work from the same physical location then it can seem like a hassle to document everything, remember to invite them to meetings, etc. The important thing to remember is that remote teams allow organisations to hire the best people, regardless of where they happen to live. It might be a annoying for those that are physically co-located, but there’s a good reason for it (more talent in the organisation). Remote working is effective when there are good communication practices and there are high levels of trust. In the long run it’s best to get used to ‘remote’ ways of working as the chances are any organisation will end up having more than one office.

Moving onto effective communication practices, Laura suggests the following:

Shared communication spaces
Every project should have a URL
Some kind of chat system that has logging (IRC/Campfire, etc.)
Etherpads and wikis for collaborative document editing
Bug tracking
Email (secondary – after the fact documenting)
Record as many meetings as possible through video, audio or shared notes
Record decisions made

‘Bug tracking’ might seem like a specific issue for software development, but there’s many way bug trackers can be used for other things. As an example, check out this recent bug (#914343) for transferring the Web Literacy Standard from the Mozilla wiki to Webmaker.org.

It’s a well-known fact that many meetings kind of suck. Laura believes that, paradoxically, team meetings can actually reduce communication. They can be a bit like an annual performance review where someone says, “Hey Fred, you did a terrible job this year, in March you did this thing that sucked”. But then you wait until December to tell him about it. If something is important, don’t wait for a weekly team meeting to raise it. It’s not the frequency of meetings, it’s the culture: the ad-hoc, asynchronous nature of the interactions/communications.

If you turn up to a meeting and never say anything you probably shouldn’t go to it. Try replacing the idea of meetings with conversations about the following:

Collaborative problem-solving
Maintenance windows
Triaging bugs
1:1s
Show and Tell (people really enjoy doing these)
Post-mortems

If you have to have an actual meeting, make sure you have an agenda, a list of stuff you’re going to talk about (even if it’s just five bullet points). Limit the number of people at the meeting as “nothing good ever happened at a meeting with 20 people in it. Ever.” Limit the length. Try 30 minutes and if it takes longer than that, schedule another 30 minutes. And try to cluster meetings together – either all on the same day or same morning.* Record and take notes for asynchrony.

*This, of course, depends on shared calendars, which is a great habit to get into. You can share on a free/busy basis with most platforms.

When it comes to Minimum Viable (Project) Documentation, Laura’s advice is to aim for:

How to install code
How to make a change / submit code
What’s the roadmap (even a rough one for next week)
Changelog (version control systems often do this)
Glossary (helpful for new employees, interns, external contributors)
Where to get help (the most important)

Although this seems extremely software-specific, if you think about what these things would look like in your environment, it doesn’t take too much of a leap. Instead of ‘submitting code’ you could talk about ‘adding ideas’.

Finally for this section, Laura reminds us that it becomes more annoying to explain something for the tenth time to the tenth different person that it is to write it down. Documentation is important and saves everyone time.

You can follow Laura Thomson as @lxt on Twitter.

Minimum Viable Bureaucracy: Scale, Chaordic Systems & Trust

Posted on September 23, 2013August 3, 2017 by Doug Belshaw

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.

Minimum Viable Bureaucracy: Introduction

Posted on September 18, 2013August 3, 2017 by Doug Belshaw

We really are rather fortunate, aren’t we? I mean right now, as I write this there will be conferences all over the world taking place. And a good number of those, especially in my areas of interest, are likely to be livestreamed meaning I can (theoretically) follow along at home. But more than that, these live streamed sessions are often also recorded meaning that these talks can kept for posterity and used as learning materials in a course (like a MOOC).

The difficulty with the super-abundance of learning resources is that it’s difficult to know where to begin. It’s hard to know what’s worth paying attention to – hence the Web Literacy Standard (“here’s the things you should pay attention to if you want to get better at reading, writing and participating on the Web”). At Mozilla we have ‘brown bags’ every so often – talks that take place at a Mozilla office (often Mountain View) that are streamed out via Air Mozilla. As with any kind of event, some of these are of more or less interest to me and/or feature people who can present better than others.

Recently I my colleagues directed my attention towards a brown bag given by Laura Thomson entitled Minimum Viable Bureaucracy. It’s so good that, after giving the talk at OSCon Laura was asked if she could repeat it so it could be streamed and recorded via Air Mozilla. It’s an hour long so I’ve taken the video, extracted the audio and created a separate MP3 file from each section of Laura’s talk.

So what’s it about? What is ‘Minimum Viable Bureaucracy’ (MVB)? Well, as Laura rather succinctly explains, it’s the difference between ‘getting your ducks in a row’ and ‘having self-organising ducks’. MVB is a way of having just enough process to make things work, but not so much as to make it cumbersome. It’s named after Eric Ries’ idea of a Minimum Viable Product which, “has just those features that allow the product to be deployed, and no more.”

The contents of Laura’s talk include:

Basics of chaordic systems
Building trust and preserving autonomy
Effective communication practices
Problem solving in a less-structured environment
Goals, scheduling, and anti-estimation
Shipping and managing scope creep and perfectionism
How to lead instead of merely managing
Emergent process and how to iterate

I truly believe that MVB is an approach that can be used in whole or in part in any kind of organisation. Obviously, a technology company with a talented, tech-savvy, distributed workforce is going to be an ideal testbed, but there’s much in here that can be adopted by even the most reactionary, stuffy institution.

My posts writing up Laura’s ideas can be found below. The original talk is on Air Mozilla, the slides are on Speakerdeck, and there’s a backup of the slides and audio on the Internet Archive.

Also, you might be interested in following Laura on Twitter – she’s @lxt.

Image from Bonkers World