Tag: organisations

How to build an architecture of participation

Posted on March 9, 2017 by Doug Belshaw

Back in 2014, when I was still at Mozilla, I wrote a post entitled Towards an architecture of participation for episodic volunteering. I bemoaned the lack of thought that people and projects put into thinking through how they’re going to attract, retain, and encourage the volunteers they crave.

‘Architecture of participation’ is a term used to describe systems designed for user contribution. It’s a term I use relatively often, especially at events and thinkathons run by our co-op. Not only is it a delightful phrase to say and to hear, but (more importantly) it’s a metaphor which can be used to explore all kinds of things.

In my 2014 post, I made some suggestions for ways to improve your project’s architecture of participation. I’ve updated and improved these based on feedback and my own thinking. Based on my experience, to build an effective architecture of participation, you need:

A clear mission – why does this project exist? what is it setting out to achieve?
An invitation to participate – do you have an unambiguous call to action?
Easy onboarding – are there small, simple tasks/activities that new volunteers can begin with?
A modular approach – do volunteers have to commit to helping with everything, or is there a way which they can use their knowledge, skills, and interests to contribute to part of the project?
Strong leadership – do the people in control of the project embody the mission? do they have the respect of volunteers? have they got the capacity to make the project a success?
Ways of working openly and transparently – does the project have secret areas, or is everything out in the open? (this post may be useful)
Backchannels and watercoolers – are there ‘social’ spaces for members of the project to interact over and above those focused on project aims?
Celebration of milestones – does the project recognise the efforts and input of volunteers?

Most of the links I can find around architectures of participation seem to be tied to Web 2.0 developments pre-2011. I’d love to see a resurgence in focus on participation and contribution, perhaps through the vehicle of co-operativism.

If you’ve got another couple of features that lead to a positive and effective architecture of participation, I’d love to hear them. Then this can be a 10-point list! As ever, this post is CC0-licensed, meaning you can do with this whatever you like.

(Image drawn by audience members during a keynote I gave at Durham University in 2015)

On ‘Kit Builder’

Posted on May 19, 2014May 20, 2014 by Doug Belshaw

Note: this is one of those blog posts where I use one thing as a convenient hypocrisy to talk about another thing. Kind of like Jeremy Clarkson’s car reviews, I guess. If you just want to get to the meat, check out my very talented colleague William ‘FuzzyFox‘ Duyck’s new pre-alpha Webmaker prototype: Kit Builder. The rest is tangential, to say the least.

I’m increasingly convinced that there’s a gaping hole that someone will soon fill when it comes to organisational effectiveness. Before I describe that, I need to talk about some of the basic technology-related things that organisations need in this day and age in order to be effective.

OK, so I’m simplifying massively for rhetorical effect, but here’s three things I think you can’t do without – no matter what size of organisation you’ve got. These may be more formal or less formal, but you need them unless you plan to descend into chaos.

1. Issue tracker

I wrote about this in a bit more detail in a recent post, but basically what I mean is that you need some way for people to raise ‘bugs’, ‘issues’, ‘tickets’ or whatever you want to call them, and get the whatever the problem is fixed.

Examples: Trello, BugZilla, GitHub

2. Resource tracker

Much as I hate the term ‘human resources’, I’m going to use it here because it’s useful. Other people in your organisation should know where things and people are. Or, if that’s not possible for whatever reason, they should at least know you (or a room’s) free/busy status. It’s all about co-ordination, really.

Example: Google Calendar, Basecamp

3. Knowledge base

The best organisations I’ve worked in have had wikis. It’s all very well knowledge residing ‘in networks’ but that does build new knowledge. That only comes when a community (not a network) of people come together to intentionally build something. That’s where the magic happens. You don’t have to use a wiki, of course, but that’s what I’ve seen work best, time after time.

Examples: PBworks, Mediwiki

So, coming back to the ‘gaping hole’ I mentioned earlier, what do you do when one organisation has all of this in place, and another one doesn’t? Or… even if both organisations have adequate systems, but those systems don’t ‘talk’ to one another. At the moment, that’s where the friction comes, and that’s why there’s well-paid people all over the world who are friendly ‘go-to’ people and help paper over the cracks of relationships between organisations potentially fraught with misunderstandings.

You’ll not hear me say this often, but what we need is a technical (but simple) solution to this mess. A way in which organisations can work together for unspecified periods of time without causing problems, resentment or internal issues for their own setup. I guess it’s a kind of souped-up version of what Jon Udell was trying to achieve with the Elm City project.

What we don’t want are de facto standards like “let’s just all go 1:1 with iPads!”. Or, why don’t we all use Microsoft Office! Or even, “everyone should use Google Apps!”. We tried that, folks. It fails.

But what on earth has this got to do with Kit Builder, a pre-alpha prototype for educators who want to make teaching kits? Well, I’m getting to that. Let me just make a quick point about ‘means of production’ first.

As Marx didn’t write, but someone on Wikipedia helpfully did:

The means of production can be simply described as follows: in an agrarian society the soil and the shovel are the means of production; in an industrial society, mines and the factories; and in a knowledge economy, offices and computers. When used in the broad sense, the “means of production” includes the “means of distribution” such as stores, the internet and railroads.

I’m butchering Marx’s work here, but the point I’m trying to make about Kit Builder is that it’s not just another capitalist company offering you a proprietary silo. Even in pre-alpha, it’s a pretty straightforward way to create high-quality resources. You’re in control of everything. You can copy and paste the HTML into Notepad, for goodness’ sake.

Once you’ve created a resource using Kit Builder (or Webmaker in general), you get all of these benefits:

Hosted on the web (accessible everywhere)
Remixable (by anyone)
Open format (can be used on any system)

I wasn’t sure how to put this as a bullet point, but you also don’t get the crazy situation where Sue has one program which spits out files that are incompatible with Bob’s program. And, because there’s no downloading/uploading of files, we don’t end up with filenames like:

Billy's presentation FINAL (use this one!) NO THiS ONE (final version) v2.ppt.docx.pdf

At the moment the text boxes in Kit Builder require you to use Markdown to format your text. I’d suggest we keep this as a feature. Markdown is a human-centric way to enter text that is then rendered as a web page. It’s easier to understand if you realise that HTML stands for ‘HyperText Markup Language’ and is machine-readable code for rendering web pages. Markdown on the other hand, is much more human readable, and allows you to include arbitrary HTML if necessary.

I’d very much encourage you to explore Kit Builder. If there’s one thing I’ve learned from my 18 years on the web so far is that open wins the long game. Shiny, pretty closed things come and go, but if you’re in it for any period of time, bet on open. And if you need to level-up your skills, don’t just sit on your hands, join in with Webmaker Training.

And finally, if you’ve got a way to build something that talks to lots of different systems and provides a human-readable layer, please do it. Do it now.

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.