TL;DR: I’m working on creating a Community Alignment model (name TBC) that sets out some of the ways I’ve had success working with diverse stakeholders to ship meaningful things. I’ve started work on this on my wiki here.
Just as my continuum of ambiguity is a fundamental part of how I approach life, so I’ve got a default way of working with communities. I’m working with City & Guilds at the moment and realised that it’s actually quite difficult to articulate something I take for granted.
As a result, I’ve started working on a guide to an approach that I’ve found useful for some kinds of initiative. It’s particularly useful if the end product isn’t nailed-down, and if the community is fairly diverse.
I’ve taken a couple of hours today to write the initial text and draft some diagrams for what I’m initially calling a Community Alignment model. Your feedback would be so valuable around this – particularly if you’ve been part of any projects with me recently, or have expertise in the area.
This is my last post writing up Laura Thomson’s excellent talk on Minimum Viable Bureaucracy. I’ve added the audio from the Q&A session below, but this text is taken from the final section of the talk entitled ‘Why have managers?’ Laura is the one who should be credited with all of the ideas in this post, whereas you can blame me for any mis-intepretation and random sentences I’ve added in italics. Posts in the series:
“Enable your people to achieve mastery, have lots of autonomy, and work towards a purpose – and you will do well.”
No such thing as a structureless organisation
There’s a lot of stuff at the moment about ‘programmer anarchy’, ‘structureless organisations’ and companies who say that they don’t have any managers. Laura thinks that we should at least acknowledge that we do indeed have them. If you work at a place that doesn’t have ‘managers’ there will, nevertheless, be people who make decisions. In other words, there are still people who lead – even if there’s a lot of them because you’ve got very small teams. Leaders emerge. Think of Open Source projects, there are people who make decisions and they elected themselves. There is a structure, there are people in charge. You can call these people whatever you want, but at the end of the day there are people who organise stuff. There’s a blog post by David Eaves where he refers back to a feminist paper from 1970 called The Tyranny of Structurelessness that discusses the feminist groups that wanted democractic, emergent organisations with no leaders. Guess what happened? Cliques emerge and there’s lots of politics; you end up with people in charge and ways of doing things that “just kind of happened.” There’s always an emergent structure and always someone with power in any group. One of the things to think about in any structureless organisation is: “do we want this to be unguidedly structureless or do we want to have some input into the direction in which it emerges?” In other words, let the organisation have an emergent structure, but intervene if we see that it’s emerging in an obstructive direction. Some examples of where you might see this in action. If you’re on any mailing lists or newsgroups there are people who lead and people who follow them. People who decide what the social norms and morays are. It’s the same thing with Open Source projects and ‘structureless’ organisations. If you’re a structureless leader, here are your jobs:
Recruitment – make sure you have enough of the right people working on your team.
Transmit culture – once you have the right people you need to support and guide them in the culture of your organisation.
Mentor people – make sure people understand the culture of the organisation “in their bones”. An example of this at Mozilla is being as open and transparent as possible: challenge people who make things private and ask them why it couldn’t be public.
Big picture – it’s easy for people to have their heads down amongst the weeds and not see how everything fits together. You might know, for example, that another team is blocked because of something way down on someone’s priority list.
Do things no-one else wants to do – go to meetings, do the paperwork, file bugs and close the bugs that no-one else want to touch.
The Servant Leadership Model (Greenleaf, 1970) says that you shouldn’t become a leader because you want to be in charge of things. You should become a manager because you like people and you like enabling people to be great. One of the things when you’re becoming a manager or a leader for the first time is giving up doing things yourself. For example, realising that it’s more important to unblock and enable others than it is to get your own work done. As a footnote, Laura says, you shouldn’t stop coding (she comes back to why). A lot of people think that introverts cannot be managers or leaders, but that’s a “really interesting mistake to make”. At Mozilla the place is full of really good introverted leaders. Introverts make great servant leaders. The 10 practices of servant leadership, as identified by Regent University (August 2005):
This doesn’t look like a list of qualities of a traditional manager, but it does look like the leader of an Open Source project, says Laura. For example: build community, grow people, steward the project. Have some foresight about where we’re going. Conceptualisation is about understanding the big picture. Be able to listen to people, have empathy for them, help them through the hard times (healing), know what’s going on (awareness), be able to persuade people. These things are very important – especially in a company like Mozilla.
Why you shouldn’t stop coding
The reason you shouldn’t stop coding (or doing whatever it is the rest of your team does) is because of a point Dave Mandelin makes in a blog post called The Glue Person. Enabling is more important than coding, but if you never write any code then you will not be as good a manager of coders. You have to understand why things are hard. It will also make it harder to find your next job if you do nothing but manage: they’ll put you through a whole bunch of technical interviews and you won’t know the answers. As a manager that codes, there’s stuff you shouldn’t do. You shouldn’t do anything on the critical path and you shouldn’t put yourself down to do things that block other people (because you might not have time). Think of yourself as the ‘glue person’. Write that script that needs writing; do a bit of innovative/experimental stuff. The classic example is the bug that’s gone unfixed for five years. Focus on things that aren’t really important to fix, but would be nice to have. As a manager you should have 1:1s with people on your team. Laura asks three questions:
What are you working on?
What’s blocking you?
How can I help?
…and then shut up. It’s import not to turn this into a status report. And you can spend the whole time talking about your dogs if you want to, because that’s “putting money in the trust bank”.
Other roles you have as a manager
Another role that managers have is as a “shit umbrella”. If you work for a large or bureaucratic company there is a lot of ‘process’ and one thing engineers hate is process. They don’t want to go to meetings. They don’t care about filling out paperwork. They just don’t want to pay attention to that stuff. Your job as a manager is to keep this from raining down on your team. Even in a low-bureaucracy organisation there’s always something so anything you can do to shield your team from that will make them happier. All managers have to be marketers. You raise the visibility of your team and the projects they’re working on. You want people outside the team to think: “that’s a cool team to join; I would love to work on that team”. If you’re trying to sell consulting team you’re trying to get people to think how smart you are so they want you to work on their stuff. If you make products, it doesn’t hurt for people to think that your company is cool. Think about the cool tech companies you know. If one of those companies came out with a new product then you’d look at it, right? You want to use the stuff that they make because the stuff that they make is cool. It’s really important to market your team in this way. If you do this well your team will have strong morale and a really strong tribal team identity. This makes people happier. Other things you have to do:
Challenge people enough but not too much
Help people figure out where they want to go
Help people when they stumble
Stretch people but don’t do it to the extent that they get demotivated and miserable because they don’t know what to do. It has to be hard enough. On the whole, though, managers tend to under-challenge people. At Mozilla, we give interns real things to do that are hard. And they end up doing an awesome job. Never underestimate people. This last point on the list about helping people when they stumble is a really hard part of the job. In some management talks this might be called ‘discipline’ or ‘performance management’ but Laura insists on ‘stumbling’. One thing that goes unacknowledged is that we don’t have ‘good performers’ or ‘poor performers’, we just have people. “Even people who are really strong performers have times when they’re not very performant,” says Laura. You might be the best engineer at Mozilla but if you come down with a health condition that makes you really miserable, or you have your first child, or some other kind of problem, then you’re probably not going to be as awesome as you were the month before. There are reasons that people perform at different levels at different times. Sometimes it’s because they’re bored, or burned out. Depression is a big one: if you plotted ‘bugs closed’ vs ‘seasons’ you’d notice that people write less code in the winter. Also, people have crises. Laura says there’s a difficult group to manage she labels ‘cruisers’. People who were smart at school and knew how to do their homework because they knew that stuff already. They’ve cruised through college and got to their job without ever really having to work that hard (and she includes herself in this definition). Suddenly they get to the job where they do have to work hard and ‘knowing how to work hard is actually a skill that some people don’t have’. So enabling people to learn this is really important – especially ‘cruisers’ as they’re often really smart people. In talking to them you should tell them that you know they can excel, you just need to work with them to show it. You can’t fix everything as a manager. You can’t fix depression for them, for example. But you can help them fix it. You can direct them to get help, to resources, or if they’re working on something that they hate you can find them something to work on that they like better. You can shuffle people around. If someone is really, really miserable, then Laura is a strong believer in asking whether they’d be happier working somewhere else. This isn’t sacking people, but bluntly having a conversation centred around the question: are you sure this is still for you? The last thing is that Dan Pink wrote a book called Drive in which he said there are three things that make people happy at work:
Mastery – people should be allowed to become masters of their domain. Let them get good at stuff and learn new things.
Autonomy – people should have control over what they’re working on.
Purpose – people are more motivated when they’re working on something they think is important.
Laura says if people take one thing away from the whole talk about how to lead, then enable your people to achieve mastery, have lots of autonomy, and work towards a purpose – and you will do well.
This is another post on Laura Thomson’s excellent talk on Minimum Viable Bureaucracy all about the section she entitled ‘Goals, scheduling, shipping’. You should credit Laura with all of the ideas in this post, apart from comments that I’ve added in italics.
Laura assumes everyone’s read The Lean Startup and the idea of Minimum Viable Product (MVP). She encourages people to apply this to everything. Literally everything. Make the smallest thing that could possibly work and iterate on it: not just in architecture or software, but in your processes and your company org chart.
You have to push back really hard to get to this because so many people are perfectionists. There’s a spectrum between purists on one end (“we want to ship the best possible thing”) and pragmatists on the other (“we want to ship it now”). You need a balance of both kinds of people on a team: if you have all purists they will never ship, and if you have all pragmatists “they will ship a steaming pile of crap”.
Why does estimation fail?
We’ve all worked on projects that went over a deadline. The thing is we know that up-front estimation (‘waterfall’) approaches are worse than agile-type approaches, but we don’t really know why. Laura’s opinion is that “agile methodologies are a way of secretly admitting that estimation is always wrong”.
It’s not too hard to estimate how much work you can do in the next 24 hours, or two weeks or six weeks, but it’s pretty hard to estimate how long something that’s going to take over a year is going to take altogether. There’s an old saying that “a one-week project takes three weeks, a three-week project takes three months, a three-month project takes six months, and a six-month project takes forever.” It will never ship. The goal, says Laura, is to break things down into small enough pieces so that you can do it in a reasonable amount of time.
Why do projects fail?
Here’s this huge thing that we want to ship:
So you build the project plan and then bask in smug self-confidence: it’s written down so therefore it must be true. This, of course, works really well until your project goes off the rails. The thing that’s wrong with the plan is that you didn’t know enough yet when you wrote it. All kinds of things happen over the course of the project that you don’t know about. For example, Thing 5 on your project plan turns out to be infernally difficult and to ship that item you have to come up with an optimal solution to an NP-complete problem. Or Thing 4 depends on someone else’s team – who have more important things to do.
Everything about Minimum Viable Bureaucracy so far is about bottom-up, emergent and chaordic systems – they’re grassroots and self-organising. Estimation, on the other hand, is by its very nature top-down. It’s somebody from a programme management office saying “this is how long I think this is going to take”. These two things are inherently in conflict.
There are some things you can try to resolve this tension – and the risk of trying something different is really low, because if you’re wrong 100% of the time, it doesn’t hurt you to try something else! Laura proposes anti-estimation. For example, if someone asks if her team can build something in the next quarter (of a year) she replies “Nope, because I don’t know what that is, but we can go away and investigate and at the end of the quarter tell you how hard it’s going to be.” Instead of writing a project plan, her team will build a prototype of what they think is the hardest part, because that’s the bit that’s going to take the longest. By doing this they get a much better feel for how hard the project is.
When you’re prototyping something like this you should set a timebox for it, “we’re going to build as much of a working thing as possible in this amount of time and then we’ll stop and think about it.” The same goes with writing a specification: take two weeks and talk to everybody and write down as much as you know. And with shipping: commit to shipping every week whether it’s perfect or not as long as the thing that’s being shipped it good.
There is a tendency in all of us to say “yes, I can do that”. Part of this involves looking at the five things on a project plan and starting with the four things we already know how to do. Laura says we should start with the unknown – putting the risk right upfront. Then we can iterate. If someone asks you to estimate how long something will take that you don’t know anything about say “no”. This is particularly important for consultants as if they say it’s going to take 30 hours and it takes 600 hours then “you have just worked for McDonalds wages”.
Laura proposes the idea of ‘never-done-ness’. No system is ever done – unless we decide to throw it out and replace it (in which case the new thing is never done). Everything is always in a state of growth and you have to constantly push back about this with your team. So with the perfectionists you say that the team is not going to build the whole awesome thing in one go, but break it into chunks and do a really good job on them before shipping them. And the next iteration is Awesome Thing Part 2. Aim for micro-quality rather than macro-perfectionism.
Another thing you should do is ruthlessly murder scope-creep. Laura’s favourite phrase is, “not in this iteration”. Doing small, frequent iterations means that:
You get better at shipping (and everything involved) – you have to automate things because you don’t have a choice
It takes less time to get things from idea to execution
Your team gets better at improving products
People whose work is blocked won’t be blocked for as long
Perfectionists are happier because they know the next iteration is coming soon
It’s as important to iterate on your processes as it is on your product. “If something doesn’t work, just change it.” Don’t say you’ll do it ‘one day’, fix it now! Talking about it takes more time than doing it. Start with what can be fixed today before you go home and “use dividends from small improvements to put down payments on larger improvements.”
Don’t aim for perfection: just change one thing at a time and try to make it better each time. One of the things Laura says to people is, “Everyone makes mistakes; one of my personal goals in life is to make different mistakes each time.” Make novel mistakes.
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.
Self-organising does not equal democracy. Just because no-one is in charge doesn’t mean everyone has an equal vote.
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 notstructureless.
“You should never have all of your time filled with things that other people have made for you to do.”
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.
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).
Communication practices are called practices for a reason.
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
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:
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.
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!)
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.
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.”
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
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?
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.
I’m a believer in them because I think that innovation is predicated upon standardisation. In other words, routines afford us the spare capacity to think about things other than (repetitive) tasks at hand.
Routines provide spare capacity by removing, or narrowing, choice.
Take my morning routine, for example. Granted, having children means that no two are identical, but every day I’m at work in the office at JISC infoNet Towers, I do the following:
Have a cold shower
Eat eggs (either scrambled on toast or an omelette)
Listen to the same ‘Train’ and ‘Walking’ playlists via Spotify (albeit on random)
Read Baltasar Gracian’s The Art of Worldly Wisdom on the train
Of course, it’s not necessary to have to undergo a commute to have routines. They’re just things you do at the same time and/or place.
So far, so obvious.
Routines gain power by becoming rituals. For example, there’s something about the first cup of coffee in the morning. It has a ritualistic element; it symbolises waking and the liminal space between home and work.
Whilst routines are easy to create and maintain on an individual level, rituals are slightly trickier. This, I believe, is because rituals involve gathering. It may be people who are gathered together, it may be thoughts. Rituals pull together and coalesce disparate elements.
Organisations and educational institutions are extremely well-placed to turn individual productive routines into collective rituals. One of the best places to start is often around food. At JISC infoNet we have a weekly Cake Club: the cake serves as a convenient hypocrisy for a kind of gathering we otherwise would not necessarily experience.
What kind of routines could you or your organisation turn into rituals?
I’ve been reading Reinventing Knowledge: from Alexandria to the Internet over the last couple of days. It takes an interesting approach, looking at intellectual history through institutions rather than individuals: The Library, The Monastery, The University, The Republic of Letters, The Disciplines, The Laboratory.
After I mentioned my belief that innovation is (generally) built upon standardization in a blog post about the Guardian Innovation in Education event, some people asked me for examples. I’m happy to say the book provided one in the shape of the medieval monastery:
By no means the only rule for monasteries, nor the oldest, nor the most innovative, [The Benedictine Rule] nevertheless achieved authoritative status on acount of its simple practicality and realistic expectations of the average monk’s capacity for ascetic discipline. Crafted for spiritual use, tested by time and repetition, and propagated by anonymous scribes, it bears a certain resemblance to the Christian scriptures themselves. Adhering to such a text enabled communities of monks to survive and thrive desipte the personal quirks and transient lifespans of individual members. In Benedict’s ideals and their evelopment in practice we see how monastic time played upon cycles of days, weeks, and years, endlessly repeating, to ensure the survival and stability of the monastery and of learning itself. (p.56-7)
The author continues a couple of pages later:
The genius of the Rule lay in the recognition that monks needed a specific regimen to make this spiritual goal an attainable reality. It was one thing to declare the entirety of one’s life, every moment, was to be devoted to God, another to know precisely what to do during all the minutes that followed sunrise, day after day. (p.59)
The idea of a platform for innovation, I think, is sound. It doesn’t really matter what the socially-negotiated/accepted base consists of, just so long as there is one to build upon. The best examples I’ve seen are a school where there was a workflow for everything, and my current employers where we have a team-constructed wiki that serves as a knowledge repository.
There’s an underground religion at work in every institution and most organisations. It’s something that pervades meeting after meeting and interaction after interaction. People everywhere are worshipping the Status Quo.
Whilst for those of a certain age this will immediately bring to mind an ageing rock band who can be seen in arenas worldwide miming their hits from a bygone era, that’s not what I’m talking about. The type of Status Quo I’m talking about is a nebulous force akin to what Steven Pressfield identifies in Do The Work as ‘The Resistance’.
The problem is that, unlike Pressfield’s quasi-religious (objective) malevolent force, Status Quo is a monster of our own creation which can, under the right conditions, spread like a virus. Status Quo is an idea. It’s a meme. And as with any successful meme it’s a shapeshifter, having a common core whilst being able to take on many different forms. The Status Quo is an unvoiced set of assumptions that allows new ideas to be dismissed by appeals to ‘common sense’ strong emotions.
Status Quo is manifested in many different ways and in many different places. In schools it might be the idea of desks in rows. In businesses it could be detailed branding regulations. In universities it’s possibly the physical location of students. However it manifests itself, the important thing to remember about Status Quo is that it’s the very thin layer, the crust, on top of a much deeper set of opinions, policies, prejudices and practice.
So if the question is ‘How do I change the Status Quo?’ you need to ask the associated questions: ‘The Status Quo according to whom?’ and ‘Why did this Status Quo take hold?’ Once you can answer these, you’re ready to do battle. You can’t win by fighting directly, only obliquely: presenting an alternate reality is the only way to win.
You replace one Status Quo with another Status Quo.