I have just come across a monster word – “Zompetencies” – I found it in a great article by Stacia Garr at Bersin by Deloitte. It’s a reference to Zombie competencies …
where competencies seem to be collapsing under their own weight, dying a very slow death
Stacia was, of course, referring to competencies as a whole – but it got me thinking about organisations who have adopted SFIA and have found over time that SFIA is not having the planned business impact or that they are not being used as widely as expected.
This is a common problem with organisations adopting SFIA.
- And in reality it’s a common problem for organisations adopting any new talent management framework e.g. for career planning or leaning and development.
- One connection at a large consultancy quipped that initiatives of this type begin to “decay from the day of implementation and have a half-life of 12-18 months”
So in what ways can we prevent SFIA becoming zombified in your organisation?
Stacey suggests 4 key things which you can do to prevent this happening:
Design for Criticality
Design for Impact
Design for Simplicity
Design for Acceptance
Now this gives us a useful checklist to think about when mapping SFIA skills to roles profiles.
1. Criticality of SFIA skills
Stacia says …
Focus on what is essential to success – not [on] every competency necessary for doing a job.
My views …
When mapping SFIA skills to role and positions – avoid the shopping list approach.
- It’s all to easy (especially for less experienced SFIA users) to try to map every aspect of someone’s role and some individuals or line managers can be very insistent that, yes, we are involved in all of these activities.
- Lists of 18-20 SFIA skills are not uncommon (Architects seem particularly prone to this problem but they are by no means alone in that.)
So the guideline of 6-8 SFIA skills per role is a good place to start (less if you can**).
- Don’t think of this as a dogma or a theory – it’s a pragmatic focus to help effective implementation and adoption.
But don’t stop there – from that list of 6-8 you can still emphasise which are the critical SFIA skills.
- This may be done on the skills mapping (i.e. the criticality is applicable to everyone in the role) or
- you can encourage managers and/or individuals to identify critical skills when they are having conversations around hiring, performance or development so that these can be very focused on what will make a difference.
2. Impact of SFIA skills
Stacia says …
Focus on competencies that align to the organization’s business strategy and greatest areas of need.
If your organization is making a major transformation from one focused on execution to one focused on innovation, competencies should be a part of the bedrock of the change effort.
My views …
This is an excellent observation and one which I have used to good effect many times. I find it really demonstrates your understanding of the business by knowing and highlighting where the biggest impact will be found.
Also key here is recognising that they can be a time dimension to SFIA skills.
- So although we may have 6-8 per role – at any point in time the importance of SFIA skills can change.
- In this way individuals and line managers need to be reminded to prioritise SFIA skills based on the business priorities and team / personal objectives.
To give a SFIA related example:
- an IT organisation has mapped the following SFIA skills to their Project Manager roles: Project management, Stakeholder relationship management, Supplier relationship management and Systems development management.
- this IT organisation has a current year objective to become trusted business partners for their internal customers
- in this case conversations about Impact should focus on the Stakeholder relationship management skill as the primary area of focus for the current year
3. Simplicity of adoption
Stacia says …
Constantly ask yourself if the competencies are necessary or can be expressed more simply. Further, in an effort to reduce competencies, do not combine two competencies into one. “Visionary leadership and tactical execution” is not one competency.
My views …
Of course, SFIA is an off-the-shelf product so SFIA users are heavily reliant on the authors and editors of the SFIA framework delivering simplicity.
From www.sfia-online.org we can see the intent: SFIA is …
Developed by people experienced in the management of skills in IT, SFIA tells you what you need to know and leaves it at that. It is designed as a resource for people who understand IT and know what they are doing.
Overall the SFIA skill level descriptors hit the mark – my main criticism is that there are some very wordy ones and some very short ones – but in general they do hit the mark.
One design principle which can be owned by SFIA users during skills mapping is to avoid adding overlapping SFIA skills where one would do
- e.g. including both Consultancy and Technical Specialism as a SFIA skill for one role. While you may feel there is a rational argument to include both – but always ask yourself is this helping or hindering Simplicity?
- There are other examples of this as the list of SFIA skills does not strictly follow the MECE principle.
4. Acceptance of SFIA
Stacia says …
Avoid the trap of developing competencies in a vacuum. Competencies need to be broadly socialized and amended as they are developed, to ensure both broad understanding and agreement on their content.
My views …
One of the great strengths is that the SFIA skills are socialized and amended at an industry level.
- So what could have been “developed in a vacuum” is turned into a strength as the SFIA description are validated by a far greater audience than could have been achieved internally.
- now that we have published SFIA version 6 (in 2015) we can be confident that the SFIA skill descriptions have both stood the test of time and have been revised and maintained to keep pace with industry changes. This means any problem areas or gaps are resolved based on feedback from SFIA Users.
Certainly with the many organisations I work with the descriptors are in the vast majority understood and accepted.
I also have first hand experience in a number of organisations where SFIA’s neutrality and credibility as a “de facto” industry standard has actually helped prevent the “not invented here” objections.
- These objections commonly occur with homegrown frameworks which are devised centrally or in the case of mergers devised by the “other” partner. In these instances using SFIA greatly increases acceptability.
Other things you can do to increase Acceptance of SFIA
- have a programme of communication and education for stakeholders to explain what & why you are using SFIA and the benefits
- tailor communications for the different needs of your audience e.g. IT leaders, IT line managers, IT professionals, HR/L&D professionals
- have a FAQ or jargon buster if you need to explain how some of the SFIA language and structure fits to how you do things in your own organisation
- set up internal support groups or SFIA champions who can become local subject matter experts
Conclusion
- Be pro-active and build longevity into your SFIA adoption
- Think ahead and have a plan at the design stage to minimise the risk of Zompetencies
- Ask your SFIA Consultant what experience they have of doing this and how they can help increase the value of your investment in using SFIA
h/t Stacia Garcia at Bersin.com -Does your Organization have “Zompetencies?”
** Note the danger of trying to get to 1 SFIA skill per role. In the vast majority of cases that is going too far and is counter-productive. There have been numerous rumblings on the SFIA circuit of a high-profile tool vendor which tries to get every role down to only 1 SFIA skill. I can’t confirm or deny this – although I have heard it from more than one reliable source. The drive for this appears to make adoption of their tool easier rather than for any sense of delivering high performance or avoiding Zompetencies.
