Ardonio Ltd

Aug 01, 2020

The Onion model

I love a good model. Imperfect as they can be, they're invaluable in trying to organize the world and create clarity between detail and big picture. As a consultant it was only ever going to be a matter of time before I ended up creating my own model for the world around me: the world of (software) delivery organisations.

At heart my job is usually very simple to define: create a system in which the right work can be delivered in a controlled manner. Let's unpack that a little bit. It starts by knowing what "the right work" really is. Delivering the wrong thing isn't the goal here, or in fact anywhere I'd hope. So any system with that goal has to deal first with understanding the input and how to make sure that input fits those goals. The second part, "a controlled manner" doesn't mean a command-control "manage the detail" style. Instead I mean controlled in a more statistical interpretation, as in "within the bounds of acceptable variation". The last part to think about, and arguably the most important, is that any process or framework ultimately has a number of people to think about. While I do subscribe in part to the Ohno "it's the system, stupid" line of thinking, in the end the work still is done by people and so that's a dimension that has to be factored in. Each of those is worthy of a long discussion, but for now let me stick to introducing the Onion.

The Onion

The Onion Model

The Onion really is a meta-framework, if you will. It doesn't prescribe any particular actions in the way some proejct management methods would. Instead it takes a step back and tries to place the various methodologies and practices in context. In it's simplest form, the onion is a set of concentric layers from the inside out: delivery, quality, automation, framework, governance.


The heart of the onion is delivery. Going back to what I said earlier, designing systmes in which the right work can be delivered is essentially my job. So at core, teh capacity to put product or services in the hand of customers is what drives a business forward and generates revenue. It doesn't really matter if your product is a small toy, a complex supercar, some software or a product that is really a service like a lawyer or consultant. At the end of the day, value comes from delivering this product to people who have a use for it. That's as true on a macro level (i.e. company wide) as it is on a team or even individual level. The only difference really is the scope or type of customer, which could vary from team mates to internal teams to external customers.


I tend to look at quality through 2 questions: 1. Are you delivering the right thing? 2. Are you delivering the thing right? Or slightly more philosophical: is delivering the wrong thing right better than delivering the right thing wrong? The first perspective is all about understanding demand and requirements, the second is inspecting the processes. Not looking at both these perspectives is a classic pitfall when organisations "go Agile". They'll put all their focus on the second perspective, trying to do a better version of Scrum/KanBan/SAFe but end up simply building the wrong thing better.


In a perfect world where you are delivering, both the right thing and the right way, the focus shifts to repeatability. I would also expand that definition to "repeatable without extra variability". In other words, consistency is also important. That's where automation comes in.

I'm going to take a pretty broad definition here of automation as any rules based system that gets consistently executed. In it's purest form that is probably code, but it could equally be a set of rules for people to follow and help them make decisions. If you take that in terms of dollar value of time spent by a person it's not easy to understand that situations that require judgement and creative solutions are worth more than repeating a set of steps over and over. And if anything, the latter is more prone to human error. So with that in mind, gear your automation towards maximum leverage while allowing enough variability in the creative/hard/unclear sitautions. 100% automation isn't a goal, it's about freeing up people to engage with the hard problems rather than the mundane.


This layer and the governance layer around it are less about directly affecting the product but focus more on the processes, both creations and management thereof. In my experience people discuss this layer a lot, but often don't bother reflecting on how this affects the other 3 layers inside it. We're doing Scrum has become short hand for a few ceremonies with sprints and daily standups. Similarly KanBan seems to have been reduced to swimlanes and no sprints.

Consider this though: which company has ever won because they had the best prince2, scrum, kanban, SAFe, ... implementation? I'd argue those that won consistently delivered value to their customers, and their internal process was likely some amalgamation of things that worked for them.


In many ways this layer deals with the most important decision of all: the decision of how you make decisions. Governance isn't about picking a particular framework, let alone directly impacting quality levels in the delivery. The core problem of governance is around defining focus, boundaries, tolerances, and even strategy. It sets the broad guiedes for what is valued, what the organisational design should optimize for and the top level execution of how that will be achieved.


As you move through the layers 2 dimensions change. The first is very obvious: you are moving away from directly impacting the core. The second is the time it takes to get feedback on a change. Changing a line of code has immediate result, tweaking the parameters of how you make decisions will take quite a while before the effects are seen throughout the organisation.

This is at heart the difficulty with moving from individual contributor roles into leadership, and either of those trying to overreach too far is likely to have negative effects. In fact individual contributors typically look from the inside out, whereas senior managers tend to look from the outside layers inwards. As a result they might optimize for different things and at times even seem at odds. This model however has helped me for well over a decade in staying grounded, and help teams focus on the place where they can add most value for the entire organisation.