Analyse a model

Once a model has structure in it, the views down the left of an open model are how you interrogate it. They’re all read-only: nothing here changes the model, so click freely.

Summary

The overview. Headcount, how much of it is filled, and what the whole thing costs.

Cost is split into filled and vacant, which is usually the number that matters — not what the organization costs today, but what it costs fully staffed. The unit tree below rolls cost up the hierarchy, so a parent shows the total of everything beneath it and you can expand toward whichever branch looks expensive.

A Headcount card counts the positions three ways, for example 12 named · 2 placeholders · 3 vacant: held by a person, spoken for by a placeholder, or vacant. Each figure opens the Slots view filtered to those positions, and when hires are under way the card also lists the vacant and placeholder positions by hiring stage (a placeholder can have a hire under way too, so these can add up to more than the vacant count), each linking to the Slots view filtered to that stage. The same three-way split runs through the metric strip at the top of every view, the Counts and Costs cards, and the Compare headline.

The Summary also reports unmatched positions — ones no cost profile covers, and which are therefore contributing nothing to your total. Treat a non-zero count as a to-do list; the total is understated until it’s zero.

When a readiness checklist applies to some of the model’s units, a Readiness card shows, per checklist, the average readiness across those units and how many of them are through each gate (every item of the gate Done). Open the readiness grid goes to the Readiness view.

When units break a composition rule, a Unit shape card sums it up per rule and role, for example Pods: 4 missing a Product Builder · 2 unstaffed Product Engineer. The first counts units short of the role, the second counts required positions nobody holds yet. Each count opens the Problems view filtered to just those problems, with Show all problems to go back to the full list. The card is not shown when the model meets every rule, or the organization has none.

Counts and Costs

Pivot tables — the same shape twice, once for headcount and once for money.

Break the model down by role, role category, level, location, company, or vacancy, against the unit hierarchy, and read off where headcount and spend actually sit. The vacancy breakdown splits positions into filled, placeholder (vacant, but spoken for), and vacant; a placeholder costs what a vacancy costs. Empty rows and columns can be hidden to get a dense table out of a sparse organization.

Both views also plot a trend when the model has time in it — either across the points on a timeline or across the start and end dates on individual positions. You can plot at each change or at a regular monthly interval. Where a timeline is in play, there is a column per point, and each column clicks through to the model behind it. A snapshot placed on the timeline is a point like any other; snapshots left off it don’t appear.

Positions shared across several units contribute once to headcount and have their cost divided between those units, so the rollups still add up. There’s a toggle for showing those partial counts explicitly.

Timeline

Who joined the model and who left it, period by period, on a vertical rail. Each period lists its Joiners and Leavers — people, not positions — and the top of the page totals them with the net change for the range shown. A row opens the person’s position in this model, or links to the point on the timeline they come from when this model doesn’t place them.

The view needs time in the model, on one of the same two axes the trend views use (see Planning over time):

Axis	A joiner is someone who…	A leaver is someone who…
Start and end dates on the model’s own positions	starts a position on that day, having held none the day before. Listed under the position’s start date.	holds a position until its end date and none the day after. Listed under their last day — someone whose last day is 31 March left in March.
The model timeline — the dated points the model shares a timeline with	is in a point but wasn’t in the point before it. Listed under the later point’s date.	was in the point before but isn’t in this one. Listed under the date of the first point they’re missing from.

On the model timeline, each period says once which two points it compares, and its rows read New at this point or Not at this point; a period holding more than one comparison names the point in each row instead. A timeline needs two or more dated points: with only one, and no start or end dates on the positions, the page has nothing to show and offers Go to Slots to add dates, or Start or add to timeline.

A few rules hold on both axes:

People, matched by who they are. Someone who moves from one position to another without a gap — a handover, or a change of role between two points — is neither a joiner nor a leaver. With a gap between the two positions, they leave and join again.
Vacant positions don’t count. A vacancy opening or closing isn’t a person joining or leaving.
Positions with dates count only while in effect. On the model timeline, someone whose position ended before a point’s date isn’t in that point, so they show as leaving there — matching the headcount the Counts trend draws at that point.
The first point is the starting line. Nobody joins at it, because there’s nothing before it to compare with. Points that share a date count as one: a plan wins over a snapshot with the same date.

Group by sets the period: Day, Week (starting Monday), Month (the default), Quarter or Year. Periods with no joiners or leavers are left out unless you turn on Show empty periods, and Newest first / Oldest first flips the order. Someone who joins and leaves within one period appears in both lists. The period, the empty-periods switch, the axis and the filters are kept in the address, so a link opens the same view.

When the model has both axes, the Model timeline switch chooses between them. It’s on by default and is the same switch as on the Counts trend, so the two views stay on the same axis.

Day and week on the model timeline

On the model timeline, changes are known only between points: if the points are three months apart, nothing says which day within those three months someone left. A period shorter than the gap between points can’t split it, so each change is listed in the period that holds the point it was first seen in. With Show empty periods on, the periods in between read no changes are known rather than nobody joined or left. The page shows a note whenever the chosen period is finer than the spacing of the points. Pick a period at least as long as the gap — Quarter for quarterly points — to read the timeline at its real resolution; the start-and-end-dates axis has no such limit.

Filters

The Filter button narrows the view by role category, role, location, company and level — the same filters as Counts and Costs, kept in the same link parameters, so a link to one view carries its filters to the other. A person counts while they hold a position that matches. That means someone who moves out of the filter is a leaver of the filtered view: filter on Engineer, and an engineer promoted to Senior Engineer shows as leaving at the point where the promotion appears. The label beside the button says how many changes are listed and how many filters are on, so a filtered view is never mistaken for the whole.

The person-status filter (filled or vacant) and the partial-counts toggle from Counts don’t apply here: the Timeline lists people, so it is filled positions only, and each person counts once however many units their position is shared across.

Rollout

When each unit goes live, as a timeline: one row per unit, one column per month, with a line for today and one for the model’s effective date. Units without a start date sit in the TBD lane on the right. A start date known only to the quarter (“Q1 2027”) spans the quarter’s three months; the thinner track after it runs to the unit’s end date, or off the edge when it has none. See Rollout state for how dates become Planned, Live, Ending, Ended and TBD. Each bar names its state in words and with an icon — the legend shows which is which — so it never depends on colour; a live unit without a start date sits in the TBD lane but reads Live · start TBD.

The strip above the chart counts units by state: Live, Ending, each month or quarter that planned units go live in, TBD, then Ended.

Units with label picks which units are shown. It starts on the most-used label whose key is Type (for example Type: Pod), so a model of tribes and pods opens on the pods; choose All units to see everything.
Group by sets the row groups: the parent unit (the default), or the value of one label key, such as Region.
A bar is hatched, and carries an icon, when the unit has vacant slots or breaks a composition rule. Its name says which, so it never depends on colour.
Select a unit to see its slots and who fills them, its description, labels and dates.

If you can edit the model, drag a bar to another month, or into or out of TBD, to change when the unit goes live. A move keeps how precisely the date is known: a month stays a month, a quarter moves to the quarter you drop it in, and an exact day keeps its day of the month. A quarter unit dragged out of TBD lands on a quarter again; any other unit lands on the month. Without a mouse, focus a bar and press ← or → to move it a month (a quarter for a quarter date), or Delete to move it to TBD; a unit’s details have Earlier, Later and Move to TBD buttons too. Undo (or Ctrl+Z / ⌘Z) reverts the last move, and each move’s message has its own Undo. A unit can’t be moved past its end date. Every move is an ordinary change to the unit, so it shows in the audit log.

Table shows the same units as a table — state, start, end and what needs attention — for reading exact values or using a screen reader. On a phone the chart becomes a list of units under each go-live month.

When a readiness checklist applies to a unit, a readiness ring sits beside its name and its readiness percentage is on its bar, in the table’s Readiness column and beside it in the phone list.

Readiness

Which units can start, which are blocked, and on what. For a readiness checklist, the grid has a row for every unit the checklist applies to and a column for every item, under its gate’s heading, with each unit’s readiness last. Above the grid, a ring shows the checklist’s readiness across all those units. When more than one checklist applies to the model’s units, Checklist picks which one is shown.

Sort by orders the rows: Group (under a heading per parent unit, or per value of the label key chosen in Group by), Go-live date (units without a start date last) or Readiness (most ready first).
Each cell shows the item’s state with its icon; the legend says which is which. A shaded cell with a link icon in its column heading follows the unit’s staffing under a composition rule, and a dash means the item is not counted.
Point at or focus a cell to read what its item means under the grid. What each item means lists every gate and item with its help text.

If you can edit the model, click a hand-set cell to move it to the next state: Not started, In progress, Done, then back to Not started. The item’s note is kept. Derived cells can’t be changed here; filling the position does that. Without a mouse, the grid is one stop in the tab order: the arrow keys move between cells, Home and End go to the ends of a row (with Ctrl, of the grid), Page Up and Page Down move ten rows, and Enter or Space cycles a hand-set cell. On a narrow screen the grid scrolls inside its own frame, with the unit names and headings kept in view.

Units, Org Chart, Diagram, and Matrix

Four ways of seeing the same structure:

View	Shows
Units	The hierarchy as an editable tree, with a panel for the selected unit’s positions and people.
Org Chart	The reporting structure, drawn from each position’s reports to. It opens centred on the top of the organization, at a size you can read. Large organizations open with only the top levels showing, as many as fit your screen, so the chart stays quick to read and to move around; the arrow at the foot of a position’s card shows or hides the people who report to it, and while they are hidden it shows how many there are. Expand all and Collapse all in the toolbar open or close every branch at once, and Fit to screen beside the zoom buttons brings the whole chart into view, however small that makes it. A filtered chart shows each matching position under its real manager, with the managers that don’t match the filters faded so you can see where the matches sit; it opens on the matches, and the arrow on a closed branch shows how many matches it hides. Positions with no manager and no reports are gathered into a grid below the chart.
Diagram	Units as cards with their positions inside — the shape of the organization rather than its reporting lines. Sibling units sit side by side and wrap to the next line when there’s no room. Deep hierarchies start with the first three levels open; pick how many levels to expand from the toolbar, or collapse and expand any unit with the chevron in its header. A collapsed unit still shows its position counts and how many units sit beneath it. Toggle which attributes are shown on each position.
Matrix	A crosstab of roles against units, either orientation, for spotting which teams hold which capabilities and where the gaps are.

In every view a placeholder shows its label in italics with a Placeholder tag, and a vacant position with a hire under way shows its hiring stage (Planned, Approved, Open, Offer accepted) as a chip, so neither depends on colour to tell apart. The status filter offers Filled, Placeholder and Vacant; Vacant leaves placeholders out, to match the counts.

Slots and People

Slots lists every position in the model as a table: filter by unit, by any attribute, by status (filled, placeholder or vacant) or by hiring stage, sort by any column, and export the result to CSV. The search also finds a placeholder by its label or requisition, and the export carries each position’s status, placeholder label, hiring stage and requisition. It’s the view to reach for when the question is a list rather than a shape. Download model table saves the whole model instead, whatever the filters, as one flat table: a row for each position in each of its units, with the unit’s path, labels and dates, the position’s attributes, who holds it, its notes, open comments and problems. Choose the version without names when you want to share it.

People shows the model from the other side — who’s placed in it, and who in the organization isn’t. Each person shows every unit they’re assigned to, and the unit filter and search match any of them. Export the list to CSV to get one row per person, with their external ID, the units they’re assigned to, and the top-level unit each of those sits under. Search and filters apply to the export.

Problems

An automatic review of the model, run each time you open the view. It reports:

Problem	Meaning
Duplicate person	Someone is assigned to more than one position in this model.
Attribute mismatch	A person’s own role, level, location, or company differs from that of the position they occupy.
Reporting cycle	A chain of reports to that loops back on itself.
Orphaned slot	A position that belongs to no unit. In a model whose bench is intentional, these are reported as information rather than a problem.
Composition shortfall	A unit has fewer positions of a role than a composition rule requires.
Composition excess	A unit has more positions of a role than a composition rule allows.
Unstaffed seats	A unit has the positions a composition rule requires, but too few of them are filled.
Placeholder recorded as a person	A position is held by a person record that looks like a stand-in for a seat rather than a real hire. See Placeholder people.

Several offer a fix in place — combining duplicate assignments or clearing one of them, aligning mismatched attributes in either direction, breaking a reporting cycle, removing orphaned positions. Each problem in the list names the positions it concerns — who holds them, and for a duplicate the units they sit in, for a reporting cycle whom each reports to. An attribute mismatch lists each mismatched attribute with its current value and the value the fix will set it to, both in the list and in the fix dialog, so you can check the change before applying it. Aligning a mismatch by copying the position’s attributes onto the person pins them as overrides, so the rules that derive a person’s attributes won’t undo the fix.

Not every problem is worth fixing — a deliberate dual assignment, say, or a contractor whose attributes are meant to differ from the position. Every problem in the list has an Ignore button beside Fix, and the fix dialog offers Ignore beside Apply Fix wherever you open it from — the Problems view or a position’s problem badge. An ignored problem leaves the list, the counts, and every slot badge in the model. Ignored problems stay available on this page behind the Show ignored toggle, where you can unignore any of them. An ignore applies to the problem as it was when you ignored it: if it changes — a reporting cycle picks up another position, a different attribute starts to mismatch — it is reported again as a new problem.

Not everything reported is a mistake. Somebody deliberately holding two positions, or acting up into a more senior post, will show here and is fine. The view’s job is to make sure it’s a decision rather than an accident.

Placeholder people

Before placeholders existed, a seat that was spoken for but not by a named hire was often modelled as a made-up person, such as “Team X - SE” or “Backfill”. The Problems view flags these so you can turn them into placeholder positions. A person is flagged when they have no email and no external ID, and either:

their name matches the organization’s placeholder name pattern, or
they hold two or more positions across the organization’s working models (copies of the same position in a scenario count once; snapshots and archived models don’t count).

People with an email or an external ID, or who are synced from an integration, are never flagged.

Fix unassigns the person and makes the position a placeholder labelled with their name, which the audit log records. If the person then holds no position anywhere, an organization admin is offered to delete the person record; nothing is deleted unless you choose to. When the view lists placeholder people, Convert all placeholder people fixes every one of them in the model at once, leaving ignored ones alone. Ignore a problem to say the person is real: neither fix, nor the assistant’s tools, will then convert that position.

The pattern is a case-insensitive regular expression, set by an organization admin under Organization Settings → Problem Detection. Left blank, it uses the default, which matches a name containing “ - “, or the word TBD, TBH, or Backfill. A pattern that is not a valid regular expression is flagged as soon as you leave the field, with what is wrong and how to fix it (for example a missing )), and cannot be saved.

Composition rules

A composition rule says what a kind of unit should contain: “every pod has one Product Builder and one Product Engineer”. Rules belong to the organization, are managed by an organization admin, and apply in every model. Each rule’s name is unique in the organization.

Which units. A rule applies to every unit carrying a label, such as Type: Pod. Deleting the label deletes the rules that target it.
What they need. Each requirement names a role, or a role category to accept any role in it, with the fewest positions the unit should have and, optionally, the most. Deleting a role removes it from every rule, and a rule left with no requirements is deleted with it.
Where to count. By default only the positions directly in the unit count. A rule can also count everything beneath the unit, each position once.

Rules live under Configuration → Composition Rules. Everyone in the organization can see them; an admin adds, edits and deletes them there. Each rule lists what it targets and requires, and how many units in each model break it right now, with a link to that model’s Problems view. The counts can take a moment, since every model is checked.

The quickest way to write a rule is to start from a unit template: open the template and choose Create rule from template. The rule comes prefilled with one requirement per role among the positions on the template’s root, as many as the template has, and targets the template’s first label. Positions in the template’s own sub-units and positions without a role are left out. Change anything you like before creating it; if the template has no label, pick the label that marks that kind of unit.

Every position in the model counts, whatever its start and end dates: a position that has ended still counts until it is removed from the model, as with the other checks. A vacant position still counts toward a requirement, because the seat exists. A unit that has the seats but not the people is reported as unstaffed seats, separately from a shortfall, so “missing a seat” and “seat not yet filled” never read the same. The fix for a shortfall adds the missing positions to the unit, vacant and with the required role; for a requirement that accepts any role in a category, the fix asks which role to add when the category has more than one. An excess and unstaffed seats have no automatic fix: decide which position to remove, or who to place. Ignoring a composition problem applies to that unit, rule and role, and holds while positions come and go.

Composition problems also show where you plan:

Units. A unit that breaks a rule gets an amber edge and a marker beside its name; a unit whose required positions exist but are not all filled gets a blue one. Hover or focus the marker to see what the unit is short of, or select it to see the problems with Fix.
Org Chart. A position’s unit chip carries the same marker, and a unit with a problem shows its chip even when Show units is off. Turning off Problems in the toolbar hides the markers.
Positions. A vacant position that a rule requires is marked Unstaffed, rather than with the warning used for other problems, in every view that shows problem badges.

Audit log

Every model carries its own audit log — what changed, when, and who did it. There’s an organization-wide log as well, covering everything else. For a single position, open its details and switch to the Audit Log tab to see that position’s own history, change by change.

Cost profiles — fixing unmatched positions.
Planning over time — what makes the trend and Timeline views work.
Compare and merge — analysing two models against each other.