What is job architecture, and why are companies redesigning it?

A job architecture is the structure underneath an organisation's roles: job families, job profiles, and the levels that connect them. It defines what a job is before anyone asks what skills that job needs. Most large enterprises already have one, often built with a firm like Mercer, Korn Ferry or WTW.

The reason so many are being reopened is that most job architectures were built to answer a compensation question. They exist to support grading, levelling and pay, and they answer how one role compares to another. They were not built to describe what work actually happens inside a role, which is the question that matters once you start planning around skills and AI exposure.

That difference shows up as granularity. A job architecture is only useful for skills work if it splits roles that are genuinely different. Two very different jobs sharing one title cannot be given distinct skill profiles, because there is nothing in the structure to distinguish them. The opposite failure is just as common: we have seen organisations with more job titles than employees, where the structure is so fragmented that nothing rolls up. The level worth getting right is the job, not the position. Define it at the granularity you actually want skill profiles for.

TechWolf is the data layer here, not the design consultancy. We do not build job architectures from scratch, and we do not touch levelling, grading or pay. Where you already have a structure, we ingest it and map skills, proficiencies and job descriptions on top, which is why we tend to work alongside the firms above rather than against them. Your architecture does not need to be perfect or current for that to work. It needs to exist, and it needs to be specific enough to carry the distinctions you care about.

Job architecture on its own is not a business outcome. It pays off when it is specific enough to power what comes next: internal mobility, skill gap analysis, strategic workforce planning.