Organisational structure dictates the design of a service
‘There are many designs, most of which you haven’t thought of. And as soon as you organise to build a particular design, you have ruled out a lot of the other designs that you haven’t thought of. And that has major implications for getting the job done because usually the first design is wrong and that means your organisation is wrong.’”
Melvin Conway, creator of ‘Conways law’There has never been a truer word said about the difficult double-bind we get ourselves into when we design our organisations around a service that isn't right.
When Mel conway came up with Conways law, it was after years of working on technology projects that were evolving faster than the organisational structure around them.
The buildings, funding, reporting lines and other things that make up what we call ‘organisational structure’ are often defined in isolation from our service, defined too soon or simply don’t change at all in response to changes to our service.
This is a problem because as Mel Conway went on to describe Conways law; "Organizations, who design systems, are constrained to produce designs which are copies of the communication structures of these organizations." - Our structure defines the shape of the services we provide.
Our issue then becomes the fact that we have designed our organisations around a solution to a problem without validating whether this is the right solution or even the right problem (as we saw in chapter 1: Purpose and chapter 2: Users of Bad Services). This leaves us in a situation that is very hard to get out of, because the structure feels difficult to change.
This is why service design is hard, because it demands the organisation to change itself in order to deliver often what is needed.
When Conway’s law was devised, he was sitting in a physical space, seperated from other teams in the office. Technically we don't need to be in the same building as each other anymore to communicate, so why does Conway's law still have such an impact on us today?
Because we replaced physical walls with behavioral ones.
What was once a cubicle wall, or another building keeping us apart is now a separate budget, reporting line, policy area or discipline. The walls between us aren’t physical anymore, but the problems they create are no less real.
So how do we overcome this, when Conways law feels both inevitable and unchangable? Like all of the other issues we face with bad services, the first step is to know why we’re in this situation in the first place.
In part, the problem we have with negotiating structural issues in service design is that we just don't notice where silos are showing up and impacting our work. That’s why I split Chapter 5 on structure into two parts, defined by two really distinct types of silo:
Horizontal silos
The siloes people experience moving through your service
These are often experiences of disconnection in the user journey where the user has to work hard to make the service help them achieve their goal, or the service is very different at different parts, this can look like;
Disconnected data (One part of a service giving your name/age but the service is asking you to repeat information again)
Language or information (Different names for things that are the same thing, like using customer record and customer I.D interchangeably)
Visual inconsistency (Colours, font, happens a lot when different people own different parts of the service like outsourcing)
Misaligned processes (Different criterias for using the service or timelines like being asked to do one step after another but not possible to do in that order)
Vertical silos
Parts of our service design and delivery process are not delivered in unison by an organisation creating problems with our services.
This often happens when ideas come from the top of an organisation and are ‘chucked over the fence’ on their way down towards delivery mechanisms.
Not all horizontal siloes are created by vertical siloes - they can be caused by other issues but they are often caused by vertical siloes.
The fact that we don't see silos in both of these directions is part of the problem. The other issue is that we just take this for granted that it has to be this way.
Conway's law is like a law of physics but - like everything in this book, our route to solving it is understand why it happens
When one structure isn’t working it is tempting to design another one, but we rarely ever focus our effort on the communication challenge that sits at the root of Conways law. We can spend years and millions moving this round through restructures without addressing this issue by setting up new governance or improved formats that focus on what’s being designed like show and tells.
I won’t try to summarise all they potential solutions here, after all, two chapters in a book barely scratches the surface of this issue but one solution may lie in developing a better practice around connecting the disparate parts of our organisation or service that don’t work together. To do that we would do well to look at other design disciplines that see this ‘connecting’ role as intrinsic to their trade.
In older design professions the importance of designing beautiful (or at the very least considered) joints between materials is far from a new or radical idea. Think of crafts and trades that bring disparate materials together in fabric, wood or metal. The process of creating seams is so central to the role of these professions that those jobs are themselves named after the process of joining seams. Joiners, seamstresses and welders all bring together different materials to create a whole piece.
Without the 16th-century invention of strong, decorative French seams (where the seam is sewn in on itself to encase the raw edge of the fabric), we would not have the modern suit. Without the medieval popularity of mortise and tenon joints in construction, we wouldn’t have A-frame roofs. And it’s almost impossible to list the things we wouldn’t be able to do without the ability to weld metals together.
Joining materials is fundamental to any design discipline. So too with service design.
Most of service design is about silos, most of the time. To fix services, you need to both acknowledge this, and develop a toolset to deal with it.
We talked about this and more in episode 12 of the Bad Services Podcast on structure. Listen in here, or buy the book to delve deeper.

