Prototyping Organisations
Organisations are technologies. They evolved to solve problems where humans must cooperate.
To survive, a business must find a way to sustainably make profit. The modern world being complex, means most businesses are multi-person organisations. Sustainable profit-making then is a coordination problem. It requires coordinating groups of people (and machines (and systems)) to produce, market, distribute and sell goods and services.
The problem of profit-making is the pinnacle-problem that businesses must solve. But that problem sits on top of a pyramid of other problems; problems that must be solved if profit is to be made. There is a fractal nature to the problems an organisation must address; from the general to the highly specific, highly local. Like Pratchett’s turtles, it’s problems all the way down.
Most of us deeply know that organisations are riddled with problems. Ricky Gervais knows this. Joseph Heller, Saramago, Camus, Le Carre and Orwell knew this.
We know this in our bones.
Organisations are a nightmare to navigate. They are even more terrible to manage. Management’s role is to make sure the profit-making machine is running and so to manage the pyramid of organisational problems stacked below. With lots of autonomous, emotional moving parts, this is not easy. To bastardise an entropy metaphor:
there are many more organisational configurations that don’t work than those that do.
So how to find them.
Design Thinking has a suggestion - organisational prototypes. An organisational prototype takes the concepts of prototype design that are usually applied to products and services and directs those principles to the design of organisations.
Org prototypes pose the question:
how can we make meaningful change with few people and a small budget, learn from it, then later scale that across the organisation?
The benefits of these prototypes are two-fold:
quickly create momentum behind change, and
evaluate that change without the existential risk of re-engineering the organisation wholesale.
Org prototypes are fast because they are small, and because they attract fewer political roadblocks.
There is no air of permanence to a prototype.
They are also constrained on the downside - if unsuccessful, damage is limited and disruption is kept to a minimal set of employees. If successful, the org prototype provides strong evidence for the change you are proposing. Proof-points on the road to bigger change. A catalyst for action at a larger scale.
Organisational Prototype Canvas
To design org prototypes, start with the Organisational Prototype Canvas. The canvas is a simple way to explicitly state what you want to change and how you’ll go about testing that change. It takes you through the process from defining the problem to outlining a solution and the simplest possible way to test that solution.
Start with the Problem.
We know that organisations are riddled with problems. But which problem do you need to solve? If you don’t know where to start - some root cause analysis may be in order. A judicious application of the 5 Whys.
To ground the experiment, we need to clearly articulate what is currently not-working. What is the problem that we want to solve?
To illustrate the process, I will take a very simple example. In practice, more complex problems benefit comparatively more from organisational prototype. Mostly due to the speed, and constraining the risk of large-scale upheaval.
Our example: a recurring problem one of my teams was experiencing was the existence of a consistent disconnect between Product and Engineering, particularly in defining what we should be working on. The problem: product and engineering are not aligned and it’s preventing us from delivering to our customers.
To get started with an organisational prototype, download the Org Prototype Canvas here.
Beyond knowing that the problem exists, you will have ideas of how to make this better. What is your belief or hypothesis about what might solve this problem.
We don’t need to outline the detailed solution itself - but what general change could nudge the organisation toward the behaviour that we want to see change. In my example, we believed that much of the misalignment was due to the separation of personnel.
To crystalise the design challenge, we package the problem and our belief in what could change into a design prompt. Formulate the problem as a "How Might We … " statement prepares us for brainstorming solutions. How might we create greater team cohesion between product managers and engineering teams?
What is this prototype.
With the problem itself clearly articulated we search for solutions to the problem. Brainstorm some ideas for solving the problem. The canvas allows for 4-5 prototype ideas, in general it’s a better idea to go bigger than this. When it comes to brainstorming quantity beats quality. Less is not more; more is more.
Having diverged to come up with solutions of all shapes and sizes, it’s time to get particular. Choose a prototype idea - the one that stands out as showing most promise.
Describe it in a sentence.
This single line will be how the prototype is pitched outside the group so put in the effort to make it snappy. Being clear and concise in the prototype definition will make it less likely that the prototype scope will drift in the remainder of the canvas and later on during implementation.
Our prototype. Physically embed product managers with engineering teams. We believed this would induce faster, more transparent sharing of information in both directions and that would be reflected in better product outcomes. We decided
Now expand upon that sentence. Flesh out the details of the prototype. Who’s involved? How will it work day-to-day? How will we know if it’s working? For us, that meant asking individual product managers to move desk. Our assessment of whether the experiment was working was based on three measurements - asking the product team, asking the engineering if it was working and asking a neutral third party to assess the level of output before and during the prototype.
Finally, let’s think in a little more detail about how this prototype can scale. If it’s successful how will we bring it to the broader organisation? Defining a Path to Scale early on, allows us to begin thinking ahead, to avoid testing prototypes that simply won’t scale beyond the experiment and allows us to prepare answers for senior leadership.
Who will test it.
Up until now, the org prototype canvas has peddled in the theoretical. The remaining two sections are the real details of the prototype. These real details will define how successful or unsuccessful the prototype will be. More importantly, it will determine how much we learn from the prototype.
The primary function of a prototype is not whether it is successful. It is how much we learn, and how rapidly.
Of course, arriving at a solution from the beginning is preferable than iterating wildly around a possibility space. But the key element here is to test the fundamental hypothesis - not the minutiae.
The first thing to pin down is who exactly will live the prototype. Who should live this prototype - and why are they the right group? We need to choose wisely. Often, who runs the prototype can be as important as what it is that we are testing. Depending on how optimistic we are we can have many choices here. More often than not, being opportunistic is the name of the game.
Choosing the group that can move most quickly and with fewest constraints and moving parts typically works well for first iterations. It also helps if the group views the prototype positively and doesn’t work to undermine it from the beginning. This isn’t a hard requirement but if it’s your first time implementing a prototype I strongly recommend it.
For the group that will take part - how much time will it take? Is this a week-long, or fortnight prototype? Is it full-time or does it make up a percentage of participants’ workday. - if so, how much? In our example, we ran the prototype for 6 weeks.
And finally, on a practical note, do all of the participants have permission and the required support to actually meaningfully take part in the prototype? One or two individuals with managers who actively oppose the prototype could invalidate the remainder of the experiment.
How will we run it.
Now we plan the prototype.
When should it start and finish?
What resources or conditions are needed? Do we need additional buy-in, space, new software licence, physical materials, etc. ?
How will we measure the impact?
What obstacles can we expect? How can we get around them?
On the ground.
With a prototype outlined, it’s time to keep that momentum up. Immediately, begin to share the plan with the teams involved. Incorporate their feedback into your design.
The prototype canvas is great for outlining what we want to do. Now it’s time to shore it up, lend it some weight. For very simple prototypes, where all the key stakeholders are present for the design - the canvas may be enough. For something more wide-ranging, a 1-page narrative document is a useful companion document. This is especially the case if there are many other parts of the organisation who may be partially, or indirectly impacted by the prototype. Signalling upfront that you will include this group in the shared learnings sessions often helps to build buy-in.
And remember, the primary function of a prototype is not whether it is successful. It is how much we learn, and how rapidly.
To get started with an organisational prototype, download the Org Prototype Canvas here.