Organising Around the Customer
Why the unit you group people by decides how fast you can adapt
An article in the series “The Dimensions of Adaptivity”
Solution orientation, as this article uses the term, is the dimension behind the Product Orientation pillar of the Society’s reference model on the home page: the commitment to organise around the outcome delivered to the customer rather than around internal functions.
Two kitchens, one way to cook
Think of a catering kitchen and a food factory. A factory is organised by ingredient and by skill. The vegetables are washed in one room, the sauces made in another, the ovens run by specialists in a third. Each station is efficient at its own task. Now follow one finished dish. It crosses every station in turn, waits between each one, and no single person can tell you whether the whole plate arrived hot, balanced and on time.
A good catering kitchen is organised the other way round. A single chef owns each table’s meal from the first chop to the final plate. They see the guest, they taste the result, and when something goes wrong they fix it on the spot because they have both the judgement and the authority. The catering kitchen has no organisation chart that can be drawn in a slide. It has outcomes that someone owns.
Most organisations are built like the factory. They are structured around functions, components and disciplines, and the customer’s result has to be stitched together across the boundaries between them. The alternative, organising around the outcome delivered to the customer, is what this article calls solution orientation. It is one of the dimensions of an adaptive organisation, and it is the one that dictates the shape of everything else.
The value lies in what changes for the customer
Begin with a plain claim. A hospital delivers health. A bank delivers the ability to manage risk. A software company delivers the capability to do work differently. In each case the value is not in the internal activity, the consultation, the ledger or the code. It is in what changes for the person who uses it. This sounds obvious and is, in practice, almost never how an organisation is arranged.
The structural commitment of solution orientation is to define the unit of organisation around that change rather than around internal activity. A solution is the complete outcome delivered to the people an organisation serves: not a feature, not a component, not an internal deliverable, but the thing that changes a customer’s situation. For a car manufacturer the solution is reliable personal mobility, not an engine or a chassis. For an e-commerce company it is the seamless experience of finding, buying and receiving a product. Defining the solution is the first structural decision an adaptive organisation makes, because every later decision about teams, accountability and value streams rests on it.
Draw the boundary too narrowly, around a single component or a single step in the value stream, and the teams inside it optimise for their part without seeing the whole. Draw it too broadly, wider than any person or team can oversee, and accountability dissolves. Either error is structural: it determines how teams form, where accountability sits, how priorities are set and how value is measured.
The component team sees no customer
A team organised around a component rarely sees the person it exists to serve. The team that owns the payment module in an online shop does not meet the shopper. The team that builds a braking system does not meet the driver. Two consequences follow, and both damage adaptivity.
First, priorities become disconnected from value. The component team cannot judge whether its work is the most valuable thing the organisation could be doing, because it has no view of the customer’s situation. Priority is settled elsewhere, in a management layer that arbitrates between competing internal demands. Decisions about what matters are made furthest from the evidence of what customers actually need.
Second, and just as corrosive, the team’s contribution becomes invisible to itself. Performance is measured by output, by features delivered and components shipped, rather than by outcome, by what changed for the customer. The team becomes a cost centre justified by efficiency rather than a value creator measured by impact. And because each team is accountable only for its own component, the question that matters most, did we solve the customer’s problem, has no owner at all. It falls into the gaps between teams, owned partly by everyone and fully by no one.
The structural alternative is the solution team: a team organised around a slice of the solution visible to the customer, with the competence to deliver that slice end to end. It sees the customer. It understands the problem it solves. It sets priorities from customer impact rather than internal arbitration. It owns the outcome, not just the output.
What the shift actually costs
None of this is achieved by declaration, and the honest article says so plainly. Reorganising around solutions challenges the reason most organisations were arranged in the first place. Departments carry reporting lines, budgets, career paths and identity, and moving to a solution structure disturbs all of them.
The obstacles are structural rather than technical. When a value stream is fragmented across departments, internal politics fill the gaps: decisions about priority become negotiations between internal stakeholders rather than assessments of customer value. Distributed teams face slower, thinner communication than co-located ones. Large organisations carry technologies that mirror their departmental boundaries, and the more technologies a team must span to deliver a solution, the harder broad competence becomes. And knowledge often pools in functional groups, so no team can own a whole solution without depending on people outside it.
The sharpest lens for this is the distinction between two kinds of complexity, first drawn by Brooks (1986) for software systems and applied here to organisations. Essential complexity is the genuine difficulty of the problem being solved; it cannot be reduced without changing the problem. Accidental complexity is the difficulty the organisation adds through its choices of structure, technology and process. Fragmentation that forces five teams to coordinate when one broad team could deliver is accidental. Advisory or compliance layers added because boundaries exist are accidental. And accidental complexity is the enemy of adaptivity, because every piece of it is a handoff, a wait and a decision that cannot be made locally. Cutting it is not housekeeping. It is a direct lever on speed.
Thinking about your own organisation
Now map this onto the place you work. Consider the last genuinely important delivery of your organisation. Could one person name who owns its end-to-end outcome, or was responsibility spread across a chain of internal handoffs? Set aside what the titles say and ask what rewards: when a bonus is on the table, is it paid for features delivered or for problems solved?
Then ask where decisions about customer priorities are actually made. The test of solution orientation is whether the people closest to the work, and closest to the customer, hold the authority to act on what they see, or whether that authority sits in an arbitration layer that filters and delays. A reorganisation that moves boxes around an org chart can fail to be a reorganisation at all if it leaves the decision structure untouched.
The good news is that the direction is measurable. The question is always how many internal boundaries a customer’s need must cross before it becomes a delivered outcome, and how much of the coordination that crossing requires is accidental. Every reduction in that count widens the scope a single team can own, shortens the feedback loop and returns a decision to the person who has the knowledge. That is solution orientation working, and it is available wherever the ambition to cut accidental complexity happens to sit.
Question worth asking
So come back to the kitchen. Nobody walks into a good restaurant and asks which station cooked their meal, because the answer would be meaningless. The only meaningful account of the meal is the one that follows a single owner end to end. Ask the same of your organisation the next time you are asked to draw it. If you drew it around departments, around technologies or around the components that happen to exist, you have drawn a factory. If you drew it around the outcomes people actually receive, you have drawn a kitchen, and you have drawn the shape of something that can adapt.
The chapter this article draws on, Chapter 5 of the book, develops the seven constraint dimensions that limit how broadly any organisation can define its solutions, and the practical work of reducing accidental complexity within them. If the gap between your ambition and your structure is wider than you would like, that is where the sustained, empirical work of solution orientation begins. Start there.
Sources
- Brooks, F. P. (1986). No silver bullet: Essence and accidents of software engineering. In H.-J. Kugler (Ed.), Information Processing 86. Elsevier.
- Society for Adaptive Organisations (2026). Adaptive Organisations: Thriving in Complexity.
- Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard Business Review, 64(1), 137 to 146.
About this article. This article is a short, adapted summary of one of the core topics of the book Adaptive Organisations: Thriving in Complexity, written and published by the Society for Adaptive Organisations (2026). The full treatment of the subject, together with the supporting argument and reference materials, is developed in the book. Further resources and the book itself are available at adaptive-organisations.org.