Key points
- Choose the structure by deciding what the organisation must be best at, then group work around that priority and accept the trade-offs.
- Every structure is a compromise, so the real design work is in the linking mechanisms that cover what the chosen structure neglects.
- Matrix structures fail when decision rights are left vague, not because two reporting lines are inherently unworkable.
- Redrawing the org chart without changing roles, decision rights, processes and metrics usually produces the same organisation with new boxes.
Most restructures I have seen start with the chart. Someone senior sketches boxes on a whiteboard, the boxes get names, and the names get people. Six months later, the same problems are back, because the question that should have come first was never asked: what does this organisation need to be exceptionally good at, and what are we prepared to be merely adequate at in return?
This article walks through the main structural options (functional, divisional, matrix, team-based, network and flatter models), what each one is good and bad at, and a decision table you can use with your executive team. It is written for organisations in the GCC, where rapid growth, government transformation agendas and family group complexity make structural choices more consequential than usual.
Structure is a choice about trade-offs
Every structure groups some work together and separates other work. Whatever you group together becomes easy to coordinate. Whatever you separate becomes harder. That is the whole game.
Group by function, and you get deep expertise and efficient shared resources, but customers and products fall between departments. Group by market or product, and you get focus and speed on those markets, but you duplicate specialists and lose consistency. No structure removes this tension. It only decides which side of it you are standing on.
This is why I push executive teams to name their primary design criterion before looking at any option. Is it cost efficiency, customer responsiveness, speed of innovation, regulatory control, or growth in new markets? You can rank several, but one has to win. If everything is a priority, the structure will reflect whoever argued loudest in the workshop.
Every structure is a compromise, so the real design work is in covering what your chosen structure neglects.
The main options and what they are good at
Functional
Work is grouped by expertise: finance, operations, HR, sales, technology. This is the default for most organisations under a few hundred people and for many government entities.
It works well when the organisation has one main product or service, when efficiency and technical depth matter most, and when the environment is relatively stable. It struggles when you serve different markets that need different approaches, because every cross-functional decision escalates to the top. In a fast-growing GCC company, the CEO often becomes the only integration point, and the executive committee turns into a queue.
Divisional
Work is grouped by product, geography or customer segment, with each division holding most of the functions it needs. Family groups with distinct businesses (say, retail, real estate and hospitality) often land here naturally.
The strength is accountability: each division head owns a result. The costs are duplication, inconsistent practices, and divisions that compete with each other for group resources. The usual fix is to keep a small set of shared services and group-level policies at the centre, but the boundary between "centre decides" and "division decides" must be explicit or it will be fought over every budget cycle.
Matrix
People report along two axes, typically function and product, or function and geography. Matrix structures get a bad reputation, and mostly deserve it when they are introduced as a compromise to avoid choosing.
A matrix is useful when you genuinely need both deep expertise and strong market or project focus, and neither can be subordinate. It works when decision rights are written down, when there is a regular forum where the two sides resolve conflicts, and when both managers are measured on outcomes that require each other. Without those, employees get two bosses and no answers.
Team-based and project-based
Work is organised around cross-functional teams that own a product, a customer journey or a project. Teams may be stable (a product team) or fluid (people assigned to projects and then reassigned).
This suits organisations where the work itself is project-shaped: consultancies, engineering and construction, digital product groups, and transformation offices inside larger entities. The risks are loss of professional depth, unclear career paths, and people belonging to everything and nothing. Most organisations that do this well keep a functional "home" for professional standards and development, and deploy people into teams for the work. In technology groups this is the familiar tension between organising around the codebase and organising around the product; most settle on a hybrid.
Network
The organisation keeps a core of strategic capabilities and relies on partners, outsourcers and joint ventures for the rest. Many GCC entities already run partly this way, with significant work delivered through contractors and service providers.
The design question here is less about boxes and more about the capability to manage partners: contract management, performance oversight, and knowing which capabilities are too strategic to outsource.
Flatter and self-managing models
Flattening means removing layers and widening spans of control. Self-management goes further, distributing authority to teams through explicit rules on how decisions are made. Both are sometimes presented as the answer to bureaucracy.
Flattening can speed decisions, but only if the decisions actually move down with the layers removed. If you delete a layer and keep the approval matrix unchanged, you have simply given the remaining managers more people to ignore. Full self-management requires unusual maturity, strong information transparency and a willingness to rewrite HR policies, and I would treat it as a targeted experiment in a willing unit rather than an enterprise design.
A decision table for your executive team
Use this table in a working session. For each row, agree which statement is most true for your organisation today and for the next three to five years.
| If your situation is mostly this... | Lean towards | Watch out for |
|---|---|---|
| One core service, stable demand, efficiency and control matter most | Functional | Slow cross-functional decisions, CEO as sole integrator |
| Several distinct businesses or markets with different strategies | Divisional | Duplication, inconsistent policies, turf wars over the centre |
| Need both deep expertise and strong market or product focus, neither can be secondary | Matrix | Vague decision rights, conflicting objectives, slow escalation |
| Work arrives as projects or products with clear outcomes | Team-based or project-based | Weak professional depth, unclear careers, overloaded specialists |
| Much of the delivery can be done by partners | Network | Weak partner management, outsourcing strategic capability |
| Too many layers, slow approvals, capable people waiting for sign-off | Flatter structure with delegated authority | Removing layers without moving decisions, overloaded managers |
Two practical notes on using this. First, the answer can differ by level. A group can be divisional at the top, functional inside each division, and team-based inside the technology unit. Second, if two rows fit equally well, that is a signal you need strong linking mechanisms regardless of which way you go.
Linking mechanisms matter more than the chart
Once you choose how to group work, you have created seams. The quality of a design depends on how well those seams are stitched. Galbraith's Star Model is a useful reminder here: structure is only one of five design elements, alongside strategy, processes, rewards and people practices.
The linking mechanisms I see make the most difference:
- Decision rights. A simple matrix listing the 20 to 30 decisions that matter most (pricing, hiring above a certain grade, capital spend, policy exceptions) and who recommends, decides and must be consulted. RACI works if you keep it short.
- Governance forums. A small number of committees with clear mandates and membership, rather than a proliferation of meetings nobody can skip.
- Integrator roles. Account leads, programme directors or product owners whose job is to pull across the structure. They need real authority over priorities, even if they do not own the people.
- Shared metrics. Objectives that two units can only achieve together. If sales is measured on volume and operations on cost, the structure will not fix the argument between them.
- Planning cycles. Joint business and workforce planning so that units commit to each other's needs before the year starts, not during it.
If you want a deeper treatment of the principles behind these choices, I cover them in organisation design principles that hold up in practice.
Designing for the GCC context
A few features of the region shape structural choices in ways that generic guides miss.
Growth outpaces structure. Many GCC organisations have doubled or tripled in a few years. Structures designed for a founding team get stretched until they break, and then get patched with advisory roles and special units. It is worth designing one stage ahead: what will this structure look like at twice the headcount, and which roles will need to split?
Government mandates change. Government and semi-government entities frequently receive new mandates, merge or split. A structure with a stable functional core and a flexible programme layer absorbs this better than one where every new mandate becomes a new sector.
Family groups carry legacy. In family-owned groups, structure often reflects family roles and history as much as business logic. The practical move is usually to separate ownership governance (family council, board) from management structure, and to be clear which decisions sit where.
National workforce programmes. Emiratisation, Saudisation and similar programmes affect how you design roles and career paths. Structures with very flat hierarchies can leave few visible progression steps, which makes it harder to develop and retain national talent. Design grade structures and career paths alongside the chart, not after it.
Common mistakes to avoid
The same errors appear across sectors:
- Designing around individuals. Creating a role because a particular person needs a title produces structures that make sense only to those who were in the room.
- Too many layers for the size. A 600-person entity with eight layers from CEO to front line has a decision speed problem, whatever its chart looks like. Review spans and layers together.
- Copying a competitor or a famous company. Their structure reflects their strategy, history and talent. It rarely transfers.
- Treating the chart as the deliverable. The chart is a summary. The work is in role profiles, decision rights, processes, sizing and the transition plan.
- Announcing before sizing. Publishing a new structure before you know how many roles each unit needs, and at what grades, creates expectations you then have to walk back.
Where to start
- Agree your primary design criterion with the executive team in one sentence, and write down what you are willing to be less good at.
- Map the current structure honestly, including spans, layers, and where decisions actually get made rather than where the chart says they do.
- Use the decision table above to shortlist two options, and test each against five or six real scenarios, such as a new major client or a new government mandate.
- Design the linking mechanisms (decision rights, forums, integrator roles and shared metrics) before you finalise the chart.
- Size the units and plan the transition before any announcement.
At Humanyx, we help organisations make these structural choices and then design the roles, decision rights and workforce plans that make them work in practice.