Minimum Viable Bureaucracy: Practicalities

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:

1. Introduction
2. Scale, Chaordic Systems & Trust
3. Practicalities
4. Problem Solving and Decision Making
5. Goals, scheduling, shipping
6. 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.