Clarifying Software Development Skills at Polymorph

Recently, we discovered and started experimenting with a framework called SFIA: the Skills Framework for the Information Age. In this article, we look into:
  • The SFIA framework and how it works
  • Where it fits in at Polymorph
  • What problems it can and cannot solve

What is the SFIA framework, and why does it matter in software development?

According to their website, SFIA is a framework that defines the skills and competencies required by professionals who design, develop, implement, manage and protect the data and technology that power the digital world. As a software development company, this matters because people build software.  If we can get better at defining the skills and competencies of our people and then work with those definitions, it follows that we’ll have improved the working environment for everyone at the company. Upon discovering SFIA, there was some scepticism about how current such a framework could be. While investigating it in more depth, it became obvious that SFIA has been keeping up; it contains a relatively small set of skill definitions (about 120), but they are the relevant ones, and the definition of each skill is clear as well as broad in the sense that it describes a wide range of seniority levels. These definitions act as a set of building blocks that help us build the bigger pieces. These bigger pieces then help us build a world-class software development company.

How does SFIA work

The framework has several features that we should consider separately.
7 levels of responsibility and 5 basic attributes

"The generic attributes that characterise SFIA’s seven levels of responsibility and accountability provide the underlying structure of the SFIA Framework. They ensure that the definitions of professional skills are defined in a way that makes their different levels recognisably distinct and aligned to the levels of Responsibility."


The 5 basic attributes are Autonomy, Influence, Complexity, Business Skills, and Knowledge.  Each level of responsibility addresses each of these 5 basic attributes.  For example, Level 1 (characterised as “Follow”) describes the required Autonomy as follows: 

Works under close direction. Uses little discretion in attending to enquiries.

Is expected to seek guidance in unexpected situations.

It has similar descriptions for the other basic attributes. The net results are that:
  1. It’s possible to map a job description onto a level.  For example, the CEO job description probably matches level 7 (“Set strategy, inspire, mobilise”), while the job description for a senior software engineer likely matches level 4 (“Enable”).
  2. Each skill can be defined across a range of levels. For example, Programming / Software Development (Developing software components to deliver value to stakeholders) goes from graduate-level coding to setting organisational policies and standards.
  3. The progression inside each skill becomes clear.  Programming / Software Development at level 4 includes “[d]esigns, codes, verifies, tests, documents, amends and refactors complex programs/scripts and integration software services.” At level 5, this progresses to “[t]akes technical responsibility across all stages and iterations of software development.”

117 skill definitions

The skills are divided into categories and subcategories.  Each skill contains descriptions at multiple levels, as well as some context explaining how the skill is generally deployed in practice.  Here’s a screenshot of the contents page of the framework reference.  You can find all of this information at the SFIA website.
Each of these skill definitions has some helpful features. Let’s look at the example of PROG (Programming / Software Development).
First, and right at the top of the skill definition, is the headline description.  In this case, “Developing software components to deliver value to stakeholders.”  Its four-letter unique code (“PROG”) also makes it easy to refer to in spreadsheets and other documentation. Next are the guidance notes, containing the practical things you might see someone doing if they’re using this skill.  Taken together, the headline description and guidance notes are very helpful when you’re trying to find the appropriate SFIA skill definition for some part of the work that happens in your organisation. Next is the skill’s definition at each of the applicable levels.  The skill definitions don’t necessarily cover all 7 levels; for example, the skill of Strategic Planning is only defined at levels 5, 6 and 7.  This makes a lot of sense; strategy work always leans toward inspiring and mobilising people rather than following some set of instructions.
Because of the way SFIA is laid out (levels of responsibility, basic attributes, skill definitions at different levels of responsibility), it’s quite modular and indicates a clear process for using it.
Crowdsourced & peer-reviewed
One of the key things that give SFIA its longevity and keeps it revitalised is this design principle (quoted from  SFIA is driven by its end users – the content reflects what industry and business want, and it is not driven by any single stakeholder group. When reading the skill definitions, it becomes clear that this really does get followed.  I’m regularly gratified to discover how well SFIA describes skills. Practitioners appreciate (and are surprised by) this clarity and lack of obfuscation.

Where does it fit in at Polymorph

Job descriptions get everyone on the same page quickly
The golden thread that runs through the relationship between employee and employer is the job description, since it defines the work that needs to be done.  That being so, the content of the job description becomes relevant not only during recruitment, but also at performance assessment time, while discussing career development, and when considering a promotion. That’s why it’s necessary to ensure that job descriptions are clear and understood by everyone involved in all these processes. SFIA helps with this by giving us a shared and documented language to talk about the bits and pieces that go into a job description.  For example, mentioning “software configuration” as one of the key performance areas in a job description gives everyone interested, a phrase to use when searching the SFIA framework reference.
Career path description and development conversations
Everyone would like to have a way to look ahead, to see what their future career options are, and what they need to do to make progress in their desired field.  A lazy way to respond to such a request is: “You’re an intermediate software engineer now, so next up for you is senior software engineer.  To get there, you have to gain experience”. It’s not surprising that such an answer is unsatisfactory.  What is needed is more detail about what it means to be a senior software engineer.  “What will be required of me?  And how is that different to what is required now? With SFIA available as a resource, it becomes possible to list the skills and their levels, as the organisation requires, for each seniority level.
Like Daniel Kahneman et al. say in their book Noise:

"Thousands of research articles have been published on the practice of performance appraisals. Most researchers find that such appraisals are exceedingly noisy."

Daneil Kahneman et al.
Daneil Kahneman et al.

Noise (book)

We should all look for ways to reduce the noise.  One way to do so is to make sure that the language that describes a skill is concise, unambiguous, complete and correct (meaning, a close match to reality).   We could invent this ourselves in Polymorph’s usual iterative way, but the SFIA foundation has been at this for over 20 years now and has gained input from many companies in the process.   So, in a way, it’s a shortcut to clarity.   Of course, that’s not enough; more thinking must go into providing a suitable rating scale and training our managers to use it consistently.  This is not what SFIA is trying to achieve.

What problems does it solve?

Uncertainties regarding career path and development
There’s a lot of work to be done to describe all our jobs this way.  But once that’s done, the uncertainty is largely addressed. Since it’s all based on a public resource, everyone has access to the same set of information, which as we’ve said is clear, unambiguous and informed by decades of input and refinement cycles. This gives people a lot of input to work with when thinking about their career direction.
Gives a high-resolution look into skills & competencies
What it means to “be a good programmer” depends on the context: is this programmer at a university?  A software development company like Polymorph?  A financial institution?  A government agency? SFIA makes it much easier to get detailed about this, for a specific organization. What is more, SFIA provides a consistent style and approach. So, if we require a skill that SFIA does not define, we can define it ourselves.
Removes extraneous details
We tried to define the skills we needed before discovering SFIA.  It’s very easy to end up with unnecessary details that are more cumbersome than helpful.  For example, our software engineer skills framework might explicitly talk about Flutter, AWS, TypeScript, etc. Doing this is a bad idea and will make everything harder, including staying relevant.  Instead, we now have skill definitions like this one, which do not refer to any specific technology or other extraneous details.  This is a much more robust approach.
Programming/software development PROG level 4
  • Designs, codes, verifies, tests, documents, amends and refactors complex programs/scripts and integration software services.
  • Contributes to the selection of the software development methods, tools and techniques.
  • Applies agreed standards and tools to achieve well-engineered outcomes.
  • Participates in reviews of own work and leads reviews of colleagues’ work.

What problems doesn’t it solve?

It’s still hard (and subjective) to assess proficiency with a given skill
Earlier, I referred to Kahneman et al.‘s book “Noise”.  They discuss the fundamental reason why assessments are subjective: When we ask one human (let’s call them Alice) to assess the skill proficiency of another human (let’s call them Bob), we’re asking Alice to make a judgment call.  To define the term “judgement call”: we’re asking her to use her mind as a measuring instrument to tell us something about reality as she perceives it.  There are different possible sources of noise in this process.  To name a few:
  • Alice might be having a particularly bad (or good!) day, systematically throwing off her judgement in one direction or the other.
  • Bob, simply by being himself, might trigger some internal bias that Alice holds – of which she might not even be aware.
  • Alice might have some other bias that’s throwing her off systematically; maybe she anticipates the impact of her assessment on Bob’s teammates, or the culture of the organisation she works in sets her up with some expectation of how the assessment process is supposed to go.
Assessing competence is difficult and subjective because of a fundamental aspect of doing assessments.  SFIA cannot change that.

Why bother with SFIA?

If you’re setting out to build great software, it’s best to start with the people: the people who build the software, the people they build it for and the people who’ll end up using the software. So, in short, we’re pursuing this because people build software. For more information, consult the SFIA website at, as it’s the primary source of information for the SFIA Framework.

Planning to build an app? 

Try our free software development calculator to maximise your ROI.

Request for Access to Information

The following forms are available to download with regards to request for access to information: