Making better decisions

OSOM builds upon and endorses a set of guides to better decisions known as "Wardley's Doctrine".

Simon Wardley's doctrine is a collection of patterns that were carefully researched from the world's most successful organisations, and have been used to evaluate and then underpin its approach to improving organisations, and ultimately to develop OSOM. OSOM refers to them as a set of guides to making better decisions.

The decision guides don’t inform us of the precise steps that need to be taken, but they do help us to understand how we’d prefer to see an organisation act: whether it’s assumptions being challenged freely and often, ensuring the user needs are focused upon, embracing uncertainty, or using failure as a tool, amongst others.

This text has been derived from Simon Wardley's writings on medium and in Wardleypedia

Communication

We want to ensure that people speak freely, using language everybody understands. We want to make sure that the factors that influence the environment we are in are understood when decisions are made, and we want to ensure that the way in which we make decisions is, in so far as is possible, open, transparent, and communicated clearly.

Do we use a common language?

A necessity for effective collaboration is a common language. If we use words that have different meanings to different people, or words that others don’t understand then we hinder our ability to work as an effective group.

Do we challenge assumptions?

It's a duty for everyone to challenge assumptions as they encounter them. Openly and honestly tell people when and why you think they are wrong. There is no place for ego if we want to learn.

Do we focus on having high situational awareness?

There is a reasonably strong correlation between awareness and performance so we try to understand the landscape that we are operating in and understand any proposals in terms of this. We look before we leap.

Do we have a natural bias towards transparency and openness?

We share what we're doing to allow others to challenge and question our assumptions. The act of sharing is essential because it helps us to learn, and transparency also requires us to remove the noise that gets in the way of learning.

Development

We want to make sure that we know who we're delivering to, and what it is that they need. We want to make sure that we're not repeating ourselves, or doing the same thing repeatedly, in slightly different ways.

We want to feel confident that your teams are able to use the most suitable methods for the task at hand - whether that is building a website or a data centre, and do we use the right tools?

We want to make sure that we're building only what is needed, and not throwing in the kitchen sink because we can!

Do we know our users?

Any value we create is through meeting the needs of others, no matter who they are.

Do we focus on user needs?

We'd like to create an environment where our needs are achieved by meeting the needs of our users. These needs will evolve due to competition and they may be uncertain, and we're aware that users may have different and competing needs so we're prepared to balance the conflict.

Do we remove bias and duplication?

We seek to remove duplication (i.e. building the same thing multiple times) and bias (building for ourselves that which is an attainable commodity).

Do we use appropriate methods in the appropriate places?

We try to avoid the tyranny of one. There is no magic solution and we have to use methods (e.g. agile or lean or six sigma) as appropriate. In any large system, multiple methods may be used at the same time. We are aware that tribes can form with almost religious fervour about the righteousness of their method, but we seek to rise above that and use the right approach, at the right time.

Do we focus on outcomes rather than processes?

We try to focus on what we're trying to achieve rather than a process or a contract. We know that sometimes we can achieve goals with teams of different types - sometimes on-site, sometimes remote, sometimes in-house, and sometimes via a third party.

Do we think Fast, Inexpensive, Restrained and Elegant (FIRE)?

We move quickly with a bias towards action; we use inexpensive components; we're frugal wherever possible; we simplify the problem as much as we can, and we build in small components, or we don't build at all.

Do we use the appropriate tools?

Mapping, modelling, logging, whatever. We build better things when we build with the right tools for the job.

Are we pragmatic?

There will always be edge cases or a way to make something more perfect but if what you're building can use a component that already exists then we try to avoid the urge to re-invent it.

Do we use appropriate standards?

If something is industrialized and if standards exist then we try to use them. There's always a temptation to build a better standard but we try to avoid this unless we have an extremely compelling reason to do so. If we need a toaster, we buy a toaster and we don't try building one from scratch.

Operations

After we've built things, we need to run them.

In this section, we'll consider the various guides that impact most strongly on our operations. Are we all over the things that we need to know about? Do we know why we are doing certain things in certain ways? Do we allow that there might be new and better approaches for things we're already doing?

Do we build the expectation of failure into how we operate? And do we try to set exceptional standards in everything we do?

Once something is running and working well, do we look to improve its efficiency so that it becomes less expensive? Or do we rest on our laurels?

Do we know the details?

We use small teams and break large landscapes into small services. We're don't back down by fears of the complexity of management or "too many interfaces to manage". We get under the hood of things and break them down.

Do we manage inertia?

We all display it. It's caused by past success. When we find ourselves saying "but this is how we do it" or "but this has always worked in the past" or "if it ain't broke don't fix it" then we question why we're saying this.

Do we manage failure?

In any system there is risk. We try to understand failure modes, what can go wrong and what will be impacted when a component fails. We try where possible to mitigate risks by distributing systems, by designing for failure and by the constant introduction of failure as a means of testing our response.

Do we prioritise effectiveness over efficiency?

We're careful not to waste valuable time making the ineffective more efficient. Instead, we replace it with something that works better.

Do we optimise flow?

Anything which gets in the way of meeting user needs, being fast, or preventing transparency on relevant information is treated ruthlessly. Whether it is with what we build or how we run it afterwards, we remove bottlenecks and improve throughput where possible.

Do we get better with less?

We strive to improve continuously. Do we set exceptional standards? We strive for the very best that can be achieved.

Learning

Building methods of learning into the organization is essential to improve our organization. These patterns lead us towards that.

When in doubt, we do something. Not because we know it is the right answer, but because it might be.

We try new things because otherwise, we won't discover better approaches, but we try to make sure that the lessons we might learn from those attempts can be shared among all of us so that we all get better.

Do we use systematic mechanisms of learning?

We try to introduce mechanisms of learning into our organization that compel it to improve.

Do we have a bias towards action?

We learn from playing the game. Activity and feedback from it is the best tutor available.

Do we have a bias towards the new?

Whatever we do will evolve. So we have a bias towards the new, we're curious and we take appropriate risks. We're willing to experiment to learn.

Do we listen to our ecosystem?

The ecosystems that we create are powerful sensors for future change. But ecosystems need management, they need tending as a gardener tends a garden - sometimes we'll allow them to grow wild, sometimes we'll harvest, and sometimes we'll help direct or constrain them. These are particular skills that we can develop but the most important skill is that we listen to them.

Leading

Leadership is essential to a strong organization, and these behaviours help us think about that.

We try to make decisions quickly, measure the outcome and respond, and we know that strategy will change and develop over time. We want to get things right, but we know if a better way of doing something comes along then we need to be humble and adopt it.

Do we try to pick a direction of travel, and then deal with the problems as they come along, or do we change direction at the first sign of a challenge?

Do we move fast?

An imperfect plan executed today is better than a perfect plan executed tomorrow.

Do we recognise that strategy is iterative?

Instead of long-winded plans, we will have a direction towards a position and adapt as needed. We will "cross the river by feeling the stones". Do we pick a direction and stick to it, while adapting to challenges along the way? Once we've set a direction we commit to it.

There will often be hurdles and obstacles but we don't just simply abandon a direction because a single step is challenging. We try to find paths around the obstacles. When we're building systems and a common component isn't quite as expected then that is a potential opportunity.

Do we take ownership?

We take responsibility for our environment, our actions within it and how we play the game. We could let someone else decide for us, but that way we don't learn and we still can lose.

Do we try to inspire others?

Whilst the actions we take, the way that we organize and the focus on detail requires us to think small when it comes to inspiring others and providing direction & moral imperative then we think big.

Do we embrace uncertainty?

There will be uncertainty, emerging patterns and surprises along the way. We embrace this and don't fall for the temptation that we can plan the future. What matters is not the plan but the preparation and our ability to adapt.

Are we humble?

We listen to others, act selflessly, have fortitude and humility. We inspire others by who you are and what you do. We don't believe our own hype or pretend we are infallible.

Do we try to exploit the landscape we find ourselves in?

We use the landscape to your advantage. We look for and exploit powerful force multipliers to make the right moves, at the right times. Do we recognise that there is no core? Everything is transient, whatever we think is core to what we are doing now, won't be at some point in the future. The only things that are truly static are dead.

Structure

In the final section, we want to think about how we organize things. We need to recognize that small teams that are empowered to make decisions about how they will reach achievable goals are a better way of organizing ourselves, but that the people who work in those teams need to be right for the nature of the task.

We want to make sure that we strive for excellence, and that we don't accept second-best. We need to build into our organization the idea that things will change over time, and that we will need to change to meet new challenges as they emerge.

Do we think in terms of small teams?

When we're exploring the uncharted space a team of 3-5 is appropriate. When building a product then 10-12 seems more apt. When providing an industrialized commodity then a larger team can be argued for. We try to make our teams the right size for the task at hand.

Do we distribute power and decision making?

We try to put power in the hands of those who are closest to the decisions that need to be made.

Do we think aptitude and attitude?

Each team may contain discrete skills or aptitudes. But each aptitude has an attitude; the culture, methods and techniques for agile development of an entirely novel act are not the same as those for building a highly industrialized component. When we determine the composition of the team, we consider not only the aptitude but the attitude. The combination helps us be more effective.

Do we provide purpose, seek to attain mastery, and allow for autonomy?

Each team is autonomous within the confines of what it is supposed to do. Each team, therefore, owns what it does. Each team knows how they fit into the whole and can develop mastery in both aptitude and attitude.

Do we seek the best?

We try to find and grow the best people with the best aptitude and attitude for their roles. We invest in keeping them. We don't force them into becoming something they're not.

Do we recognize that there is no single culture?

We understand that an organization that plans for longevity needs to cope with not only the discovery of new things but also the use of things that have become industrialized while transitioning other things between these two extremes. We will, therefore, need to allow for different approaches at different times. We won't insist upon round pegs or square holes; we won't grind people down into one way of looking at the world.

Do we design for constant evolution?

Whilst a team might become a semi-permanent structure, the work it undertakes will evolve. It is, therefore, a duty to ensure that work evolves through the organization and that the makeup of teams changes over time.