You must understand and evolve the job architecture, and not do compensation in isolation.
Job Architecture must be well understood to perform total rewards work.
Job architecture unifies org design, job design, talent management and compensation. We can no longer perform compensation work in isolation from these.
Traditionally, we get a job description and an org chart (who reports to whom) and we evaluate (grade) the job. Done. Then we benchmark a lot of jobs and build salary ranges with midpoints aligning to market median. Done. This gives us what we need for salary proposals and merit decisions (compa-ratios.)
Over the past 5 years, well before the pandemic, clients are asking for help developing a job architecture first, then evaluation, then ranges. This is the right approach, I am convinced.
So what’s the difference?
A job architecture considers not only the “correct” grade for each job, but:
- workforce segmentation, where different total rewards approaches are needed;
- the career pathways within and across segments for growth and development for any person;
- job titles
- adjacent subject matter domains a person can (or must) learn to reach the next level, as promotion is not only upward, nor even in the same function;
- the ideal number of levels at each band: senior leadership, managers, individual contributors, support, operations/ hourly, etc.; and
- general competency (behavioral) expectations by band
Close attention to the job architecture leads to a more insightful analysis of everything else: job evaluation, competency framework, total rewards and pay mix, range width, use (or non-use) of “degree and years of experience” as a factor, type of incentive (if any) and other reward decisions.
A client was hiring rapidly in startup mode, using a few titles to cover hundreds of people. At a certain point they asked for help to develop a job architecture as no one knew how promotions would work. We intentionally designed broad level criteria based on the job as well as expectations around multi-domain knowledge and learning, competencies and culture expectations. Job evaluation factors were a starting point, but toward higher levels, they were more heavily supplemented by culture and competency markers.
More mature or monolithic organizations (i.e. large and slow to change) can update their job architecture any time to promote learning and out-of-your-lane thinking and contribution. Fast growing or agile (empowered lower levels) organizations, or organizations seeking a leaner fixed people cost will benefit the most by designing and evolving more flexible roles (job designs) that assume learning and flexibility, and not simply note “other duties as assigned” as item #10 on the job description.
Benchmarking that only looks at job evaluation points or pay grade number will still be useful. But in faster changing environments and/or agile cultures, paying for “value” is key, not pay for performance. Performance ratings still miss measurement of much of the value a person brings, despite our 50-years of perfecting our forms, bell curves and calibration practices. Paying for value addresses performance, plus:
- competence and pace of development
- potential
- scarcity in the market, i.e. difficulty to replace
- ANY OTHER form of value to the organization–this can be a person’s clearance to work with the government or defense industry, it can be the person’s unofficial status as successor to a key leadership role, it can be the person’s value as having the culture DNA. As long as it is not wrongfully discriminatory, value can be many things.
More can be said about job architecture. I am just getting my mind around it now, as it keeps coming up in client conversations. What have you learned about job architecture? How do you define it?