- 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 workThe framework has several features that we should consider separately.
7 levels of responsibility and 5 basic attributes
Works under close direction. Uses little discretion in attending to enquiries.
Is expected to seek guidance in unexpected situations.
- 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”).
- 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.
- 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.
ModularityBecause 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-reviewedOne of the key things that give SFIA its longevity and keeps it revitalised is this design principle (quoted from https://sfia-online.org/en/about-sfia): “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 quicklyThe 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 conversationsEveryone 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.
AssessmentLike Daniel Kahneman et al. say in their book Noise:
What problems does it solve?
Uncertainties regarding career path and developmentThere’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 & competenciesWhat 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 detailsWe 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.
- 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 skillEarlier, 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.