← systeric.com Interwise / Docs
Open App →

Org Design & the Star Model

Reorganising is the most visible thing a leader can do and the least likely to work on its own. Everyone has watched a company redraw the boxes, announce it, and discover six months later that the same decisions take the same length of time and go to the same people.

Jay Galbraith’s explanation, and the reason his model is still the standard reference for org design, is that structure is only one of five things that have to move together.

The five points#

The Star Model puts strategy at the centre of the decision and four levers around it.

strategy structure processes rewards people
Every point is joined to every other point. That is the argument, not the decoration: move one and the other four are now out of alignment with it, whether or not anyone updates them.
  • Strategy decides direction and what the organisation has to be good at.
  • Structure is where authority sits: the boxes, the reporting lines, how work is grouped.
  • Processes are how information and decisions actually move, which is often nothing like the boxes.
  • Rewards are what the company pays for: goals, bonuses, promotion criteria.
  • People are the skills and the practices for developing them.

The failure Galbraith describes is the one everyone has lived through. A company changes the structure and leaves the other four alone, so the new structure asks for collaboration while the rewards still pay for individual results, the approval process still routes through the old owner, and nobody has the skills the new roles assume. The boxes moved. Nothing else did.

How to tell you are in it: ask what changed about how someone is measured and who signs off. If the answer to both is nothing, the reorganisation has not happened yet regardless of what the chart says.

Spans and layers#

Two numbers describe the shape of a structure and are worth knowing because managers ask about them.

Span of control is how many people report to one manager. Typical healthy ranges are five to eight for work needing real supervision, and much wider where the work is standardised. Too narrow and managers manage too closely and the layer exists to justify itself; too wide and nobody gets attention.

Layers are the levels from the most junior person to the chief executive. Beyond six or seven, decisions slow measurably because each layer adds a queue.

They trade against each other: widening spans removes layers. Most organisations that feel slow are carrying layers they added one reasonable promotion at a time.

What an org chart actually is, for us#

Here the framework becomes a data model problem, and this is the part that matters most for what we build.

A position is not a person. A position exists whether or not anyone is in it. It has a title, a grade, a cost centre, and a place in the hierarchy. People occupy positions, leave them, and are replaced. A vacancy is a position with nobody in it, and headcount planning is entirely about positions rather than people. Systems that model only people cannot express a vacancy, so they cannot express a hiring plan either.

Reporting lines are effective-dated. Someone reported to A until March and to B afterwards. Both facts are true, and a system that stores only the current manager has destroyed the first one. That breaks retroactive payroll, historical approvals, and any question that begins “who approved this at the time”.

There is more than one hierarchy. The reporting line, the cost centre, and the approval route are three different structures over the same people, and they diverge in real companies. Somebody reports to a team lead, is charged to a project’s cost centre, and has leave approved by a department head. Collapsing these into one tree is the most common modelling mistake in HR software, and every workaround a customer invents afterwards exists to reconstruct what was collapsed.

Sari Budi Rina people only lead / G5 Sari eng / G3 Budi eng / G3 vacant positions, then people
The same team modelled two ways. Only the right-hand version can say that a job exists and nobody is doing it, which is the fact every hiring plan, budget and cost forecast is built on.

Why this matters to our strategy#

Our org chart is not a visualisation feature. It is the structure that approvals, leave routing, cost allocation and salary comparison all read from, which means an error in it surfaces as a wrong payroll outcome rather than as a wrong-looking diagram.

The specific risk to our positioning is history. We are selling the ability to explain a number, and a retroactive change is exactly when a customer most needs the explanation: someone moved teams in March, and the question in June is what they should have been paid and who approved it. If our model stores only the present, that question is unanswerable, and one unanswerable question of that kind reopens the spreadsheet permanently.

So effective dating is not a sophistication to add later when enterprise customers ask. It is load-bearing for the trust we are trying to earn, and it is close to impossible to retrofit once real history exists.

What this means for what we build#

  • Model positions, then place people in them. A vacancy must be expressible on day one, because headcount planning and cost forecasting both depend on it.
  • Effective-date reporting lines and structural changes. Every structural fact needs a validity period, and every historical query needs to resolve against the structure as it was.
  • Keep the hierarchies separate. Reporting line, cost centre and approval route are three relationships, not three views of one. Let them coincide by default and diverge when the customer needs it.
  • A reorganisation must never rewrite history. Applying a new structure creates a new period. It does not update the old rows, and prior payroll runs must continue to resolve exactly as they did.
  • Show spans and layers where a manager can see them. It costs us almost nothing and is the one piece of genuine org-design insight a small company will never otherwise get.