(This article was originaly published on the Hack and Paint blog)
Disclaimer:* For the length of this post, we will draw analogy between companies and machines consisting of small parts. If you don’t like this analogy just substitute it with any of the following:*
- Company is Organism with Cells.
- Company is Ecosystem with Organisms.
- Company is Dependency Graph with Nodes.
- Or if you are functional programming fan — Company is a Program with Functions.
The point is — these are just semantics and they only help illustrate the point, so don’t get hung up on the over-simplification here.
A Company (like a Machine) has inputs and outputs. For example, Hack and Paint’s machine has inputs in the form of time (from people) and money (from our bank account). The output of this machine is a VR game. Anyone who is not part of Hack and Paint can look at Hack and Paint and draw the conclusion that it’s a machine that takes in money and time and outputs a VR game. Pretty straight forward. For someone outside the company that’s all the information they have— it’s a black box machine and what happens inside of the black box is unknown to them.
But for someone inside Hack and Paint, what happens inside the black box is hugely important because it affects not only them, but also how this machine produces VR games. It can produce them slowly, quickly, it can be optimized to spend resources carefully and still produce the same output. Or it can be functioning badly and it can spend all the resources without producing anything at all. How a machine operates is determined by it’s people and it’s culture. The people are the parts of this machine and the culture is the rules and the logic that the machine uses to operate.
So companies, like machines, consist of parts that also have inputs and outputs. In terms of Hack and Paint and because we use Holacracy to operate this machine, these parts are roles. So far we have a big machine with parts inside the big machine. On any given day, at any given moment a company takes thousands, sometimes millions of decisions. From something small and internal, like “how to name this variable” to something big and external, like “should we buy our competitor”. Decisions happen all around us, all the time. How these decisions are taken will determine if the company will succeed or fail. So good decision making is kind of a big deal.
Note: In self-managed companies an important principle is the principle of transparency. Which means that all parts in this machine are free to exchange information without restrictions. The freeer the information is allowed to flow between parts in machines, the better. If you try to design a machine without allowing it’s parts to share information, I can guarantee that it will be a poorly designed machine ;)
At Hack and Paint we have a role called “Rigger ” — and to oversimplify it, the input this role accepts is “unrigged 3D model” and it outputs “rigged 3D character”. You can take any role in our current company governance scheme and see very well what inputs that role (part in the machine) accepts and what outputs it produces.
So if the small “Rigger” part is given the required input — unrigged model, it very well knows what to do with it — to rig it. But sometimes these parts are given inputs they can’t really handle on their own or information gets to the part, based on which it needs to take a decision outside the scope of it’s design. For example the part gets information that the machine is missing another important part — Animator to animate the rigged character. For example the person that has the Animator role is no longer within the company, the role is on vacation, or otherwise absent. Which means any work done by the Rigger part will be a waste of time. Now the part has to decide if it needs to continue to work on the rig or to stop doing this work. So the input to that part is “Based on what you know — decide if you should rig or not rig the 3D model”.
Let’s explore 3 different scenarios to gain some perspective:
The part decides to process this input without notifying other parts
What happens when the part decides she can process this input and stops work on the character. If the part does this without notifying other parts in the machine that depend on this information, chaos can ensue. Suddenly a decision has been taken that requires information to be spread to other parts of the machine, but that didn’t happen. So you are left with someone working on a task that is directly affected by this decision and suddenly they are left working on something that isn’t relevant anymore — waste of time, resources and morale. So to program all parts in the Hack and Paint machine to process any decisions (inputs) that they are given, regardless of the nature of the decision, is a bit overwhelming. This won’t work. So work will continue without the right communication about decisions that have been taken and crucial parts of the machine will be left in the dark — very inefficient design for a machine, don’t you think?
The part decides to process this input and then notifies other parts for the decision
This machine design is a bit better than the first, but still not as streamlined as it could be. Here is why. The part decides what to do with the input — in this case, stop work on the tasks. Then it notifies other parts about the decision. The problem here is that some other part might have additional information that the first part was missing and say “Hey, why did you decide this without notifying us before hand? I know a solution how to progress even with the current situation of missing an Animator. You should have notified us PRIOR to making this decision.” Now the Rigger part is given information that they were missing before — that there is a way to progress, but the decision was already taken — so that’s just a bad timing.
The part decides to notify other parts for the situation and THEN take a decision based on their inputs
Clearly we need a rule to handle situations where a part is given an input outside the specification or scope of its design. For an even better machine design, we came up with a process called “The Advice Process”. With this design/process, the part in question will FIRST determine who will get affected by it’s decision, THEN ask for advice from the parts that will be affected, and FINALLY will be able to take an informed decision based on their inputs. In this design,information is sought before proceeding with important decisions, because it affects multiple parts and the machine as a whole. The principle here is to aim for decisions with consent (not to be mistaken with consensus) i.e. everyone effected has given their input (and therefore their consent) for the decision to be made knowing that all the necessary information has been shared. This is crucial, because if all the relevant parts are not involved in this decision, by being asked for their advice, those parts will feel disengaged from the work. This is really important and it is embedded in all self-management companies, in some way or another, because it is a very elegant way of solving some extremely common issues like:
- decisions taken without notice
- decisions taken without knowledge of the whole picture
- taking wrong decisions altogether
- disengagement from work
- bad morale
So now you have an insight as to how we use Holacracy and “the Advice Process” to oil every part of our machine in the hope to make it work as well and efficiently as possible. Self management is organic and constantly evolving and we hope to continue sharing our leanings with you along the way. Let us know your thoughts and share any experiences you’ve had in the comments below!