Introducing SFIA: early considerations

These are the things that often come up once people move beyond the first question of “should we use SFIA? They are not a recipe or a fixed approach. In practice, organisations usually move backwards and forwards between them, depending on where the pressure is coming from and what they already have in place.

Starting from a question rather than the framework

SFIA tends to work best when it is brought in to help with a question the organisation already cares about. The question does not have to be grand. It is often something quite practical.

For example:

• people are saying they cannot see how to develop
• a restructure needs clarity about roles and skills
• career progression exists on paper, but managers cannot explain it clearly
• training money is being spent, but no one is quite sure whether it is meeting the right needs
• leaders know there are capability gaps, but cannot see where they are
• managers are grading similar roles differently
• hiring managers are applying different standards for what looks like the same role.

When there is a real question like this, SFIA has something to work on. It gives people a way to describe the issue more clearly.

Where organisations struggle, it is often because they start with “we should implement SFIA” rather than “we need to solve this problem”. The framework then has no obvious job to do, and people can start to see it as another HR exercise.

Designing for the long term

Skills work is sometimes treated like a project. There is a launch, some workshops, a set of profiles and then, a year later, people quietly realise no one has updated anything.

That is not a failure of SFIA. It is usually a sign that the organisation did not decide how the work would live after the project team moved on.

It helps to think early about simple things such as:

• where the SFIA information will be used
• who will keep it current
• what happens when roles change
• how managers will use it in normal conversations
• how it connects to existing HR, workforce planning or professional development processes.

These questions may not feel urgent at the start. But they often make the difference between SFIA becoming part of how the organisation works and SFIA becoming a set of documents that people vaguely remember producing.

Considering what needs to be in place

SFIA often makes visible things people already half-knew were there. A role that has always been a bit unclear. Two managers using different standards without realising it. A development need that keeps being mentioned, but never quite turns into a plan.

That visibility is useful, but it can also be uncomfortable. SFIA can help people name the gap, but it does not close the gap by itself. It can show that someone needs development, but it cannot create the time, support or work opportunities needed for that development to happen. It can point to inconsistent judgements, but it cannot make managers deal with them.

So it is worth looking at the people practices around the framework. In some organisations, these are more informal than people first admit. Managers may talk to people about work, but not about skills, development or progression. Training may happen because someone asks for a course, or because there is budget left. Career progression may depend on a few experienced managers knowing how things work, rather than on something employees can see and understand.

These are the kinds of questions SFIA brings into the room. What skills does this role actually need? What would show that someone is working at the next level? Who makes that judgement? What evidence do they use? Are managers applying similar standards? When a development need is identified, is there a practical way to address it?

An organisation does not need all of this to be mature before introducing SFIA. In many cases, SFIA helps build these practices because it gives people a shared language. But it helps to be honest about the starting point, rather than expecting the framework to carry things that belong to the organisation’s management, development and career processes.

Tailoring rather than adopting wholesale

Most organisations do not need all SFIA skills. They need the parts that are relevant to their work.

This sounds obvious, but it is a common early mistake to treat the framework as if more coverage means better use. In practice, a smaller, well-chosen set of skills is often more useful than a large set that no one feels directly connected to.

What counts as relevant will vary. A small digital team, a government department, a large technology function and a specialist cyber team will all make different choices. That is not a problem. It is part of how SFIA is meant to be used.

Where a tool fits

Many organisations ask about tools very early. Sometimes the first conversation is not “what are we trying to improve?” but “which tool should we buy?”

That is understandable. A tool can make the work feel more real. It can hold skills data, support self-assessment, help build profiles and connect with HR systems. At scale, a tool can be important.

But early on, a spreadsheet is often enough. It lets people test the thinking, argue about the choices and see what data they actually need. Those early arguments are useful. They expose the questions that a tool will otherwise just hide behind screens and workflows.

A dedicated tool tends to earn its place once the organisation knows what it is trying to do with SFIA. By then, the tool has a clear job.

If the tool comes too early, the project can become over focussed as a data gathering effort. It can quietly settle decisions before people have properly made them. The organisation can end up working around the tool, rather than using the tool to support the way it wants to work.

A tool can help with the work, but it cannot decide what the work is for. That still has to come from the organisation.

Using AI to support the work

Some organisations will naturally want to use AI tools to speed up the work. That is not unreasonable. AI can help with first-pass drafting, comparing role descriptions or suggesting possible SFIA skills to consider.

But it needs careful review by people who understand SFIA and understand the organisation. A plausible-looking answer is not the same as a good skills profile.

There is also a more basic point. A lot of the value in SFIA work comes from the conversation itself. People discuss what a role is really there to do. Managers compare expectations. Teams notice where their assumptions differ. That work can be slow, but the slowness is not always waste.

AI can help prepare material for those conversations. It should not remove the need for them.

The related guidance on choosing the right pace looks at this in more detail.

Identifying who will look after it

It usually helps to name someone or some people to look after the use of SFIA. Not necessarily a big management structure at the start, just someone who has enough reach to keep the work connected.

This should not sit only in HR or Learning & Development if the aim is to describe real work. HR will often have an important role, but the framework needs input from the people who understand the work, the teams, the roles and the capability pressures.

At the beginning, this responsibility can be fairly light. Later, if more teams start using SFIA, it may make sense to set up something more formal, such as a skills council or design group. But doing that too early can feel heavy. Governance is easier to justify once there is enough activity to govern.

Thinking about the resources and roles needed

The work is not usually difficult because the framework is hard to read. It is difficult because it asks people to make choices, compare views and agree what roles and skills mean in their own organisation.

Even a light-touch introduction needs some time from people who understand the work, not only from HR or a central project team. Managers, professional leads, workforce planners, learning and development colleagues and sometimes employee representatives may all need to be involved. The balance will vary, but the work usually needs both SFIA knowledge and knowledge of the organisation.

Some organisations can build this understanding themselves, especially if they start small and use the published guidance. Others find it useful to bring in an Accredited SFIA Consultant, at least at the start. A consultant should not make all the decisions for the organisation, but they can help avoid common mistakes, explain how SFIA is intended to be used and provide an external challenge when discussions get stuck.

The important thing is to be clear what help is needed. Some organisations need advice on approach and governance. Some need support with role and skills profiling. Some need help building internal confidence so they can carry the work forward themselves. The best external support leaves the organisation more capable, not dependent.

Assessments: what SFIA is, and is not

SFIA provides descriptions and a common language. It does not assess people by itself.

That distinction matters. People sometimes talk as if SFIA “gives” someone a level. It does not. A person, a manager, an assessor or a certification scheme makes an assessment, using SFIA as a reference.

Professional judgement is still needed. Evidence is still needed. Context is still needed.

Using SFIA mainly as a self-rating tool in an HR system tends to limit its value. It can quickly become a form-filling exercise: people pick levels, managers approve or challenge them and the wider usefulness of the framework is lost.

SFIA is usually more valuable when it becomes a shared language for decisions. That might include role design, recruitment, development planning, progression, workforce planning or professional recognition.

Keeping this in mind helps people use SFIA as a support for decisions, not as a substitute for judgement.

A note on 'implementation sequence'

Organisations naturally ask what to do first. Rather than follow a fixed sequence, it can be more helpful to think about what depends on what.  For example, it is hard to use SFIA well in hiring or progression if managers do not yet understand the levels of responsibility. It is hard to build reliable skills profiles if no one has agreed what the roles are meant to do. It is hard to maintain skills data if no one owns the process after the first version is created.

A rough pattern might be:

First, build a shared understanding of how SFIA works, , especially the levels of responsibility and how skills are described.

• then introduce the other parts of the framework as people need them, such as generic attributes, behavioural factors and the definitions of knowledge, skill and competency

Second, use SFIA in basic practices, such as skills-based role profiles, performance conversations and development planning

You will then be in a stronger position to use  SFIA for more significant decisions, such as hiring, progression, workforce planning, organisation design and job design.

Some organisations will not follow that order exactly. They may be pulled in by an urgent restructuring, a workforce planning need or a professional development initiative. That is normal.

The main point is not to treat implementation as a neat recipe. SFIA becomes useful when it is connected to real organisational questions, supported by practical habits and kept alive after the first burst of activity.