Role Architecture: How to Design a Position from Your Operating Model

By: Nhi Hong

Most job descriptions are written backwards.

They start with the person (the qualifications, the experience, the skills) and work toward the role. The result is a document that describes a candidate profile, not an operational position.

Then the hire is made. And three months later, the founder is frustrated because the person isn't doing what the business needs, even though they looked right on paper, interviewed well, and came with strong references.

The problem wasn't the hire. It was the design logic.

A role designed from a candidate profile tells you what kind of person to look for. A role designed from your operating model tells you what the business needs that position to do including which decisions it owns, which processes it drives, which outputs it's accountable for and then derives the person's profile from that.

The sequence matters more than most founders realize. And getting it wrong is expensive.

1) The Standard Approach and Why It Fails

The conventional approach to role design in an SME context looks something like this:

The business hits a pressure point, such as a function is overloaded, a capability is missing, the founder is spending time on work that shouldn't require their involvement. The response is to hire.

The job description is assembled from a combination of: what the founder has been doing that they want to hand off, what a similar role looks like at a previous employer or competitor, and what an acceptable candidate profile looks like in the local market.

The result is a role that is defined by inputs (experience, qualifications, functional knowledge) rather than outputs. What the person has done before, not what the business needs them to produce.

This creates three predictable failure modes:

Failure Mode 1: Role-Process Mismatch. The hire is competent, but the processes they're expected to own don't exist or aren't documented. They default to improvisation, which produces the same founder dependency the hire was supposed to solve.

Failure Mode 2: Authority Vacuum. The role has responsibilities but no decision rights. The person knows what they're accountable for, but not what they're empowered to decide independently. They escalate constantly, not because they're incapable, but because the authority structure was never defined.

Failure Mode 3: Competency-Output Disconnect. The competency requirements on the job description are generic functional skills, "strong communication," "analytical mindset," "leadership experience", rather than the specific operational capabilities the role requires. The hire meets the listed criteria and still can't do what the business needs.

All three failures have the same root cause: the role was designed from the person inward, not from the operating model outward.

2) The Operating Model: Role Design Logic

Designing a role from your operating model starts with a different first question.

Not: "What kind of person do we need?"

But: "What does the operating model require this position to own, decide, and produce?"

That question has four parts and each one must be answered before you write a single line of a job description.

Step 1: Identify the Process Ownership

Every role in a system-led organization owns at least one critical process. The first design question is: which processes will this position be responsible for driving, not just participating in, but owning end-to-end?

Process ownership means the role is accountable for the process producing the right output, consistently, to the defined standard. Not just executing steps, owning the outcome.

At this stage, you're not thinking about the person. You're mapping the operational territory the role covers.

For each process the role owns, document:

• What triggers the process

• What the expected output is

• What the measurable standard for that output looks like

• What happens downstream if the output fails

This is the operational foundation of the role. Everything else, the competency requirements, the seniority level, the reporting line is derived from this.

Step 2: Define the Decision Rights

Once process ownership is mapped, the second question is: what decisions does this role need to make independently for the processes to run without constant escalation?

This is where most role designs fall short. Responsibility is assigned. Authority is not.

Decision rights for a role should specify:

• Which classes of decisions the role owns completely, no approval required

• Which decisions require consultation but not sign-off

• Which decisions require escalation and to whom, under what conditions

• At what financial, operational, or strategic threshold the authority level changes

A role with clear process ownership but undefined decision rights will produce constant escalation. The person knows what they're responsible for. They don't know what they're allowed to decide. The rational response is to ask, every time.

Step 3: Specify the Output Standards

The third question: what does good performance in this role actually look like, in measurable, verifiable terms?

Not "manages the finance function effectively." Not "leads the team with strong communication." Specific outputs with defined standards.

For each major process the role owns, there should be a defined output standard: what does the deliverable look like when it's done correctly? What is the frequency? What is the quality threshold?

This is the basis for performance management and it needs to exist before the hire, not be invented six months into the role when something goes wrong.

Output standards also drive the competency requirements. If the role's primary output is a monthly financial report that requires synthesis of data from three systems and a narrative for the board, the competency requirements flow directly from that: specific technical skills, specific analytical capabilities, specific communication standard. Not generic "financial acumen."

Step 4: Derive the Competency Requirements

Only at this point, after process ownership, decision rights, and output standards are defined ,do you derive the competency requirements for the role.

This is the inversion that makes role design functional rather than cosmetic.

Competency requirements built from operating model logic look different from competency requirements built from convention. They're specific to what the role actually needs to produce. They're testable in an interview or assessment. And they connect directly to what success looks like in the position, not to a generic profile of a capable professional.

A competency framework built this way functions as operational structure, not an HR checklist. It answers: given what this role needs to own, decide, and produce what must someone be able to do to perform it?

3) The Role Design Canvas

The Role Design Canvas is a single-page template that captures the output of the four-step logic above, before a job description is written, before a recruiter is briefed, before an interview process is designed.

It has six sections:

Section 1: Operating Model Context Where does this role sit in the execution architecture? Which function does it anchor? What breaks in the operating model if this role is vacant or underperforming?

One paragraph. Forces the designer to articulate why the role exists in operational terms, not in org chart terms.

Section 2: Process Ownership List the 3–5 critical processes this role owns end-to-end. For each: trigger, key steps summary, expected output, downstream dependency.

This is the operational core of the role. If you can't complete this section, the role isn't ready to be hired for.

Section 3: Decision Rights Three columns: Decide independently / Consult then decide / Escalate. Populated with the specific decisions relevant to this role's process ownership.

Section 4: Output Standards For each major process owned: what does correct completion look like? Frequency, format, quality threshold, recipient. Specific and verifiable.

Section 5: Competency Requirements Derived from Sections 2–4. For each competency: what specific capability is required, and what is the observable evidence of that capability at the required level?

Structured as: Competency -> Why it's required (link to process/output) -> How it will be assessed.

Not a list of adjectives. A functional specification.

Section 6: Integration Requirements How does this role connect to adjacent roles? What does it receive from upstream? What does it hand off downstream? What governance touchpoints does it participate in?

This section prevents the most common post-hire failure: a well-designed role that doesn't connect properly to the rest of the operating model.

4) Competency Framework as Operational Structure

The standard competency framework in most SME HR practice is a list of desirable traits, consisting of leadership, communication, analytical thinking, initiative scored on a 1–5 scale and reviewed annually.

This is better than nothing. But it's not an operational structure.

A competency framework functions as an operational structure when it answers a specific question for each competency: why does this capability matter for this role's process ownership and output delivery?

The difference in practice:

Conventional competency entry: Communication - Able to communicate clearly and effectively with internal and external stakeholders. Demonstrates strong written and verbal communication skills.

Operationally grounded competency entry: Structured Reporting - Able to synthesize operational data from multiple sources into a board-ready monthly report that meets the defined format and accuracy standard. Required because this role owns the monthly performance reporting process, and the output is a primary governance input at the senior leadership review. Assessed by: sample report exercise during interview process; review of output against standard within 60 days of hire.

The second version is more work to write. It's also actually useful, for selection, for onboarding, for performance management, and for identifying development gaps when performance falls short.

The test for any competency entry: could you use this to design a specific interview question or assessment that would tell you whether a candidate meets the standard?

If not, the competency is decorative. Rewrite it until it is.

5) When to Use This Framework

Role Architecture applies at three distinct moments in the organizational lifecycle:

Before a new hire: The most obvious application. Run the four-step logic before briefing a recruiter or writing a job description. The Role Design Canvas becomes the brief, not just for recruitment, but for onboarding, performance management, and the 90-day review.

When a current role isn't performing: Before concluding that a person is underperforming, audit the role design. In many cases, the process ownership was never clearly defined, the decision rights were never made explicit, and the output standards were never documented. The person is failing against a standard that was never communicated. That's a role design problem, not a performance problem.

When the organization restructures: At every significant scale point, roughly 20, 50, and 100 headcount, the operating model changes enough that role designs need to be rebuilt from the architecture up. Roles that worked at 20 people often carry structural assumptions that don't function at 50. The Role Design Canvas is the tool for rebuilding, not just patching.

6) The Underlying Principle

A role is not a person. It's a structural position in the operating model, a node that owns processes, holds decision rights, and produces outputs that the rest of the system depends on.

Designing it from the person inward produces a hire. Designing it from the operating model outward produces a functional position that the right hire can step into and perform.

The former feels faster. The latter is faster because it eliminates the six-month cycle of unclear expectations, misaligned authority, and performance conversations that should never have been necessary.

7) What This Connects To

In People-Led vs System-Led: The Core Distinction, we established that system-led execution requires process clarity, role clarity, and governance rhythm. Role Architecture is the operational discipline that builds the role clarity component, not as an org chart exercise, but as a structural design decision derived from the processes the organization needs to run.

In Org Design for FDI SMEs: The Three Inflection Points, we'll look at governance design, how to build the review and accountability rhythms that keep a system-led operating model calibrated over time.

→ Download the Role Design Canvas

A one-page template structured around the four-step Operating Model => Role Design logic. Covers process ownership, decision rights, output standards, and competency requirements, in a format designed to be completed before recruitment begins, not after the hire goes wrong.

→ Download the Role Design Canvas 

OPS FOR SCALE by SOSP Consulting Group

Operational architecture for foreign founders building businesses in Vietnam. 

← Previous: Operating Model Localization 

Next: Governance Design →