Organisational Structures

Every structure on one screen

Here is the whole comparison first. Each row is one structure: how it groups people, how many bosses one person has, who owns the people and the budget, and how much authority a project manager has inside it. The names differ between the management textbooks used across Eastern Europe and the Western project-management literature, and the difference trips people up, so both are given.

Line, hierarchical, matrix — which are real types

Many people arrive at this topic with three words — line (often translated as linear), hierarchical, matrix — and two of them are types while the third is not. Line is a real structure: every person has exactly one boss, and orders travel down one chain. Matrix is a real structure: a person deliberately has two bosses, one for their speciality and one for their project. Hierarchical is not a third type beside them. It is a property — the existence of levels, each reporting to the one above — and almost every structure in the table has it. A line organisation is the purest hierarchy; a matrix is two hierarchies laid across each other. The real opposite of hierarchical is flat or self-managing, where authority is written into roles rather than into levels.

Textbooks sometimes use “hierarchical” as a family name instead, in the tradition of Tom Burns and G. M. Stalker, who in 1961 contrasted mechanistic organisations with organic ones. In that reading line, functional, line-and-staff and divisional structures are hierarchical, or bureaucratic, while matrix, project and team-based ones are adaptive. That is the more useful reading. But the three-word list still leaves out what matters most in practice: line-and-staff, divisional, project and product teams — which is where most IT companies actually live.

Two vocabularies for the same shapes

Five questions that tell you which one you are in

The org chart on the wiki is not evidence. These five questions are, and a new project manager should have the answers in the first week.

1. 1.Who actually decides

   1. 1.1Who approves your team members’ holidays?
   2. 1.2Who sets their pay and writes their performance review?
   3. 1.3When two projects want the same engineer next week, who decides?
   4. 1.4Who can move money inside the project budget without asking anyone?
   5. 1.5When the project ends, where do the people go?

If the answer to 1.1 and 1.2 is a department head and the answer to 1.3 is “we negotiate”, you are in a weak or balanced matrix, whatever the chart says. If you answer 1.3 and 1.4 yourself, it is a strong matrix or a project structure. If the answer to 1.5 is “back to the bench”, the company is a matrix with the people owned by competence centres. And if nobody can answer 1.3 at all, you have found the largest risk on your project.

Two questions behind every structure

Every structure is an answer to two questions. The first is how the work is grouped: by speciality, so all the testers sit together; by output, so everyone building the mobile app sits together; by customer or region; or by project. The second is where authority sits: how many bosses one person has, how many levels lie between the person doing the work and the person who can decide, and how much can be decided without climbing them.

No grouping removes coordination. It only chooses which boundary the work has to cross. Group by function and every feature crosses departments; group by product and every shared standard crosses products. The design question is always which crossing you would rather pay for, and the honest answer depends on which one your work crosses most often.

What “hierarchical” actually measures

The second question is where the word hierarchical belongs, and it is a matter of degree. It is set mostly by the span of control — how many people report to one manager. Sixty-four engineers under managers with four reports each need three levels of management and twenty-one managers. With eight reports each, they need two levels and nine managers.

Each level is a hop a decision has to climb and a hop the answer has to come back down. A taller structure gives each manager fewer people and more time for each of them, and makes every decision that crosses teams slower. A flatter one is faster and leaves each manager with less attention per person. Neither is correct. They are different trades, and the useful question is how many hops your most frequent decisions take.

Five ways work gets coordinated

Henry Mintzberg, in The Structuring of Organizations (1979), named five ways people coordinate work, and every structure leans on some of them more than others. Mutual adjustment is people simply talking to each other. Direct supervision is a boss telling people what to do. Standardisation of work processes is a procedure that says how. Standardisation of outputs is a specification of what has to come out. Standardisation of skills is hiring people trained to know what to do without being told.

A five-person startup runs almost entirely on mutual adjustment. A bank’s IT department runs on processes and supervision. A product company with cross-functional teams runs on outputs — a Definition of DoneDefinition of Donewhat "finished" means hereThe checklist a piece of work must pass before anyone may call it done — tested, reviewed, documented, deployed, whatever the team agreed. Its value is that "done" stops being a matter of opinion in a status meeting.Full article →All terms, an APIAPIApplication Programming Interface — contract between programsThe rules one program follows to call another: which requests it may send, in what shape, and what comes back. To the caller it is a contract — everything behind it stays a black box, which is exactly what lets the other side be rewritten without breaking you.Full article →All terms contract — between teams, and on mutual adjustment inside each one. Much of what goes wrong in a reorganisation is a change of structure that silently removes the coordinating mechanism the work depended on, without putting another in its place.

Line, functional, divisional: the classic hierarchies

Line

A line structure is the simplest there is: one chain of command, one boss per person, orders down and reports up. Henri Fayol made its central rule explicit in 1916 as unity of command — each employee receives orders from one superior only. In IT it is the natural shape of a startup: a founder, perhaps a CTO, and engineers who all know who decides. It is fast, cheap and unambiguous. It breaks at the top. The boss has to understand everything that gets decided, and once the company has more specialities than one person can judge, decisions queue at a single desk.

Functional and line-and-staff

Frederick Taylor proposed the opposite of unity of command in Shop Management (1903): functional foremanship, where a worker takes instructions from several specialist foremen — one for the pace of work, one for inspection, one for repairs, one for the order of work and so on, eight in all. It is what Eastern European textbooks call the functional structure. In pure form it barely exists, because a person with eight bosses effectively has none.

What exists everywhere is the compromise: line-and-staff. People are grouped into departments by speciality — development, QA, DevOps, analysis, design — each with one line manager, and staff units such as HR, finance, legal, an architecture office or a PMOPMOProject Management Office — the office that sets project standardsA unit that sets project-management standards across an organisation, collects reporting from its projects and sometimes employs the project managers. Its value depends on which of those it does: a PMO that only gathers status reports adds a layer without adding a decision.All terms advise the line without commanding it. The staff idea comes from nineteenth-century military general staffs, and PMBOK calls the result simply a functional organisation. It grows deep expertise and clear careers. Its failure is the project that needs every department at once: the work queues at each department’s door, each head optimises their own team’s load, and nobody below the director owns the outcome.

Divisional

A divisional structure splits the company into semi-independent units by product, region or customer, each with its own functions inside. DuPont and General Motors built the first ones in the early 1920s, and Alfred Chandler’s Strategy and Structure (1962) turned their story into a rule: structure follows strategy. A division is fast and accountable for its own results. It also duplicates every specialist, and divisions drift into competing with each other — for budget, for customers, and over the platform they ought to be sharing.

Matrix: two bosses on purpose

A matrix lays a project axis across a functional one. The functional manager owns the person: hiring, salary, skills, career. The project manager owns the work: what to do, in what order, by when. The engineer at the intersection has two bosses by design. The form grew up among US aerospace and defence contractors in the 1960s, where hundreds of specialists had to serve several large programmes at once, and it is now the default shape of IT services companies — competence centres or delivery units on one axis, client projects on the other.

How much power sits on each axis is the whole question, and PMBOK names five points on the line between them. The diagram shows authority moving from one manager to the other; the table gives PMBOK’s own terms for each point.

In a weak matrix the project manager is really an expediter or a coordinator: they chase, report and persuade, and every real decision about people goes back to a department head. The job is legitimate and hard. The common mistake is to accept its accountability — for a date — without its authority. In a strong matrix the project manager decides priorities and the functional manager supplies people and standards; the engineer’s performance review should then carry the project manager’s input, or the second boss quietly becomes the only one.

Nine ways a matrix fails

Stanley Davis and Paul Lawrence studied matrix companies for Harvard Business Review in 1978 and named nine pathologies the form is especially prone to. Most organisations suffer some of them anyway; a matrix is simply more vulnerable. The list has aged remarkably well.

What keeps a matrix working is not a better chart but written decision rights. Who decides priority between projects: one named person, not a committee. Who decides how the work is done: the team, within the department’s standards. How much of each person’s time belongs to which project: agreed per quarter, not fought over weekly. Whose voice goes into the performance review: both. Christopher Bartlett and Sumantra Ghoshal’s 1990 HBR title says the rest — matrix management is not a structure, it is a frame of mind.

Project structures and product teams

At the far end of PMBOK’s scale sits the projectized organisation. The team belongs to the project; the project manager hires, directs and releases people; the budget is theirs. It is the cleanest structure for one large deadline — a government system, a migration programme, a launch. Its weakness arrives on the last day. When the project closes, the people have no home, the knowledge disperses, and whoever maintains the system next has met none of the people who built it.

Product companies went the other way. Instead of assembling a team around each piece of work and disbanding it afterwards, they keep stable, long-lived cross-functional teams — every skill the product needs, inside one team — and bring the work to the team. The team is what persists; projects become the next items in its backlog. Most agile methods assume this shape, and Scrum’s accountabilities describe it.

The Spotify model is a matrix

The best-known version is Spotify’s, described by Henrik Kniberg and Anders Ivarsson in 2012. Squads are small cross-functional teams, each with a product owner. Squads working on related areas form a tribe. People with the same speciality across squads form a chapter. Guilds are voluntary communities of interest that anyone can join. The paper is explicit about the shape: it is a matrix, with the squad — the delivery axis — as the primary dimension, because that is where people sit and spend their time. The chapter lead is the line manager, responsible for salary and growth, and also works in a squad.

Two things are worth knowing before copying it. The paper was a snapshot of one company in 2012, and people who worked there later wrote that much of it never worked quite as drawn — Jeremiah Lee’s 2020 essay is the best known. And renaming departments to chapters and teams to squads changes nothing unless the decision rights move with the names.

Team Topologies: four team types

Matthew Skelton and Manuel Pais’s Team Topologies (2019) is the most widely used modern vocabulary for designing these teams. It names four team types and three ways teams interact: collaboration, working closely together for a limited time; X-as-a-Service, one team consuming what another provides with minimal contact; and facilitating, one team helping another learn something.

• Stream-aligned team

  Owns one flow of work — a product, a customer journey — from idea to production. Most teams should be this kind; the other three exist to make its work easier.

• Platform team

  Provides internal services that stream-aligned teams consume on their own — deployment, observability, data — so no team rebuilds infrastructure for itself.

• Enabling team

  Specialists who help another team acquire a capability — testing automation, security, a new framework — and then step away rather than doing the work for it.

• Complicated-subsystem team

  Owns a part that needs rare expertise — a video codec, a pricing engine, a recommendation model — so the stream-aligned teams do not all have to learn it.

Conway’s law: the structure ends up in the code

In April 1968 Melvin Conway published a short paper in Datamation — Harvard Business Review had rejected it for not proving its thesis — with a sentence now known as Conway’s law: organisations which design systems are constrained to produce designs which are copies of their communication structures. Three teams produce a three-part system, with the interfaces exactly where the teams have to talk to each other.

The diagram is the practical consequence. Group engineers by layer — a frontend team, a backend team, a database team — and the system grows in layers, so every feature a user asks for crosses three teams, three backlogs and two hand-offs. Group them by product stream and the architecture follows the streams, so most features stay inside one team. Arranging teams on purpose to get the architecture you want is called the inverse Conway manoeuvre. It is also why a move to microservices that leaves the org chart untouched usually rebuilds the monolith one network call at a time; the Monolith to Microservices page covers the migration side of that story.

The evidence from Windows Vista

For forty years Conway’s law was an observation. In 2008 Nachiappan Nagappan, Brendan Murphy and Victor Basili tested it on Windows Vista: 3,404 binaries and more than 50 million lines of code. They built models to predict which binaries would fail after release, and measured the organisation around each binary — how many engineers had touched it, how many of them had left, how far apart in the org chart its contributors sat, how many separate organisations contributed to it. The organisational measures predicted failure better than any of the code measures.

Precision is how many of the binaries the model flagged really did fail; recallrecallshare of targets foundThe share of the things you were looking for that a system actually found: a recall of 80% means one in five was missed. It is the number that matters when a miss is expensive, and it is traded against precision — how many of the things found were real.All terms is how many of the failing binaries it found. The finding is not that code does not matter. It is that who works on the code, and how far apart they sit, is at least as predictive of quality as the code itself. Brooks said as much in 1975; this was one of the first large-scale measurements to agree with him.

Without managers: flat and self-managing

Every generation of companies tries to remove the hierarchy altogether, and the attempts are unusually well documented. Two are worth knowing in detail, because both were run by people who meant it.

Jo Freeman explained the pattern in 1972, writing about activist groups rather than companies, in The Tyranny of Structurelessness. A group without a formal structure does not become structureless. It develops an informal one, run by whoever has the most time, confidence and friends — and that hierarchy is worse than a formal one, because it cannot be seen, questioned or removed. Flat organisations that last replace the chain of command with explicit, written rules about who decides what. The ones that fail remove the chain and write nothing in its place.

Where restructuring turns into theatre

A reorganisation is the most visible thing a leader can do, and one of the easiest to do without changing anything. These are the shapes the theatre takes.

• A reorganisation announced instead of a decision: the real problem was a priority nobody would set, and the new chart moves the same argument to new names.
• Squads, tribes and chapters painted over departments that still decide everything.
• A “strong matrix” on paper, in which the project manager cannot move one engineer or one euro.
• Accountability for a date given to someone who controls neither the people nor the budget.
• “We are flat”, in a company where everyone knows whose opinion actually settles things.
• Two bosses, each assuming the other is handling the performance review.
• A structure copied from a famous company’s blog post, without the product, the scale or the people that made it work there.

The honest limit: there is no structure without a cost, only a choice of which cost. Every structure is a decision about which boundary the work will cross most often, and Conway’s law guarantees that boundary will show up in the product. A structure also cannot supply what it depends on — trust between the two axes of a matrix, managers who can say no, decision rights someone took the trouble to write down. If those are missing, a new chart moves the missing thing into a new shape. If they are present, most structures in this page’s first table work better than their reputation.

When to use it

Related pages

• ManagementPMBOKThe PMBOK Guide is PMI’s standard reference for managing projects; its Eighth Edition (November 2025) sets out six principles, seven domains and forty processes. It is the third different document to carry the name in under a decade: the 6th edition prescribed 49 processes, the 7th replaced them with twelve principles, and the 8th brought processes back. The page opens with every element of the current edition on one screen, then covers which edition someone means, the six principles, how domains and processes fit together, tailoring on one project, PMBOK next to PRINCE2 and Scrum, the Phoenix pay system, and where it degrades.
• DevelopmentMonolith → MicroservicesMigrating a monolith to microservices means moving an existing system’s capabilities into separately deployed services one at a time, without stopping the system. The migration that works is not a rewrite with a cutover date but a sequence of small extractions behind a facade, each justified by a measured constraint and each with a way back; the hard part is the data. The page opens with one extraction as sixteen steps, then covers what to extract first, six ways to move code without stopping, splitting the data, the model and the teams, running the migration and knowing when to stop, five documented cases, and where it degrades.
• ManagementPM Checklist for a New ProjectA project manager’s first ninety days on a project they did not start is a diagnosis followed by a small number of deliberate changes, not a reorganisation. Month one is for finding out how the work actually flows, month two for agreeing what you will change and with whom, month three for making the first changes land and being able to show what they moved. This page is that checklist, with the situational judgement that decides which parts of it apply to you.