Job Architecture – Three approaches to noodle on

In truth, there is an indefinite number of approaches and every job architecture engagement will be unique but since there are many different views on what job architecture is and how to develop it, I wanted to lay out the three broad approaches that I use for architecture engagements and how I decide on the best approach.

To clarify how I think about job architecture, I like to think of it as the organizational “spine” – once in place, it should be viewed as the single source of truth across the organization supporting with compensation, HR systems, organizational metrics/planning, career pathing/conversations, and almost everything else you can think of relating to people. Comprehensive job architecture, done well, is incredibly empowering to people leaders, saves time, and allows for meaningful discussions with executives on people strategy.

Particularly at a time when many organizations are reducing headcount, how can you reliably know who to keep and who to let go without a clear picture of the unique roles and levels required, along with confidence in how individuals align to the framework? Without this confidence there is the high likelihood of making inefficient decisions around workforce planning.

Here are the three “buckets” that I believe Job Architecture engagements fall into:

1) Start from scratch

I think of this as a “traditional” approach to job architecture where there is virtually no starting point. In truth, this is rare; there will usually be some common understanding, either from a survey that the company uses, or a previous job architecture that has become out of date, or multiple legacy architectures in an M&A scenario.

In this approach, the input comes predominantly from functional leads and legacy information/data. This is a time-consuming but insightful process of sitting with leaders and documenting the unique roles/families of jobs that they have, the roles they will need, and how they perceive the career progression and titling within each, in addition to reviewing existing job descriptions, leveling guides, and Excel files.

Practically speaking, this means creating an interview template where we systematically discuss each job, relatively detailed responsibilities, qualifications, titles, years of experience, etc. It may be possible to use existing job descriptions as a starting point for this endeavor however, as many of us know, job descriptions are rarely maintained in an up-to-date way so can easily be misleading.

Once this information is collected, we can begin cataloguing the job families and levels, identifying common roles across functions, and building a detailed job architecture repository with leveling definitions.

2) Use a survey

Some people might say that this isn’t truly job architecture but I think this still satisfies the definition. Most survey providers (that operate a whole job classification approach) will include their own version of job architecture in the form of a fairly comprehensive catalogue of roles and leveling definitions that a participant is required to match their jobs to.

This process of job matching to a survey provider, once superfluous families and levels have been scraped away, can leave a company with a fairly respectable start to job architecture. Crucially, this has to be done effectively. The process of job matching for a survey submission cycle is unlikely to undergo the same rigor as job matching if we know that it will drive the future architecture. If done well, the end result is a selection of relevant job families, job descriptions, and leveling definitions. That sounds pretty much like job architecture to me.

The challenges are that the job families will likely not be perfect – survey architecture may be more granular than the company requires, or not granular enough, and the family names likely won’t align to internal terminology. Survey definitions are deliberately broad and probably not that helpful internally. Survey leveling guides are designed to match roles to a survey, not for broad communication across a company. As such, the leveling guides may work within an HR function where they can be effectively interpreted but may not be viewed as robust enough by employees or managers when having career conversations and deciding on promotions. Finally, titling will likely still be an issue as survey providers rarely provide recommended titling across levels and families.

Nevertheless for a small growing company, in an industry with a common understanding of roles, this is certainly better than nothing, and a good starting point for HR to manage jobs and levels until they reach the critical mass, and have the resources, to develop something more bespoke. It just might not be something that is shared and understood more broadly across the organization.

3) A hybrid approach

Finally, and probably the most common approach for me, is to take a hybrid approach.

With a hybrid approach, we use job matches to a survey provider to leapfrog our way towards a more customized and relevant job architecture. The process begins by choosing a survey or surveys, matching the current roles and to-be-hired roles into that survey, and then scraping away the superfluous families, much like with Option 2.

From that point, we can then identify the appropriate leveling structure or structures. Assuming one consistent set of organizational grades is the goal (as it often is), we can use the matches to identify the appropriate number of grades and align families to that. Common junction points are; whether to use Director, Associate Director, and/or Senior Director; Whether to use VP, SVP, and/or EVP, how senior the IC track should progress e.g. distinguished and/or fellow levels of seniority. Many of these decisions we can take a stance on without the need to involve functional leaders as these tend to be organizational decisions.

We then need to “tidy up” the families and develop naming and titling conventions based on historical practices and industry norms – this is a bit trickier to get right without the input of leaders but we can usually come up with a starting point for leaders to react to. Having completed this process, we can create a draft job architecture file that includes all families, levels, and suggested titles based on job matching process, leadership direction, and historical roles/titles.

The next step is then to review the job architecture with the relevant functional leaders and document the feedback. Typically we are looking for feedback in three areas – The appropriateness of the families we have developed, the appropriateness and relevance of the levels within them (not everyone may want, for example, a Senior Director), and the titling.

This feedback will then fall into two categories – changes that we can make, and changes we need to discuss. If there are roles missing or preferences on granularity that the functional leader needs in order for the job architecture to be useful, these are changes we can make. If the leader doesn’t fundamentally agree with the number of levels, or wants to use a titling nomenclature that is inconsistent with the rest of the company, these are things that the project team needs to discuss at the end of the review process, come to a decision on, and likely circle back to let the individual know the final decision and rationale.

Finally, we need leveling guides. With this approach, the level definitions will begin with the survey definitions but the goal is to create something that a people leader can reasonably use to frame a career conversation with their direct reports. We want to retain a link to the language and levels of the survey provider, since that ensures a reliable link to market compensation data, but we also want the guides to be useful and reflect skills/values that are important to the company such as cross-departmental collaboration, living company values, being an ambassador for the product etc.

---

As always, there is a time and a place for each approach. When choosing the right approach, the questions I ask are:

• How big is the company, how many countries do they operate in, and what are the growth plans?
• Are they using an existing survey provider or providers and what is the feedback?
• Are they in an industry with a broadly common understanding of roles and levels?
• Has there been a recent merger or acquisition?
• What is the timeline and budget?
• Is there already some form of job architecture and leveling guide in place?

My advice to anyone going down the path of job architecture is to decide early on the approach you want to take and then stick to it – any approach can work, but no approach is perfect – it is not about creating a perfect process rather acknowledging the limitations and addressing those in the project approach and intended outcomes. The end result is only as useful as the organization perceives it to be, and even the most perfectly designed job architecture will quickly be forgotten if the leaders are intended to use it don’t feel that they have been included in the design process.

“Any approach can work, but no approach is perfect”

Once the architecture is developed, we shouldn’t underestimate the importance of governance to make sure that is being used and is kept up-to-date but I’ll table job architecture governance for another time…