Setup Sequence, Scenarios & Quick Reference

1. Recommended Setup Sequence

Use the sequence below only after the key terms and level logic are understood. This prevents the company from assigning titles, codes or reporting lines before the underlying structure is clear.

Define the planning horizon and target headcount

For example, the next 24 months.

Define the company-wide grade/level framework

Agree what each level means in terms of experience, scope, decision authority, accountability and leadership expectations.

Create the department master

Assign stable department codes.

Create teams under each department

Assign team codes.

Create sub-teams where needed

Only where a team needs a meaningful permanent split; otherwise use the agreed “00 / Not Applicable” value.

Define the required positions

At department, team and sub-team level, then assign a suitable Position Name, Position Title and Level to each seat.

Generate a unique Position ID

Use the approved code structure for every seat.

Assign one primary Reports To position

For every operational position except the single top/root position.

Map employees to positions

Unfilled seats remain Vacant.

Validate the structure

Check for duplicate IDs, missing reporting lines, circular reporting and unnecessary layers before publishing the org chart.

Five phases left to right: Frame (plan headcount, define the grade framework), Structure (departments, teams, sub-teams as org units with codes), Seats (positions, position codes, reports-to), People (assign employees), Check (validate). Arrows between phases carry what each hands to the next: grade codes and org-unit codes become segments of every seat code; seats are what people are assigned into. A note explains that only bulk import enforces the checks.

Why the recommended setup order matters — each phase depends on the one before it.

2. Common Scenarios

Scenario	Decision	Recommended handling	Why
1. Two or more positions report to one manager	Allowed	Create separate Position IDs for each subordinate seat and point each to the same manager Position ID.	Typical team structure.
2. One employee supervises several teams	Allowed if structurally intended	Keep one manager position if the role genuinely owns those teams; child positions can come from different teams/sub-teams.	Useful for small organisations before dedicated team heads are hired.
3. A functional manager is not yet mapped to an employee	Keep the manager position Vacant	Subordinate positions may still report to the vacant manager position. Do not redirect the structure to a random person only because the seat is empty.	Preserves target-state design.
4. A manager position does not exist at the next immediate level	Use the nearest appropriate higher approved position	Do not create a fake intermediate layer only to force L30 → L40 → L50.	Levels may be intentionally skipped.
5. Team roles report to a department-level manager	Allowed	Use team/sub-team 00 for the manager seat where the role genuinely covers the full department/team.	Common for shared functional heads.
6. Two founders both want to appear “at the top”	Use one operational root	Map one CEO/MD/root for the primary hierarchy. A co-founder can be another CXO/Founder position or a governance role.	Prevents two-parent trees.
7. Board / investors exist above management	Treat as governance, not daily line management	They may appear as separate governance nodes or categories and should not automatically become the Reports To for all employees.	The uploaded grade master separates Board Members and Investors.
8. One person is CEO and CTO in an early-stage company	Create two separate seats; map the same person to both only if the product permits multi-position occupancy	Do not merge the structural roles into one ID if the 2-year plan expects them to become separate hires.	Keeps future hiring plan intact.
9. An employee is promoted	Move the employee to the new Position ID	The old seat becomes vacant or is closed/end-dated. Do not rewrite the old Position ID.	Preserves history.
10. An employee transfers departments	Map the employee to a position in the new department	Do not change the department code of an old historical Position ID just to follow the employee.	Position belongs to structure, not person.
11. A role is temporarily handled by an acting manager	Keep the original position and record acting assignment separately if supported	Do not permanently change all child reporting lines for a short-term absence.	Useful for leave or recruitment gaps.
12. A team is merged or split during reorganisation	Create/effective-date the new structure and retire old seats	Avoid recycling old codes or silently changing their meaning.	Supports audit history.
13. A cross-functional project needs two managers	Keep one primary Reports To; manage project accountability outside the line hierarchy	Do not create dual primary parents merely for a temporary project.	Project structure and org structure serve different purposes.
14. A position is planned for next year but not hired yet	Create as Planned/Vacant if it is part of the approved 2-year structure	Do not add a dummy employee.	Enables headcount planning.
15. A department has only one person today	Create the future position structure only to the level justified by the 2-year plan	Avoid creating unnecessary layers just because the template contains them.	Keeps the org lean.
16. A person has many direct reports	System may allow it; review span of control	If the number becomes difficult to manage, introduce a genuine team lead/manager layer rather than arbitrary hierarchy.	No universal number suits every function.
17. A team code is no longer used	Retire the code; do not reuse it for a different meaning	Reusing codes can make historical Position IDs ambiguous.	Stable master data is essential.
18. Two positions need the same title and same grade	Allowed	Create separate serial numbers for each seat.	Headcount is position count, not unique title count.
19. A contractor or advisor needs to appear in the chart	Use a separate worker/contractor category or designated level/type	Do not force all external roles into the employee grade ladder if the framework distinguishes them.	Keeps employment type clear.
20. An employee leaves	Unmap the person; keep the position Vacant unless the role itself is removed	Do not delete the position just because the incumbent exits.	This is the core benefit of position-based design.

3. Quick Reference — Allowed / Not Allowed / Best Practice

Case	Rule	Guidance
Several positions at the same grade	Allowed	Use unique position IDs/serial numbers.
Several positions reporting to one manager	Allowed	Normal one-to-many hierarchy.
One position with two primary managers	Not recommended	Use one primary + optional functional/dotted-line relationship.
One organisation with two independent operational roots	Not recommended	Choose one CEO/MD/root; keep other top roles as peers below or governance nodes.
Vacant manager position	Allowed	Keep child roles reporting to the vacant position.
Vacant employee seat	Allowed	Show as Vacant/Planned rather than deleting it.
Skipping unused hierarchy levels	Allowed	Use only levels needed by the design.
Circular Reports To	Not allowed	Validation should block publishing.
Self-reporting position	Not allowed	Validation should block publishing.
Duplicate Position ID	Not allowed	Serial must make each seat unique.
Changing a Position ID when the employee changes	Do not do	Remap the person; keep the seat stable.
Deleting used positions	Avoid	Prefer inactive/end-dated status for audit history.
Using employee names in department/team/position codes	Do not do	Codes should represent structure, not people.
Creating every possible level in every function	Avoid	Design to the approved 2-year headcount and span of control.
Using “00” for unknown information	Do not do	Use “00” only for agreed general/not-applicable structural scope.
Same Position Title at different levels	Allowed	Use the Level / Grade as the company-wide indicator of seniority.
Using Position Title alone to compare seniority	Avoid	Titles vary by department; compare the approved Level / Grade instead.

Get Started

User Guides

Video Library

Glossary

Setup Sequence, Scenarios & Quick Reference

1. Recommended Setup Sequence

2. Common Scenarios

3. Quick Reference — Allowed / Not Allowed / Best Practice

​1. Recommended Setup Sequence

​2. Common Scenarios

​3. Quick Reference — Allowed / Not Allowed / Best Practice

​Related Guides

1. Recommended Setup Sequence

2. Common Scenarios

3. Quick Reference — Allowed / Not Allowed / Best Practice

Related Guides