Pay Attention to Structure

One of the easiest ways to tell whether somebody is an inexperienced organisational leader is to listen to how they talk about structure and process.

Structure slows us down. Process gets in the way.

On the surface, these ideas might sound bold and progressive. In reality, they are often an admission that leader doesn’t know how to shape an effective organisation. Structure and process are inevitable - they can be intentionally designed to amplify outcomes, or they can be ignored and delay or defeat outcomes.

The moment you have more than a handful of people working together, structure exists whether you acknowledge it or not. Information flows in particular ways, and decisions are made by particular people. Certain systems depend on other systems. Ownership forms around some areas and remains fuzzy around others.

The key differentiator is whether that structure emerged intentionally or accidentally.

Software engineers understand this instinctively. Every sufficiently complex software system has structure. Every architecture has boundaries, interfaces, ownership and constraints. When a system becomes painful to work with, we don’t declare architecture itself to be the problem - we look at the architecture and ask why it is producing the outcomes we’re observing. And then we fix it.

Organisations are complex systems, just the same. If you want an effective organisational structure then give it to a software architect - not an MBA.

Many leaders spend years fighting the consequences of structure while refusing to engage with the structure itself. They treat it as a bureaucratic problem rather than a design opportunity. They see it as administrative background rather than the primary tool available to them to deliver outcomes.

And then they wonder why their org isn’t delivering results.

Conway’s Law Is Unavoidable

For those not familiar with Conway’s Law, it effectively states that systems designed by organisations tend to mirror the design of the organisation. This is an inevitability, due to the fact design is a highly collaborative exercise which is communication heavy - the people who are talking determine the parts of the design that are talking.

Much like cognitive biases, some people tend to think if you know about them you’re somehow immune from them - but that’s not how they work. They are somewhat inevitable consequences of how brains function. And Conway’s Law is a somewhat inevitable consequence of how human collaboration functions.

Conway’s Law is the instruction: if your organisation will inevitably be reflected in your product, then organisational design becomes product design.

You are going to ship your org chart whether you like it or not. So design the org, and thereby design your product.

If you want a product that feels fragmented: organise around internal operational concerns, like code reviews, product surfaces, or politics.

If you want a coherent customer experience: organise around your customer’s experience.

The relationship is one-to-one. Your product eventually becomes a reflection of the conversations your organisation has to have in order to build it.

The Call Centre Problem

Commonly, organisations are structured around internal operational concerns. We work inside the organisational machine all day, and so our most natural idea is to make it as efficient as possible.

This produces what I think of as “the call centre problem”.

You contact a company with what seems like a straightforward issue. The first person tells you that isn’t their department, so you get transferred elsewhere. The next person asks you to explain everything again because they have no context. They transfer you to a third team. Eventually somebody helps you, but by that point you’ve spent forty minutes on hold navigating the company’s internal structure.

As a customer, it’s an awful experience. Every step in the user’s journey feels like it belongs to a different team because, in reality, it does. You, the paying customer, are suffering the complexity of solving whatever problem the organisation is supposed to be solving for you, instead of the organisation feeling it.

It’s the same mistake I’ve described before when designing software - we optimise around making our own jobs easier, and the customer ends up eating the complexity we’re supposed to manage for them.

Products Are The Wrong Structure

Many companies organise themselves around their products or their business capabilities, then they wonder why the customer experience feels fragmented; why they’ve “shipped their org chart”.

The customer doesn’t care about platform ownership. The customer doesn’t care about your departmental boundaries. The customer doesn’t care which executive owns which budget.

Customers experience your products through outcomes.

They arrive with a goal - a job to be done - and they expect the experience to feel coherent from beginning to end.

Organising around specific products, capabilities or surfaces designs around the company’s view of the world rather than their customers’.

At the highest levels, organisations should be structured around customers and customer journeys. The teams underneath should own the products or capabilities that support those journeys. Underneath those sit the shared platforms, tooling, operations and infrastructure that service the rest of the org above who deliver those products and capabilities.

In other words, the organisation’s structure and incentives should mirror how customers experience the product - not how the company experiences itself. This is how you preserve customer obsession at scale.

When that alignment exists, teams naturally build horizontally across customer journeys. When it doesn’t, they build vertically inside organisational silos. This is when you find experiences like four or five unprompted upsell dialogs in a single user flow - all coming from different teams who don’t even know the other exists.

Structure Is A Skill

Part of the reason leaders resist structure is that many of the skills that make somebody effective at a small scale become less effective as scale increases. They are using old skills that served them well, and ignoring the new skills they need to succeed at the new level.

A leader running a team of ten can get remarkably far through force of personality - they know everyone. They can communicate directly, they can align people through conversation, they can personally resolve disagreements and coordinate work.

As the organisation grows, those techniques stop scaling: the leader can no longer talk to everybody, dependencies multiply, communication paths explode, priorities diverge, incentives become misaligned, and so on.

At that point, structure becomes the mechanism through which leaders direct organisational outcomes. Many leaders experience the discomfort of this transition and conclude that structure is slowing them down, when what’s actually happening is that they’ve reached the limits of leadership that can be achieved through personal influence alone.

The next level requires systems thinking. The solution to poor structure is not no structure, it’s better structure.

Structure Is Leverage

There are many levers leaders can pull to influence outcomes, but structure is one I see consistently ignored and underappreciated - even at the team level.

Structure determines who talks to whom. Structure decides what gets done, for who, and in what order. Structure decides the design, and design decides the customer experience.

The most dangerous organisational mistake often isn’t creating the wrong structure - it’s convincing yourself that structure itself is the problem. Once you’ve done that, you’ve thrown away the most powerful tool you had available to you to achieve the outcomes you wanted.

Whether you design the org intentionally or not, Conway’s Law remains indifferent - like it or not, you’ll still ship your org chart.

The only question is whether you continually refine that org chart with your customer in mind, or whether you leave it to chance and politics.