Purpose

This playbook takes you through the process of writing a role profile from scratch. It covers the difference between a role profile and a job description, the structure of a good role profile, how to write outcome-focused accountabilities, how to connect role profiles to your capability framework, and how to use them in hiring, performance conversations, and development.

A role profile is a clarity document. Its primary audience is the person doing the job - not the recruiter, not the candidate. When someone reads their role profile, they should be able to answer: what am I here to achieve, what decisions are mine to make, and what does good look like at this level?

When to Use This Playbook

• You are creating a new role and need to define it properly before hiring or making an internal appointment
• You have an existing role that has evolved and the current description no longer reflects reality
• You are preparing for a performance or development conversation and need a clear baseline
• You are hiring for a role and want to use a proper framework rather than a list of requirements
• You are building a career framework and need to define the levels for a role family
• You are onboarding someone new and want to give them clear expectations from day one

Before You Start

Be clear about what you are building and why:

• Are you defining a new role or documenting an existing one?
• Is this for a single hire or for a role family with multiple levels?
• Who else needs to be involved in defining this role? (The future incumbent's skip-level, a peer manager, HR, a technical lead)
• Does your organisation have a capability framework or SFIA alignment that this needs to connect to?

Gather information first:

If the role already exists:

• Talk to the current role holder. Ask: "What do you spend your time on? What decisions are yours? What would a successor need to be effective in this role?"
• Talk to stakeholders. Ask: "What do you need from this role? What is the biggest gap?"
• Review any existing documentation - job descriptions, performance objectives, level frameworks

If the role is new:

• Define the problem it is being created to solve
• Map the decisions it will own
• Identify the people and teams it will need to work with

The Difference Between a Role Profile and a Job Description

Most organisations have job descriptions. Far fewer have role profiles. The distinction matters.

A job description answers: "Who should apply for this?" A role profile answers: "What does success in this role look like?"

Both have their place. A role profile should be the primary document. A job description can be derived from it for external recruitment.

The Structure of a Good Role Profile

A role profile has six components. Each has a purpose. Do not add sections because they look comprehensive - each section must earn its place.

1. Purpose of the Role

One to three sentences. What does this role exist to achieve? Not what it does - what it is for.

Poor example: "The Senior Software Engineer is responsible for designing, developing, testing, and maintaining software systems. They work within an agile team to deliver features and improvements."

Good example: "The Senior Software Engineer exists to translate complex product and technical problems into well-designed, reliable software. They are expected to shape technical direction within their team and to raise the capability of the engineers around them - not just to deliver their own work."

The test: if you removed this role, what would be missing? The purpose should make that clear.

2. Key Accountabilities

Five to seven accountabilities maximum. These are the things this role owns. Not tasks - outcomes.

See the section on writing accountabilities below.

3. Decision Rights

What decisions does this role make independently? What decisions does it make with others? What decisions does it escalate?

This is the most commonly missing section and often the most valuable. When decision rights are unclear, people either over-escalate (slow, creates bottlenecks) or under-escalate (risky, creates surprises). Writing them down forces clarity.

Format:

4. Key Relationships

Who does this role work with, and in what capacity? This is not an org chart - it is a map of the working relationships that are essential to the role being effective.

Format:

5. Capability Expectations by Level

This section is what turns a single role profile into a career framework. It defines what "good" looks like at each level within the role family.

See the section on levelling below.

6. What Success Looks Like at 30, 90, and 180 Days

Optional but valuable for roles where the first few months are critical. Defines what concrete progress you expect to see and when.

How to Write Accountabilities That Are Outcome-Focused

This is the hardest part of writing a role profile and the part most commonly done poorly.

The difference between a task and an accountability

A task is something you do. An accountability is something you own the outcome of.

Task: "Attends sprint planning and backlog refinement ceremonies."

Accountability: "Ensures the team's engineering backlog is well-understood, appropriately sized, and ready to be worked at all times."

The task tells you what the person does. The accountability tells you what they are responsible for producing - and implies that if it is not happening, this is the person who owns fixing it.

The formula

A well-written accountability has three components:

1. The outcome or result being produced
2. The scope (what it covers and its boundaries)
3. The standard (what "done well" means, at least implicitly)

Example:

"Ensures the reliability and performance of [team name]'s production services, including defining and tracking service level objectives, leading the response to production incidents, and driving the post-incident learning process."

This tells you: what they produce (reliable, performing services), the scope (team's production services), and what the accountability involves in practice (SLOs, incident response, post-incident learning).

The accountability test

For each accountability, ask:

• "If this was not happening, who would I go to?" - the answer should be the role holder
• "Is this an outcome or a list of tasks?" - outcomes are preferable
• "Does it imply a standard?" - "maintains documentation" is weak; "ensures system documentation is accurate, accessible, and sufficient for a new team member to understand and contribute to any service within their first month" implies a standard
• "Is it within the role's genuine control?" - accountabilities for things outside someone's control are unfair

Common mistakes in writing accountabilities

Too many. If you have more than seven, you have a task list, not an accountability set. Consolidate.

Too vague. "Contributes to team performance." How? What outcome? What standard? This tells the role holder nothing.

Too prescriptive. "Attends daily standup, updates Jira, submits a weekly status report." This is process, not outcome. Write what you are trying to produce, not how you are currently producing it.

Covering everything to be safe. Role profiles are not meant to be comprehensive lists of everything someone might do. They are the set of things they are primarily accountable for.

Levelling: Capability Expectations Across a Role Family

A role family is a set of roles that share a common purpose but operate at different levels of scope, complexity, and independence. For example: Software Engineer, Senior Software Engineer, Staff Software Engineer.

For each level, define capability expectations across the dimensions that matter. Common dimensions in engineering roles:

Level differentiation - example for Software Engineer family

Connecting to SFIA

SFIA (Skills Framework for the Information Age) is a globally recognised framework defining skills and levels for IT and digital roles. If your organisation uses SFIA, your role profiles should reference the relevant SFIA skill codes and levels.

Example mapping for Software Engineer:

Using SFIA gives you an external anchor for your levels - useful for benchmarking, for apprenticeship standards, and for conversations with people who have joined from organisations that use a different internal framework.

How to Use Role Profiles in Hiring

A role profile is not a hiring checklist. Do not give a candidate a copy of the role profile and score them against it.

Use the role profile to:

Design your interview process:

The accountabilities define what the role needs to produce. Your interviews should test whether the candidate can produce those things. For each key accountability, design one or more questions or exercises that surface evidence of that capability.

Example:

Accountability: "Ensures the reliability and performance of production services, including leading incident response."

Interview approach: "Tell me about the most significant production incident you have led the response to. Walk me through what happened, what you did, what you delegated, and what you learned."

Have better hiring conversations:

Instead of: "Do you have experience with Kubernetes?" ask "We run a Kubernetes-based platform. Tell me about your experience operating production systems at scale and how you have approached reliability."

The role profile tells you what the role needs to achieve. Use it to probe for evidence of that, not for evidence of the tools list.

Calibrate the panel:

Share the role profile with your interview panel before interviewing. Ask each panellist to consider: "Given what this role exists to achieve, what do you need to understand about each candidate to be confident they can do it?"

Set expectations with the candidate:

If a candidate is offered the role, share the role profile with them. Not the job description they applied for - the role profile. It should be the first thing they read before they start, not six months in.

How to Use Role Profiles in Performance and Development Conversations

This is where the investment in writing role profiles pays off most clearly.

Performance conversations

The role profile gives you a shared reference point. Instead of "I think you are performing well" or "I think there are areas to work on" - you have something specific to point to.

"Let's look at the accountability for service reliability. In the last quarter, we had three incidents that were below our SLO. I want to understand what you think is behind that and what we should do about it."

Or:

"Looking at the decision rights section - you have been escalating a lot of technical decisions that the profile suggests you should be making independently. Is that because you are not comfortable with those calls, or is there something about the environment that is making you uncertain?"

The role profile does not make the performance conversation easy. But it makes it grounded in something objective.

Development conversations

The capability expectations by level give you a shared language for development discussions.

"Looking at the Senior Engineer level - you are already operating at that level on technical scope and autonomy. The area I think represents the biggest growth opportunity for you is the leadership dimension - specifically, how you develop and mentor the more junior engineers on the team. What does that look like for you in the next six months?"

This replaces vague conversations about "stepping up" or "being ready for the next level" with a specific, discussable set of dimensions.

Promotion conversations

"Let me share the Staff Engineer profile with you. I want us to look at it together and map where you are already operating at that level, where you are developing, and where there is still a gap. That will give us a clearer picture of when you are ready and what to focus on in the meantime."

How to Keep Role Profiles Current

Role profiles go stale. A profile that was accurate when it was written two years ago may now describe a role that no longer exists in quite that form.

Review triggers:

• Significant change in team structure
• Significant change in the technology or the product
• The organisation's strategic direction changes in a way that affects the role's scope
• You are about to hire for the role
• You are about to have a promotion conversation

Annual review:

Once a year, as part of the performance cycle, share the role profile with each team member and ask: "Is this still an accurate description of what this role exists to achieve? Is there anything that needs updating?"

This has the dual benefit of keeping the document current and reminding the team member what they are there to produce.

Worked Example Structure

Below is the skeleton of a role profile for a Senior Software Engineer, showing all sections with placeholder content. Use this as a template.

Role: Senior Software Engineer

Team: [Team Name]

Level: L2

Purpose of the Role

The Senior Software Engineer exists to [one to two sentences on what the role is for - outcomes, not activities]. They are expected to [what distinguishes this level from L1 and below].

Key Accountabilities

1. [Outcome this role is accountable for - written as what they produce, not what they do]
2. [Second accountability]
3. [Third accountability]
4. [Fourth accountability]
5. [Fifth accountability - maximum seven]

Decision Rights

Key Relationships

Capability Expectations at This Level

SFIA Alignment

Primary skills: [SFIA skill name (code)] at Level [n]

Success at 30 / 90 / 180 Days

30 days: [Concrete markers of a good start]

90 days: [Concrete markers of settling in and contributing]

180 days: [Concrete markers of full effectiveness]

What Good Looks Like

A role profile is good when:

• The person in the role reads it and says "yes, this is what I am here to do"
• A new hire can read it on day one and understand what they are accountable for
• A manager can use it in a performance conversation without the role holder feeling surprised
• A hiring panel can use it to design focused, evidence-based interviews
• The level definitions are consistent enough that two different managers applying them reach the same conclusion about the same person

Common Failures

Copying the job description. The job description was written to attract candidates. It is not a clarity document for the incumbent. Do not import its language or structure.

Writing tasks instead of accountabilities. If your accountabilities read like a process manual, rewrite them as outcomes.

Too many accountabilities. More than seven is a task list. If you cannot reduce to seven, you have not been decisive about what the role primarily exists to produce.

No level differentiation. A role profile without level expectations cannot be used for performance or development conversations. If you have multiple levels in a role family, define what distinguishes them.

Writing it and never updating it. An outdated role profile is actively harmful - it creates a gap between the written expectation and the actual one, which undermines trust and fairness.

Writing it without involving the right people. A role profile written by a manager without input from the role holder (or a predecessor, or key stakeholders) will miss what the role actually requires.

Using it as a weapon in a performance conversation. "You have not met this accountability" is not a conversation - it is a verdict. Role profiles are a starting point for discussion, not a prosecution case.

Checklist

Writing the Role Profile

• Purpose of the role written in one to three sentences - outcome-focused, not task-focused
• Key accountabilities written (five to seven maximum)
• Each accountability reviewed: is it an outcome or a task?
• Decision rights defined for each major decision area
• Key relationships mapped with nature of interaction described
• Capability expectations defined for this level (and adjacent levels if applicable)
• SFIA alignment included if organisation uses SFIA
• Role reviewed with at least one stakeholder (skip-level, tech lead, HR) before finalising

Using the Role Profile in Hiring

• Interview questions and exercises derived from accountabilities
• Panel briefed on the role profile before interviews
• Candidate offered the role profile at offer stage (not just the job description)

Using the Role Profile in Performance Conversations

• Role profile shared with team member at start of performance cycle
• Performance discussed with reference to accountabilities
• Development discussed with reference to level expectations
• Promotion conversations grounded in level differentiation

Keeping the Role Profile Current

• Annual review scheduled as part of performance cycle
• Review triggered by team restructure, technology change, or strategic shift
• Role holder involved in annual review
• Last reviewed date recorded on the document