Job Architecture & Career Levels: An HR Setup Guide
How to build job families, career levels and pay bands from scratch: designing the ladder, the dual track, mapping existing employees through calibration, and running a credible...
Job Architecture & Career Levels: An HR Setup Guide
Somewhere between fifty and two hundred employees, almost every growing company hits the same wall. Two people doing near-identical work have titles three words apart and salaries thirty per cent apart. A high performer asks "what's next for me?" and nobody has a real answer. A manager promotes someone to "Senior" as a substitute for a raise. Recruiters quote whatever the market asks. Promotion decisions are made in one-to-one conversations that nobody else can see or challenge.
The fix is job architecture: a deliberate structure of job families, levels and role definitions that everything else — compensation bands, career paths, promotion criteria, performance expectations, hiring — hangs off. This guide explains how to build one from scratch, in a way that a small HR team can actually maintain.
What job architecture actually is
Job architecture has three components. Confusing them is the most common early mistake.
1. Job families. Groupings of similar work. Engineering, Product, Design, Sales, Customer Success, Finance, People, Operations. Within a family, sub-families where the work meaningfully differs — within Engineering, perhaps Backend, Frontend, Data, Infrastructure, Quality.
2. Levels. A ladder of scope, complexity and impact that runs across the whole organisation. Level 3 in Engineering and Level 3 in Finance represent comparable organisational scope, even though the work is entirely different.
3. Roles. The intersection of a family and a level — "Backend Engineer, Level 4" — with a definition of what someone at that intersection is expected to do.
Titles are a fourth, separate thing. Titles are what appears on a business card. Levels are what drives pay bands and expectations. Keeping these separate is liberating: you can give a customer-facing person an impressive title without distorting your compensation structure, and you can maintain a clean internal ladder without arguing about external optics.
Why build one
The benefits compound, but four are immediate.
Pay equity becomes measurable. Once every employee has a level, you can ask whether people at the same level are paid comparably — and answer it. Without levels, pay equity analysis is guesswork.
Promotion becomes a decision, not a favour. With published level criteria, promotion is an assessment against a standard. Without them, it is a negotiation, and the people who negotiate best get promoted fastest — which is rarely the same as the people who contribute most.
Career conversations have content. "What do I need to do to get to the next level?" has a real answer. Managers stop improvising and start coaching against a shared reference.
Hiring gets consistent. A requisition specifies a level, the level has a band, the band determines the offer. Recruiters stop pricing candidates by what they ask for.
When to build one
Too early and you create bureaucracy nobody needs. Too late and you spend a year unwinding accumulated inconsistency.
Reasonable triggers:
- You have more than about 50 employees, or expect to within a year
- You have more than three people in any single job family
- Managers are asking how to promote someone
- You have discovered a pay inconsistency you cannot justify
- You are preparing for a funding round, an audit or a pay-transparency obligation
- Attrition exit interviews mention "no career path"
If you are under 30 people, a lightweight version — three or four levels, no formal families — is usually enough.
Designing the level framework
This is the core of the work. Get it right and everything else follows.
How many levels?
Fewer than you think. A common failure is building a twelve-level ladder for a hundred-person company, which produces levels that nobody can distinguish and promotions that mean nothing.
Rough guidance:
| Company size | Individual contributor levels | Manager levels |
|---|---|---|
| Under 50 | 3–4 | 1–2 |
| 50–200 | 4–6 | 2–3 |
| 200–1,000 | 5–7 | 3–5 |
A useful test: if you cannot write a clear, meaningful distinction between two adjacent levels in three sentences, you have one level too many.
The dual ladder
Every framework should have two tracks past a certain point: an individual contributor track and a management track, with equivalent levels and equivalent pay.
This matters more than almost anything else in the design. Without it, the only way to grow is to manage people, which produces two bad outcomes: excellent practitioners become reluctant managers, and teams get managers who did not want the job.
A typical structure:
| Level | IC track | Management track |
|---|---|---|
| L1 | Associate | — |
| L2 | Engineer | — |
| L3 | Senior Engineer | — |
| L4 | Staff Engineer | Engineering Manager |
| L5 | Principal Engineer | Senior Manager |
| L6 | Distinguished Engineer | Director |
Two rules that make the dual ladder credible:
- Equal pay bands at equal levels. If the management track pays more, the dual ladder is decoration.
- Movement between tracks is normal, not a demotion. A manager returning to an IC role at the same level should be an unremarkable event. Say this explicitly and mean it.
What distinguishes levels
Define levels using dimensions that apply across every job family. Four or five dimensions is enough. A workable set:
Scope — What is the size of the problem this person owns? A task, a feature, a system, a domain, a function, the company.
Autonomy — How much direction do they need? Told what to do and how; told what to do; given a goal; identifies the goal; sets the goals for others.
Complexity and ambiguity — Well-defined problems with known solutions; problems requiring judgement; problems where the right question is unclear; problems where the domain itself is being defined.
Impact — On their own work; on their team; across teams; on the function; on the company's results.
Influence and multiplication — Learns from others; delivers independently; raises the bar for a team; sets standards for a function; shapes how the organisation works.
Then write each level as a short paragraph per dimension. Resist the urge to write exhaustive checklists — long level definitions get read once and never used. Aim for one page per level, applicable across families.
Family-specific expectations
Under each generic level, add a short family-specific section: what does Level 4 look like in Sales versus in Engineering? Keep this to a handful of bullets each. The generic definition carries the scope; the family section makes it concrete.
The temptation is to write comprehensive competency matrices for every family at every level. A 100-person company that does this produces a 90-page document that nobody uses. Write the generic levels well, add half a page per family, and expand only where real confusion exists.
Mapping existing employees: the hardest part
Building the framework is the easy half. Placing 150 existing people into it, when many of them have titles that promise more than their level supports, is where the project succeeds or fails.
The process
Step 1 — Map without names first. Have managers describe the actual scope of each role — not the person — and place the role. Doing this at role level before you look at individuals reduces the pull of personal relationships.
Step 2 — Managers propose, calibrate, then decide. Each manager proposes a level for each of their people with a two-line justification. Then run a calibration session across managers within a function, and a second across functions. The cross-function calibration is what makes levels mean the same thing everywhere — skip it and you will have inflated levels in whichever function has the most persuasive leader.
Step 3 — Check the distribution. If sixty per cent of your engineers map to "Senior", either your framework is wrong or your titles have inflated. Both are common. A healthy distribution usually has a clear mass in the middle levels and thins at both ends.
Step 4 — Identify the mismatches. Three categories to handle deliberately:
| Situation | Approach |
|---|---|
| Level fits, pay is below band | Correct the pay, on a defined timeline |
| Level fits, pay is above band | Freeze increases until the band catches up; do not cut pay |
| Title implies a higher level than scope supports | Hardest case — see below |
Step 5 — Handle title downgrades carefully. The safest approach for most companies: grandfather existing titles, map the level correctly for compensation and career purposes, and apply the new title convention to new hires and future promotions. Taking a title away from someone who did nothing wrong is rarely worth the damage, and the level — not the title — is what drives the system.
Step 6 — Communicate individually before publishing anything. Every employee should hear their level from their manager in a conversation, before it appears in any system. No exceptions.
Calibration: the rules that make it work
- Managers present against the framework, not against the person's performance. Level is about scope; performance is a separate conversation.
- Require a specific example for any proposed level above the middle of the range.
- Anyone can challenge any placement. The framework, not seniority, settles it.
- Record the reasoning for every placement. You will need it next year.
- A facilitator who is not a manager in the group runs the session.
Connecting architecture to compensation
Levels without bands are half a system.
For each level, define:
- Band minimum, midpoint and maximum for fixed pay
- Variable pay target as a percentage, where applicable
- Equity range, where applicable
- Geographic differentials, if you operate across cost markets
Practical guidance:
- Band width of roughly 40–50% from minimum to maximum works for most levels. Narrower and everyone hits the ceiling; wider and the band stops meaning anything.
- Overlap between adjacent bands of 20–30% is healthy. It means a strong performer at L3 can out-earn a new L4, which is correct.
- Position in band should broadly track time and performance at level. Someone newly promoted sits low in band; a sustained strong performer moves toward the midpoint and above.
- Review bands annually against market data. Bands that do not move become fiction within two years.
A useful diagnostic: plot every employee as a dot, with level on one axis and pay on the other. Outliers are immediately visible. Run this before and after every pay review.
Promotion: making the system credible
The framework's credibility is decided by how the first promotion cycle runs.
Define the criteria. Promotion means the person is already operating at the next level consistently, not that they are ready to try. State this explicitly — "we promote to recognise scope already demonstrated" — because the alternative ("promote into the role") generates unfair comparisons and sets people up to fail.
Define the cadence. One or two promotion cycles a year, aligned to the performance cycle. Off-cycle promotions should be rare and require senior approval, or the cadence collapses.
Define the evidence. A short promotion case: examples of work at the next level, scope owned, impact, and peer input. One or two pages, not a portfolio.
Calibrate promotions across the company, the same way you calibrated the initial mapping. Different managers have systematically different standards; calibration is the only thing that corrects for it.
Publish the outcome principles, not the individual outcomes. Employees should know how many promotions happened, what the standard was, and how to prepare. They should not see each other's cases.
Give real feedback to people not promoted. "Not this cycle" without specifics is the single fastest way to destroy trust in a new framework. Every unsuccessful case should produce two or three concrete things to demonstrate before the next cycle.
Maintaining the architecture
A framework decays without maintenance. Four recurring activities:
Quarterly: New roles get levelled at requisition time, before the job is posted. Never let a role be hired without a level.
Semi-annually: Review new titles that have appeared. Title drift is the leading indicator of framework decay.
Annually: Refresh compensation bands against market data. Review the level distribution for inflation. Update family-specific expectations where confusion has surfaced.
On every organisation change: Re-level any role whose scope materially changed. A restructure that leaves levels untouched creates immediate inconsistency.
Assign a named owner. Without one, the framework is accurate on launch day and increasingly fictional thereafter.
Common mistakes
Too many levels. The most common error by a wide margin. Merge aggressively in version one; you can always split later.
Levels that describe the person, not the role. "Level 5 is someone with ten years' experience" is not a level definition. Tenure is not scope.
Building it in isolation and launching it as a surprise. Involve managers in the design. They will have to defend it.
Mapping people before the framework is agreed. The temptation to start with "where does Ravi fit?" is strong and always distorts the framework.
No dual ladder. Guarantees you will lose senior practitioners or gain reluctant managers.
Bands that nobody enforces. If offers routinely exceed the band, the band is wrong or the discipline is missing. Fix one or the other.
Skipping cross-function calibration. Levels then mean different things in different departments, and the whole cross-company comparison collapses.
Publishing everything at once. A phased release — levels and expectations first, bands later once you are confident — is usually safer than launching an incomplete compensation structure.
What to publish, and to whom
This is a genuine decision, not an obvious one.
| Element | Common practice |
|---|---|
| Level framework and definitions | Published to all employees |
| Family-specific expectations | Published to all employees |
| Each employee's own level | Told individually; visible to them |
| Others' levels | Usually not published |
| Band ranges for own level | Increasingly published |
| All band ranges | Varies; more common in transparent cultures |
| Individual salaries | Rarely published |
Publishing level definitions and expectations is close to universal among companies that build architecture at all — there is little point in a career framework nobody can read. Publishing bands is a cultural and, increasingly in some markets, a regulatory decision. Check whether pay-transparency obligations apply to you before deciding.
Whatever you choose, decide deliberately and tell people what the policy is. Ambiguity about what is public generates more anxiety than either extreme.
A rollout plan
Weeks 1–3 — Design. Draft the level framework with a small group: HR lead, two or three respected managers across functions, and a senior leader. Define families, levels, dimensions and level narratives.
Weeks 4–5 — Pressure-test. Take ten real, diverse employees and try to level them using the draft. Where the framework struggles, fix the framework. Do not adjust the person.
Weeks 6–7 — Manager enablement. Train all managers on the framework, the dimensions, and how to have a levelling conversation. Practise with anonymised cases.
Weeks 8–10 — Map and calibrate. Managers propose, function calibration, cross-function calibration, distribution check, mismatch handling.
Weeks 11–12 — Compensation alignment. Build bands, plot employees against them, identify below-band cases and agree a correction timeline and budget.
Weeks 13–14 — Communicate. Individual conversations first, then publish the framework, then hold an all-hands to explain how promotions will work.
Ongoing. Level every new requisition, run the maintenance cadence, and hold the first promotion cycle to the published standard.
Frequently asked questions
How many job levels should a 100-person company have? Typically four to six individual contributor levels and two to three management levels. If you cannot articulate the difference between two adjacent levels in three sentences, merge them.
What is the difference between a job level and a job title? The level is the internal measure of scope and complexity, and it drives pay bands and career expectations. The title is the external label. Keeping them separate lets you accommodate market title conventions without distorting your pay structure.
Should everyone know their level? Yes. A framework that employees cannot see does not produce the career clarity that justified building it. Whether everyone sees others' levels is a separate and more cultural decision.
How do we handle someone whose pay is above their band after mapping? Do not cut pay. Freeze increases, or grant increases below the general rate, until the band moves up to include them. Explain the situation honestly. Cutting pay to fit a new framework destroys trust in the framework itself.
Can someone move down a level? It should be possible in principle — after a restructure that reduces scope, or a voluntary move to a smaller role — but it should be rare and handled with great care, including the compensation implications. Most companies handle scope reduction by holding the level and adjusting expectations rather than by demoting.
How often should we review levels? Individual levels change through the promotion cycle, once or twice a year. The framework itself should be reviewed annually, and bands refreshed annually against market data.
Do we need different frameworks for different departments? No — one set of levels across the company is the point. Add family-specific expectations under each level, but keep the level definitions universal, or cross-company comparison and pay equity analysis become impossible.
How do we level a role we have never hired before? Assess it on the same dimensions: scope, autonomy, complexity, impact, influence. Compare it to existing roles you have already levelled. If it genuinely does not fit, that is a signal your framework may need a new family — not a new level.
What if a manager refuses to accept a calibrated level for their team member? Escalate to the framework, not to seniority. Ask for the specific evidence of scope at the higher level. If the evidence exists, the calibration was wrong; if it does not, the level stands. Recording the reasoning makes this conversation much shorter next year.
Should contractors be levelled? Generally not in the same framework, since levels connect to career progression and internal pay bands. But do map their scope for planning and cost comparison purposes, so you know what you are actually buying.
Bringing it together
Job architecture is one of the few HR investments where the return is obvious within a year: promotion arguments get shorter, pay reviews get faster, career conversations get more useful, and offers stop being negotiated from scratch every time.
The build is not complicated. Define families. Define four to six levels on a handful of universal dimensions. Add a dual ladder. Map people through calibration rather than manager discretion alone. Attach bands. Publish the framework. Run one honest promotion cycle. Assign an owner and maintain it.
The mistake is not building an imperfect framework — it is not building one, and letting the structure of your organisation be decided one negotiation at a time.
CozyHR holds levels, bands, role definitions, reporting structure and compensation history in one place, so the mapping you do once stays current as people join, move and get promoted. Try CozyHR and give your career framework somewhere to live other than a spreadsheet.
Appendix A: A sample level framework
Use this as a starting draft, not a finished product. Adapt the language to how your company actually talks about work.
Level 1 — Learning
Scope: Well-defined tasks within a larger piece of work. Autonomy: Works under close direction. Asks for help early and often, which is expected. Complexity: Problems with known solutions and clear success criteria. Impact: On their own output. Influence: Learns actively from the team.
Level 2 — Delivering
Scope: A complete component or workstream. Autonomy: Given the what; works out the how. Escalates when blocked. Complexity: Problems requiring judgement between known approaches. Impact: On the team's delivery. Influence: Reliable contributor; helps newer colleagues.
Level 3 — Owning
Scope: A system, territory, process or domain end to end. Autonomy: Given goals; determines approach and sequencing. Rarely needs direction. Complexity: Ambiguous problems where the approach is not obvious. Impact: Across their team, and visible to adjacent teams. Influence: Raises the team's standard. Trusted to review others' work.
Level 4 — Multiplying
Scope: Multiple systems or a significant area spanning teams. Autonomy: Identifies what should be done, not just how. Sets direction within their area. Complexity: Problems where the right question is unclear and trade-offs are contested. Impact: Across several teams or a function. Influence: Sets standards others follow. Makes the people around them better.
Level 5 — Shaping
Scope: A function, or a company-wide domain. Autonomy: Sets the agenda for their area in partnership with leadership. Complexity: Problems with no precedent inside the company. Impact: On company results. Influence: Shapes how the organisation works, beyond their own reporting line.
Level 6 — Directing
Scope: A major part of the company. Autonomy: Accountable for outcomes, with wide latitude on approach. Complexity: Strategic trade-offs across competing priorities and time horizons. Impact: On the company's trajectory. Influence: Builds the leaders who build the teams.
Six levels is more than most companies under 200 people need. Start with four (L1 to L4) and add above only when you genuinely have people operating there.
Appendix B: The levelling conversation script
Managers find this conversation harder than any performance discussion, because level feels more permanent than a rating. Give them a script.
Opening. "We've built a level framework so that career progression, pay and expectations are consistent across the company. I want to walk you through where your role sits and why."
Explain the system before the outcome. Show the framework. Explain that level describes the scope of the role, not how well someone is performing — a strong performer at L2 is doing excellent work at L2.
State the level and the reasoning. Be specific: "Your role maps to Level 3 because you own [domain] end to end, you set the approach without direction, and you're the person others come to on [area]."
Address the gap to the next level directly. "The main difference at Level 4 is impact beyond your own team. Concretely, that would look like [two or three examples]."
Handle the title question honestly. If their title implies something different, say so plainly: "Your title stays as it is. Titles and levels are separate here — the level is what drives your band and your progression."
Handle the pay question honestly. If pay is below band, say what will happen and when. If it is above band, say that too, with the consequence. Do not defer this to a later conversation; people will ask and vagueness reads as bad news.
Close with the path. "Here's what I'd like us to work on over the next two cycles, and here's how promotion decisions get made."
Two things to avoid absolutely: apologising for the level ("I fought for L4 but...") and blaming the framework ("this is just what HR decided"). Both destroy the manager's authority and the framework's credibility in one sentence.
Appendix C: Diagnosing a decaying framework
Run this check annually. Three or more yes answers means your framework needs attention.
- [ ] New titles have appeared in the last year that are not in the convention
- [ ] More than a quarter of employees sit above the midpoint of their band
- [ ] Offers regularly exceed the band for the level being hired
- [ ] Managers cannot state the level of everyone on their team from memory
- [ ] Level distribution has shifted upward without a change in the work
- [ ] Requisitions are being opened without a level assigned
- [ ] Promotion cases are approved outside the cycle more than occasionally
- [ ] Two people doing similar work in different departments sit at different levels
- [ ] Band ranges have not been refreshed against market data in over eighteen months
- [ ] Nobody is named as the owner of the framework
- [ ] Employees cannot find the level definitions without asking HR
- [ ] Exit interviews mention unclear career progression
Most of these are cheap to fix if caught within a year and expensive to fix after three. The single highest-leverage control is the first one on the maintenance list: never let a requisition open without a level attached. Almost all framework decay enters the organisation through hiring.