A job architecture for an agile organisation: how do you pay roles that keep changing?

You work in squads, roles rotate every quarter and nobody has a three-page job description anymore. Then someone asks: what salary band is a Product Owner in, really? Or: why does that Scrum Master earn more than an engineer in the same squad?

Many agile organisations have no solid answer. The classic job architecture feels like the opposite of agile: fixed, hierarchical, a snapshot of work that has already changed. So it gets postponed, and roles get paid ad hoc.

That backfires now. The EU pay transparency directive requires pay to rest on objective, gender-neutral criteria, and you must be able to explain why one job is paid differently from another. Ad-hoc grading of fluid roles is exactly what does not hold up. The good news: a job architecture and agile working are not mutually exclusive. You just have to evaluate at the right level.

Why a classic job architecture clashes with agile working

A traditional job architecture is built on narrowly described jobs with a fixed task list. In an agile organisation that assumption no longer holds:

• People move between squads and pick up different responsibilities each sprint.
• Roles like Product Owner, Scrum Master or Chapter Lead are sometimes temporary, sometimes structural.
• You tend to value skills and impact rather than a ticked-off list of tasks.

Build a job architecture on job titles and tasks, and it is outdated before the ink dries. The flaw is not the job architecture itself, but what you base it on.

The mistake: a role is not a job

This is the heart of it. In agile organisations two things get blurred that you need to pull apart:

• A job is a durable level of work: the mix of knowledge, responsibility and impact you pay for. It does not change every sprint.
• A role is a responsibility you carry temporarily within a squad. Product Owner, Scrum Master, tech lead: these can be roles that move with the team.

You pay the job, not the role. The role is a layer on top. Someone who is Scrum Master this sprint does not move to a different salary band from the sprint where they are not. Make that distinction and most of the problem disappears: you do not grade a hundred fluid roles, but a handful of stable job levels.

What the pay transparency directive also asks of agile organisations

Being agile does not exempt you from the obligations. If anything, fluid roles make them more urgent:

• Article 4: pay on objective, gender-neutral criteria, weighed on four factors (skills and knowledge, effort, responsibility, working conditions).
• Article 7: an employee may ask what colleagues doing work of equal value earn on average. You must be able to explain the difference.

With fluid roles, arbitrariness creeps in easily: one Product Owner was graded higher than another long ago and nobody remembers why. That is exactly the gap a complaint slips through. A job architecture that weighs levels instead of titles closes it.

How to build a job architecture that handles agile

1. Use broader job families, not titles

Not a separate job per team name, but families with levels: Engineering I to IV, Product I to III, Delivery I to III. A squad engineer sits in an engineering level, regardless of which squad they are in this month.

2. Value impact and skills, not a task list

Weigh a job on its level of responsibility and the skills required, not on this quarter's tasks. Then the grading survives a role change. This is also how skills-based working and the directive meet: skills may lead, as long as the criteria are objective and traceable.

3. Treat agile roles as a layer, not a separate band

Two clean options:

• Is a role structural (someone is a full-time, lasting Product Owner)? Then it is a real job in its own family, which you simply weigh.
• Is a role temporary (the Scrum Master rotates)? Then at most attach a role allowance, not a new salary band. That keeps the ladder consistent.

4. Keep the ladder logical

A Scrum Master is not automatically above the engineers in their squad. Facilitating is not the same as managing hierarchically. Weigh on the four factors and let the outcome decide the place, not the org chart or sentiment.

Example: three agile roles graded

• Squad engineer sits in Engineering II or III, depending on autonomy and complexity. The squad they work in changes nothing.
• Product Owner with a mandate over roadmap and budget is usually a job in its own right (Product II or III): structural responsibility, so you weigh it as a job.
• Scrum Master who rotates within the team stays in their own job (say Engineering III) and may get a temporary role allowance. If it becomes a fixed, full-time role, you weigh it as a job after all.

The thread: first decide whether something is a job or a role. After that, grading becomes simple and explainable.

In a day, without a consultant

A job architecture based on levels instead of titles is actually faster to build, because you have fewer building blocks. You import your job families, check the weighting on the four legal factors and review whether the ladder holds. At the end there is a pay rationale: the method, the weighted scores and the sources, the evidence with which you answer every "why does he earn more".

See an example pay rationale (PDF), no login or credit card.

Frequently asked questions

Do we have to grade every role separately?
No. You pay the job level, not the temporary role. A handful of stable job families covers an organisation full of fluid roles.

Is a Scrum Master a job or a role?
It depends on whether it is structural. If it rotates within the team, it is a role with at most an allowance. If someone is a full-time, lasting Scrum Master, it is a job you weigh like any other.

Does skills-based pay fit within pay transparency law?
Yes, as long as the skill criteria are objective and gender-neutral and you can substantiate the weighting. Skills may lead; arbitrariness may not.

We reorganise our squads often. Won't the job architecture be outdated immediately?
Not if you weigh levels instead of titles. A role change then does not affect the grading. You only update when a genuinely new job level appears.

Want to dig into what the law requires? aycabtu builds EU pay-transparency job architecture for SMEs. Start free with one job.

Written via aycabtu.com, EU pay transparency for SMEs.