How to Build a Job Architecture Framework: A Step-by-Step Guide for Mid-Market HR

Most mid-market organizations don't start building a job architecture framework from a blank slate. They start from a mess: hundreds of job titles that accumulated through years of reactive hiring, inconsistent leveling across teams, job descriptions saved in Word docs that nobody has touched since 2019, and managers who set their own implicit criteria for what "senior" means on their team.

That's the real challenge. Rationalizing accumulated title chaos is harder than building clean from scratch, because you're not just designing a system, you're also managing the gap between where your organization is now and where the framework says it should be.

This guide walks through the process in the order it actually needs to happen. Each step names the real decision points, including the political ones that most frameworks conveniently skip over.

‍

What Is a Job Architecture Framework?

A job architecture framework is a structured classification system that organizes all roles in an organization into job families, functions, and levels, with defined criteria for each level and consistent competencies mapped across tracks. It serves as the foundation for compensation, career pathing, skills assessment, and workforce planning.

When it's working, your job architecture framework becomes the single source of truth for role definitions, leveling decisions, and career progression criteria. When it isn't, you end up with exactly what you already have: promotion decisions that feel subjective, pay equity issues that are hard to defend, and employees who don't know what they need to do to advance.

‍

Step 1: Audit What You Have

Before you can build the framework, you need a clear picture of the raw material. Pull every active job title across the organization, including titles that exist in your HRIS versus titles people actually use day to day. They're often different.

A title audit typically surfaces a few consistent problems:

• Title proliferation: fifty variations of "Software Engineer" with no clear rationale for the differences
• Grade inflation: titles like "Senior" and "Principal" used inconsistently across departments, often tied to tenure or negotiation leverage rather than scope
• Missing levels: some functions have a clear IC track while others jump straight from entry-level to manager with nothing in between
• Ghost titles: roles in the HRIS that don't reflect how the work is actually organized today

Document what you find without judging it. The audit is diagnostic, not corrective. Your job at this stage is to understand the scope of the rationalization problem, not solve it yet.

Also flag the organizational hotspots: the departments or functions where leveling is most inconsistent or where you expect the most pushback. That intelligence shapes your buy-in strategy later.

‍

Step 2: Define Your Job Families and Functions

Job families group roles that require similar types of work and expertise. Functions organize those families into broader organizational domains. Getting this structure right is the foundation everything else rests on.

A typical mid-market organization has somewhere between eight and fifteen job families depending on industry: Engineering, Product, Design, Marketing, Sales, Customer Success, Operations, Finance, People, Legal. Your specific list depends on how your organization is structured and where meaningful distinctions in work type exist.

The decisions that matter at this stage:

• Where to split, where to combine. Do you have one Engineering family or separate ones for Software, Data, and Infrastructure? Do you split Sales from Account Management or treat them as one family with different sub-tracks? There's no universal right answer. The right answer is the one that reflects how roles actually differ in scope, skills, and career progression.
• How to handle small functions. A three-person Legal team and a two-person Finance function don't need elaborate family structures. Build a simple one-track framework for small teams rather than forcing them into a system that doesn't fit their scale.
• Whether to use sub-families. For large engineering or sales organizations, sub-families (Frontend, Backend, Platform; Account Executive, Strategic, SMB) provide the granularity that leveling decisions actually require.

Industry-specific frameworks are useful as a starting reference here. The specific job families common in professional services organizations are different from those in technology or financial services, and starting from an industry-calibrated baseline saves significant time compared to building from scratch.

‍

Step 3: Establish Your Job Leveling Framework

This is where the architecture gets its teeth. A job leveling framework defines the criteria that distinguish one level from the next: scope of work, autonomy, complexity, impact, and typically some combination of skills and experience.

Most mid-market organizations use five to seven levels. A common IC track structure looks like:

• Level 1 (Associate/Entry): Defined tasks, close supervision, learning the domain
• Level 2 (Intermediate): Independent execution on standard problems, light mentorship needed
• Level 3 (Senior): Leads own work end-to-end, handles ambiguous problems, informal leadership
• Level 4 (Staff/Lead): Cross-functional scope, driving decisions that affect multiple teams
• Level 5 (Principal/Distinguished): Organization-wide or external impact, defines direction, rare

A parallel management track runs alongside, typically starting at Team Lead or Manager and progressing through Director, Senior Director, VP, SVP, and C-suite, depending on your organizational depth.

Three decisions tend to cause the most friction:

What "scope" actually means. Scope is the most defensible leveling criterion because it's observable. Define it specifically: how many direct reports, what budget authority, what project complexity, what cross-functional reach. Vague definitions like "broader impact" invite argument. Specific ones don't.

Whether to separate IC and management tracks. In most professional functions, yes. Forcing strong individual contributors into management to advance is a retention problem. Build parallel tracks that allow progression without requiring a management role.

Where to draw the senior cutoff. Grade inflation often means a third to half of an organization is currently titled "Senior" when the framework would call them Level 2 or early Level 3. Acknowledge this before you build the framework so leadership is aligned on how you'll handle recalibration.

‍

Step 4: Build Your Job Leveling Matrix

A job leveling matrix translates your leveling criteria into a format that HR, managers, and employees can actually use. It's a structured grid: job families across one axis, levels across the other, with defined expectations at each intersection.

For each cell in the matrix, define:

• Scope: What is this role responsible for? What decisions do they own?
• Complexity: What types of problems do they solve? What ambiguity are they expected to handle independently?
• Autonomy: How much direction do they need? What requires escalation versus independent judgment?
• Leadership: Do they mentor others? Lead projects? Influence organizational direction?

Keep the language concrete and role-specific. Generic descriptors like "demonstrated expertise" aren't useful because they can't be evaluated consistently. "Independently scopes, designs, and delivers features that affect multiple product areas without requiring architecture review" is evaluable.

The matrix is also where you surface the inconsistencies from your title audit. When you try to slot existing roles into the framework, the mismatches become visible. Some roles will fit neatly. Others won't slot cleanly because the title, the actual work, and the comp are all misaligned. Document those mismatches separately as remediation work rather than trying to resolve them within the matrix-building phase.

‍

Step 5: Map Competencies to Levels

Competencies define the skills, behaviors, and knowledge required at each level. They sit inside the leveling matrix and give managers specific language for development conversations and promotion decisions.

Effective competency frameworks at the level of a job architecture generally operate at two layers:

• Core competencies: Behaviors expected of everyone in the organization regardless of function (communication, collaboration, ownership, judgment)
• Functional competencies: Skills specific to a job family or sub-family (data modeling for a Data Engineering family, pipeline management for Sales, financial modeling for Finance)

The goal is not a comprehensive skills inventory at this stage. That comes with skills intelligence. The goal here is enough competency definition that a manager has a concrete basis for a leveling conversation and an employee has a clear picture of what the next level actually requires.

For each competency, define it at each level on a progression scale. A communication competency for an IC track might progress from "communicates status and blockers clearly to immediate team" at Level 1 to "presents complex findings and recommendations to executive audiences, adapts message to context" at Level 4. The delta between levels should be meaningful enough that a manager can make a defensible distinction.

According to LinkedIn's 2023 Workplace Learning Report, 68% of employees say they would stay with their employer longer if offered more learning and development opportunities. Competency frameworks are one of the structural inputs that make "growth" feel concrete rather than aspirational.

‍

Step 6: Write Structured Role Descriptions

Families, tracks, levels, competencies: that's the scaffolding. But the role description is the artifact that managers, employees, and recruiters actually use. It's where the framework becomes tangible.

Most organizations already have role descriptions. The problem isn't their absence; it's their disconnection. They're standalone Word docs written by individual managers at the time of a req, with no consistent structure, no connection to leveling criteria, and no update cadence.

When role descriptions are connected to your architecture, each one inherits structure from the framework. A structured role description should include:

• Responsibilities scoped to the level. Not a generic list of duties, but responsibilities that reflect the scope, autonomy, and complexity defined in your leveling matrix.
• Required skills mapped to the competency framework. The competencies from Step 5 become the skills section — creating consistency across every description in the family.
• Qualifications that reflect the role, not the wishlist. Grounded in leveling criteria rather than whatever the hiring manager thinks sounds right.
• Career path connections. Where does this role lead? Linking descriptions to career pathing data turns a static hiring document into a retention tool.

The operational benefit is maintenance. When descriptions are standalone documents, they go stale the day they're written. When connected to the architecture, updating a competency definition flows through to every description that references it. You update the framework once rather than editing two hundred individual documents.

At scale, maintaining hundreds of structured descriptions manually isn't realistic. AI-assisted generation uses your framework's leveling criteria and competency definitions as inputs to produce consistent, architecture-aligned descriptions across the organization. The value isn't in replacing HR judgment. It's in ensuring every description reflects the same structural logic without requiring someone to manually write each one from scratch.

‍

Step 7: Get Organizational Buy-In

This is where most frameworks fail. The work of building the architecture is hard. Getting it adopted is harder.

The two failure modes are predictable:

The document that lives in SharePoint. The framework gets built, reviewed, approved, and filed. Managers continue to level intuitively. Employees don't know it exists. Nothing changes. This happens when the framework is treated as an HR deliverable rather than a talent operating decision.

The framework that never launches. The perfect is the enemy of the deployed. Trying to achieve complete coverage, perfect competency definitions, and 100% manager alignment before launching means the framework never sees daylight. Six months of design work, nothing to show employees.

Both failure modes share the same root cause: insufficient executive sponsorship at the start and insufficient manager enablement at the end.

Practical approaches that work:

• Get management team alignment on the business case before the design work starts. The argument is straightforward: inconsistent leveling creates pay equity risk, makes it impossible to give employees a defensible answer about promotion criteria, and creates legal exposure in states with pay transparency requirements. Executives understand those stakes.
• Pilot with two or three functions before rolling out org-wide. A pilot surfaces edge cases and implementation friction at smaller scale. It also builds internal proof points that the framework works before you're asking every manager to adopt it simultaneously.
• Train managers on the language before asking them to use it. Managers who haven't been trained on the framework will default to their own mental models. The training doesn't need to be long. It needs to give managers enough fluency to have a leveling conversation backed by the criteria, not just their gut.
• Be transparent with employees about the timeline. Employees know when the org is working on leveling. Trying to keep it quiet breeds more speculation than transparency. Share what you're building, when you expect to finish, and what it will mean for them.

Handle the edge cases directly rather than deferring them. The "but what about X" questions from managers will surface the same handful of scenarios: the long-tenured employee who doesn't meet the criteria for their current title, the high-performer who meets criteria for a level above their current comp band, the acquired team whose titles don't map cleanly to your taxonomy. Decide how you'll handle each category before the rollout, and document the decision. Inconsistency in exception handling will undermine the framework faster than any design flaw.

‍

Step 8: Make It a Living System

A job architecture framework is a living document, which is exactly why so many organizations end up with outdated ones. Without a maintenance process, the framework is accurate on launch day and increasingly wrong every day after.

The minimum viable maintenance process includes:

• A defined owner. One person or team is responsible for the framework's integrity. Not "HR" collectively. A named owner.
• A cadence for review. Annual at minimum. Semi-annual for fast-growing organizations or those in industries where role definitions change quickly (any organization scaling AI work into existing functions, for example, will need to revisit competency definitions continuously).
• A request process for exceptions and additions. New roles get added every time someone hires. Without a process for evaluating new titles against the framework, title proliferation creeps back in within eighteen months of launch.
• Integration with comp cycles. The framework only influences compensation if it's used as an input to comp decisions. Connect it explicitly to your annual comp review process, or it will drift into irrelevance.

The organizations that maintain accurate frameworks over time are the ones that treat job architecture as infrastructure, not a one-time project. Deloitte's research on skills-based organizations found that companies taking a skills-first approach are 57% more likely to be agile — and that agility depends heavily on role definitions that reflect how work is actually changing, not how it was structured three years ago.

‍

What "Done" Actually Looks Like

A fully deployed job architecture framework gives you several things you don't have today. Managers can answer the question "what do I need to do to get promoted?" with specific, consistent criteria that don't vary by team or manager relationship. HR can run a comp analysis against a structured framework rather than a collection of inconsistent titles. Promotion decisions are defensible to the employee and to legal. Hiring managers write job descriptions against a standard, not from scratch every time.

That's the foundation. What comes after it is where the leverage is: skills intelligence that maps your workforce's actual capabilities against the competencies your framework defines, and career pathing that lets employees see movement options across functions, not just upward in their current track.

Job architecture isn't the finish line. It's the starting point for knowing what skills your organization actually has, what skills it needs, and which employees are positioned to grow into which roles. Without the architecture, skills assessments produce data with no framework to interpret it. Career paths feel arbitrary because there's no structural basis for them. The framework makes everything that comes after it work.

‍

Frequently Asked Questions

How long does it take to build a job architecture framework?

For a mid-market organization of 300 to 1,000 employees, the design phase typically takes eight to twelve weeks with dedicated HR bandwidth. Rollout and manager training add another four to eight weeks. Organizations that start with industry-specific templates rather than building from scratch can cut design time by half or more.

How many job levels should a mid-market company have?

Most mid-market organizations use five to seven levels for individual contributor tracks and four to six levels for management tracks. Fewer than five levels tends to compress meaningful distinctions. More than seven tends to create leveling debates over marginal differences that aren't operationally significant.

What's the difference between a job leveling framework and a competency framework?

A job leveling framework defines the criteria that distinguish one level from the next: scope, autonomy, complexity, and impact. A competency framework defines the specific skills and behaviors required at each level. The leveling framework is the structural scaffold; the competency framework fills in the specific expectations. Both are required for the architecture to function.

How do you handle existing employees who don't fit the new framework?

The standard approach is to grandfather current employees at their existing level and title, then apply the new framework to all future promotion decisions and new hires. For employees whose current title is above where the framework would place them, document the variance rather than retroactively adjusting titles, and align their next promotion decision to the new criteria. Forcing immediate title corrections creates more disruption than the framework is worth in its first year.

When should we use a platform vs. spreadsheets to manage job architecture?

Spreadsheets work for the initial design phase and for very small organizations. Once the framework is deployed and being actively used for hiring, promotions, and career conversations, spreadsheets create version control problems, access issues, and maintenance debt. A purpose-built system maintains the framework as a living document, integrates with your HRIS, and connects job architecture directly to skills assessments and career paths rather than keeping them as separate documents.

If you want a faster starting point than a blank spreadsheet, Career Bird provides industry-specific job architecture frameworks out of the box, built by IO psychologists and HR leaders. The platform connects job architecture directly to skills intelligence and career pathing in one system, starting at $4 per seat per month. See how it works at careerbird.ai.

‍

‍

‍