Structures Explained

Idea one

Why the functional structure exists

A structure is the basic way an organization groups work, expertise, authority, and people. It answers who works together, who reports to whom, where specialist knowledge sits, and which leader coordinates a given area. The most common answer is functional — people grouped by the kind of work they do. Finance with Finance, Sales with Sales, Operations with Operations.

The strengths are real. Specialists work alongside people who understand their language, standards, tools and problems. A functional structure allows people to become better at a particular discipline, and that matters because organizations need expertise. Northstar would not want credit-hold decisions made only by people whose main experience is restoring equipment, or field engineers setting their own safety rules. Specialization improves quality when the work requires knowledge that cannot be acquired casually.

It improves efficiency too. Rather than every regional team employing its own finance expert, systems specialist and recruiter, expertise is gathered into functions that serve the whole. And it makes standards stronger: a functional leader can establish a common method, train people in it, monitor whether it is followed, and improve it over time.

That is especially valuable where a poor decision affects more than one team. Finance can see total exposure to a customer in a way a service manager cannot. Technology can see whether a local request would create a security weakness. Procurement can see several teams buying the same parts separately at different prices. A functional view can connect decisions that appear unrelated to the people closest to each individual event.

For these reasons, functional structures are not a sign of bureaucracy or lack of imagination. They are a sensible response to growing complexity.

The difficulty is on the other side of the wall. Customers do not experience the organization in functions. A customer whose equipment has failed does not experience a Finance issue, an Operations issue, a warehouse issue and a Sales issue. They experience one company that either restores the equipment or does not.

Idea two

A silo is not a department

Every organization needs departments. A silo appears when a department becomes so focused on its own goals, measures, language, and authority that it loses sight of the wider outcome. People may cooperate politely. They may attend the same meetings. They may genuinely want to help one another. But work still stops at the boundary because nobody feels responsible for carrying it across.

At Northstar, Finance has a legitimate responsibility to control debt. Operations has a legitimate responsibility to restore equipment safely. Sales has a legitimate responsibility to protect revenue. The warehouse has a legitimate responsibility to release stock only with the necessary approvals. The problem arises when each team does its own part correctly while the overall customer outcome fails.

From inside a silo, delay looks reasonable. "We cannot release goods without approval." "We are waiting for Finance." "The engineer is ready, but we do not have the part." "We have raised the customer's concern." All these statements may be true. None answers the more important question: who is responsible for making the whole situation move?

Functional structures struggle with that question because they are designed around expertise, not around the end-to-end journey of work. Without a way to coordinate across boundaries, people fall back on the language of handover — "it has gone to Finance," "Technology has the ticket," "the warehouse is waiting." Handover language can be useful because it identifies the next step. It becomes dangerous when it is used to signal the end of one person's responsibility rather than the continuation of the work.

And here is the part that is hardest to catch. The silo does not always announce itself through conflict. Often it appears through absence.

In the portal case, no one is asking how many customers are affected. No one is counting the manual work created for Support. No one is deciding what customers should be told while the defect remains unresolved. No one has connected the portal problem to customer retention risk or operational cost. The work has not disappeared. It has simply been split into pieces small enough for each function to treat as someone else's concern.

Idea three

Measures are not neutral

Functional leaders can reinforce the pattern without meaning to, through the measures they use. If Finance is measured only on debt reduction, urgent releases appear as avoidable control failures. If Operations is measured only on response time, service managers push for exceptions without weighing the financial risk. If Sales is measured only on revenue, account executives make promises the operational teams cannot fulfil. If Technology is measured only on delivery against a planned roadmap, unplanned customer pain struggles to gain priority.

Measures are not neutral. They tell people what success looks like. When each function is rewarded for optimising its own part, the organization should not be surprised when the whole system becomes difficult to manage.

The answer is not to remove functional expertise or demand that everyone care equally about everything — that creates a different kind of confusion. Finance should continue to care deeply about financial control. Technology should continue to protect system integrity. The answer is to add shared outcomes where the work crosses functions.

Northstar can keep separate measures for debt, response, retention, portal reliability and stock accuracy, and also examine the combined outcome: how quickly critical equipment is restored, how often an urgent repair is delayed by an internal decision, how much manual work the defect creates, and whether customer problems are resolved rather than merely transferred.

Shared outcomes force useful conversations. If an urgent repair is delayed, the question is not whether Finance followed the policy or Operations raised the request correctly. It is whether Northstar had a workable way to make a proportionate decision under pressure.

Connections can take many forms — decision routes, regular forums, shared measures, named owners for customer journeys, service agreements between functions, clear escalation paths. What matters is that the connection is real. A monthly meeting does not solve a silo if nobody can make a decision there. A shared dashboard does not solve a silo if each function reads only its own numbers. A senior leader does not solve a silo merely by telling people to collaborate.

Idea four

Divisions, and matrices

As an organization grows, the question changes. It is no longer only "which function does this work belong to?" It becomes "which part of the business is responsible for this customer, market, product, or geography as a whole?" That is the logic behind a divisional structure — people grouped around an area of business rather than only around a discipline.

A divisional model can solve the ownership problem directly. The divisional leader can see that an unresolved invoice dispute, a parts shortage, and a delayed repair are not separate internal matters. Together, they threaten a valuable customer relationship.

But it creates a problem when each division begins to behave as though it is a separate business. One promises service levels needing scarce engineers already committed elsewhere. Another creates a local process conflicting with Finance policy. A third demands Technology changes useful for its customers and expensive or disruptive for everyone else. A division can create focus but duplicate effort.

A matrix tries to hold both. It lets an operations specialist work closely with industrial customers while remaining part of central Operations; it gives a finance business partner commercial understanding and a connection to credit-control standards. It can bring customer evidence, product priorities, technical constraints and commercial consequences into one conversation.

But somebody must still decide. If the meeting merely allows each leader to repeat their own priority, the matrix has added complexity without creating coordination, and the people doing the work remain uncertain what to do next.

For a matrix to work, decision rights must be unusually clear. Who sets professional standards, who sets daily priorities, who evaluates performance, who approves resources, and who resolves conflict when functional and divisional needs collide. These answers cannot be left to personality or seniority. If the most forceful leader always wins, the matrix is not a structure. It is a contest. And it needs shared measures too — reward the division only for revenue and speed, Operations only for efficiency, Technology only for planned delivery, and the matrix will produce predictable conflict. It can create a problem if the person at the intersection receives two instructions and no way to decide between them.

Idea five

The structure is always a trade

Organizations talk about structure as though it is a permanent answer. A functional model is introduced to create expertise. A divisional model to bring the organization closer to customers. A matrix to connect specialist knowledge with commercial priorities. Each change is presented as a solution, and for a time it may be.

But no structure removes the need for judgement, coordination, and clear authority. It changes where those difficulties appear.

Functional solves scattered expertise — and creates a problem when customer outcomes must travel across disciplines and no one owns the journey. Divisional solves that — and creates a problem when divisions behave as separate businesses. Matrix solves the tension between local focus and functional expertise — and creates a problem when the person at the intersection receives two instructions and no way to choose.

Neither model is automatically better than a functional structure. A division can create focus but duplicate effort. A matrix can connect expertise to the work but confuse authority. A function can build depth and consistency but become distant from the customer journey. The structure is always a trade.

So the test is not whether each department has clear responsibilities. It is whether a problem can travel between them without losing its owner, its urgency, or its meaning. When the answer is yes, specialization strengthens the organization. When the answer is no, the published org chart may show capable functions. The real org chart will show the gaps between them.

The real question is whether people can tell, in the moment when a problem appears, whose decision is needed, what each function or division must contribute, and who has the authority to resolve the conflict when more than one good priority is competing for the same work. That is the point at which structure either helps or harms.

Which leaves the sentence to carry out of this chapter. Structure does not solve problems merely by moving names into different boxes. It solves problems only when it changes the path of work for the better.