Open Thinkering


Tag: Leadership

No management but self-management

The robber of your free will does not exist. (Epictetus)

Eylan Ezekiel shared a Twitter thread (single page) with me recently from former monk Cory Muscara. In the thread, Muscara explains that he meditated for 15 hours per day for six months with one of the toughest Buddhist monks on the planet.

To me, one of the overarching themes of the 36 things he shares in the thread is that you can’t outsource self-management. I’m a world away from the level of meditation and discipline that Muscara details, but my background in philosophy, a lifetime of self-reflection, and some therapy have enabled me to get to a stage when I mentally flinch (and almost physically recoil) when some refers to another human being as their “boss”.

Despite the existence of HR departments in larger organisations, humans are not ‘resources’ to be ‘managed’. We live in a world with many problems, but also one of abundance. The biggest problem that seems to plague people and organisations across the world is one that is often referred to as ‘time’ but which, upon further investigation, often turns out to be ‘prioritisation’. We all, after all, have the same number of hours in a day.

The ability to make decisions is almost like a muscle; it withers without practice. When we employ individuals to make choices that affect others (instead of collaborating on a process), we create systemic bottlenecks. I’ve always felt constrained when working as an employee, finding that people making decisions that affect my practice are often one or more steps removed from the thing under consideration.

This is not an argument against expertise or experience. In fact, it’s the opposite, as often the people with the most relevant understanding of the situation are those closest to the problem. Finding ways for them ask for relevant input and come to alignment isn’t a problem that requires hierarchy as a solution, but rather one that requires collaborative processes.

Last week, I helped facilitate as a group of people without a clear hierarchy came to a decision to form a new organisation. The process we used was one that I’ve discussed here before and which we use at WAO: consent-based decision making, or Sociocracy. I understand that hierarchy is the ‘default operating system’ of how groups of people organise themselves, but it doesn’t make it the best.

We now live in a time where people, across arbitrary borders can collaborate with one another using technology tools that are increasingly prosaic. They can make decisions without hierarchy using consent-based decision making processes. And they can raise and disburse money through platforms such as Open Collective.

The idea of a ‘boss’ is a collective fiction. We can and should do better. Of course, we need leaders but that’s an entire other post…

Minimum Viable Bureaucracy: Why have managers?

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:

  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 Laura’s talk and you should find the part relating to this post below. The slides are here and everything is backed up at the Internet Archive. [display_podcast]

“Enable your people to achieve mastery, have lots of autonomy, and work towards a purpose – and you will do well.”

(Laura Thomson)

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:

  1. Recruitment – make sure you have enough of the right people working on your team.
  2. Transmit culture – once you have the right people you need to support and guide them in the culture of your organisation.
  3. 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.
  4. 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.
  5. 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.

Servant Leadership

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):

  1. Listening
  2. Empathy
  3. Healing
  4. Awareness
  5. Persuasion
  6. Conceptualisation
  7. Foresight
  8. Stewardship
  9. Grow people
  10. Build community

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:

  1. What are you working on?
  2. What’s blocking you?
  3. 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

Yellow umbrella 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 a 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
  • Delegate effectively
  • 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:

  1. Mastery – people should be allowed to become masters of their domain. Let them get good at stuff and learn new things.
  2. Autonomy – people should have control over what they’re working on.
  3. 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.

Image CC BY-SA Christoph Michels

You can follow Laura Thomson as @lxt on Twitter. A final thanks to her for the clarity of her ideas, and giving me enthusiastic feedback while writing up her talk!

Minimum Viable Bureaucracy: Goals, scheduling, shipping

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.

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 Laura’s talk and you should find the part relating to this post below. The slides are here and everything is backed up at the Internet Archive.


“If something doesn’t work, just change it.”

(Laura Thomson)


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.

Some examples:

  • Create prototype – MMVP (minimal Minimum Viable Product)
  • Decide changes to ship
  • Get it deployable
  • Ship MVP
  • Ship v2
  • (etc.)

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:

Waterfall chart

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

Emergent processes

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.

You can follow Laura Thomson as @lxt on Twitter.