I had a question I wanted to answer. Its simplicity actually led to deeper conversations on how we understand our organisation’s competencies.
The question: “who is the best fit for this project?”
There are many layers. Who has the right capability in the given technology for the project? Is a top tier expert required? Do they need to operate alone or as part of a team? Would a mid level developer be appropriate?
It also touched on how the individual themselves felt. What if they had no expertise in this technology, but really wanted experience in this space as part of their career development?
Our conversation naturally gravitated to new questions like what is our organisation’s core competence? What are our strengths? What are our strategic objectives for our core competencies? Where are our gaps? Where should we focus learning? Can we foster cross-pollination of skills in our teams?
I soon came to the understanding that I could not use our current skills matrix to make informed decisions. The current model required us to define what technologies people were proficient in. If we added a new technology, we had to go through and rate everyone’s competence. This lack of flexibility meant that it could not be used for other disciplines such as product or UX. Additionally, there was no concept of level of interest in a technology that a person held.
We set about creating a revised model. One that was simpler, easier to query and more maintainable than the original model that had got us to where we are today.
Most importantly, the mechanism had to align with our company values of transparency and evolution.
Here is what we wanted to get out of the improved mechanism.
It needed to:
- be always up to date
- be maintainable by individuals
- be accessible and easy to query by anyone
- accommodate any number of skills or capabilities in various fields
- capture a person’s level of interest in the field
Our company loves Notion. It has become the living operating manual of our organisation. It is the first place people go to look for information. It was a natural choice for us to define a “Notion first” strategy.
Additionally, we wanted our staff list to be the starting point to finding out everything about that person, including their capabilities.
The staff list is a simple database that contains things like the person’s name, contact information and dietary requirements.
We’ll come back to the staff list after we have defined our capability models.
Defining the capability model
We defined capabilities as a skill or ability in any number of techniques, programming languages, frameworks or other technologies. Originally our skills matrix was oriented towards developers, but we wanted to embrace designers, product people and all the unique skills our team has into the capabilities model.
The model is deceptively simple. In Notion, we created a database table that contained the person’s name, the name of the capability, the person’s proficiency level and their level of interest.
Technologies are invented frequently. We could not possibly assemble a complete list of people’s capabilities – it would never be finished. So we modelled capability as a “select list”.
If the capability you want to record is not there, you get to be the first to add it to the list. This allowed us to be consistent with what we call the given techniques or technologies. As technologies are known to re-brand themselves, it also allows us to maintain the list easily.
Our previous model did a great job of defining capability. We ranked proficiency in the following bands …
- No experience
- Basic working knowledge
- Supported a project
We added a description for each band to help people self assess their proficiency level. For example, In order to be considered a “Expert”, you would need to be able to assume the team lead role in that capability. “Experienced” would require that you have spent a year or more delivering a project focussed on the capability in question.
Our old model did not cater for how interested a person was in a particular field. At Cogent, we care about the projects our people work on and want to harness the natural interest that people have in certain technologies and techniques.
We want people to love their work.
So we introduced a column for a person’s level of interest in a capability. This allows us to see where an individual might have no knowledge in a technology, but really wants to get into that field.
The level of interest is designed to capture your feelings. Again we aimed for extreme simplicity: “No interest”, “Active” or “Evangelist”. You can probably guess the meanings from the labels.
For example, I can program C++, but I have no real interest in that space these days. With TypeScript, I’m pretty active and subscribe to mailing lists and keenly review new features. I’m totally in love with NextJS and cannot stop showing everyone who will listen – I’m an evangelist!
With interest levels, we can now tailor projects to what people love, not just what they are good at. We can also tailor lectures, training and brown bags based on knowing our strengths and where we need to level up.
Transparency is in our DNA at Cogent. With our capabilities in Notion, anyone can query the data. But what we really wanted to achieve was evolution.
In the staff list, we added a linked view to embed the staff member’s personal capability matrix to their own staff member record. Click on the staff member, get a list of capabilities.
This allows for the staff member to edit their own capabilities list.
Through our People Manager program, we can talk one on one with people to ensure that this list is kept up to date. We can tweak the capabilities list to the changing technology landscape and to the work that the person has focussed on. This ensures that the data is up to date and reliable.
With this data in place, it is now easy for us to match people’s expertise and interest in specific capabilities to a project’s requirements. This leads to a better team fit. It facilitates more conversations with our people and project owners.
Notion is great, but creating visualisations is not its strong point.
“What are our core competencies?” was one of the original questions we contemplated.
We exported our capabilities matrix to Google Sheets in order to produce some stacked bar charts. We were looking to produce columns for capability and experience levels.
Each row is filled with the name of the capability and the counts of experience levels.
With that in place, we can generate a stacked bar chart and instantly visualise where we’re placed with certain capabilities.
- Keep it simple. When modelling, it is easy to end up with lots of attributes that you want to record. Distilling the problem down to the simplest thing that can possibly work makes the system easier to understand. Being easier to understand assists in obtaining buy-in from your people.
- Always link additional Notion data tables back to a central point. We chose our staff list. This reduces the friction of searching for information and presents it right in front of everyone. They know the data exists!
I cannot wait until an official Notion API exists as there are gaps in what Notion can achieve. But once you have that information at hand and can visualise it, you can make meaningful strategic decisions.