Skills map for strategic growth
Getting data to make your team more resilient, motivated and helping you to choose the next role needed
The context
Back in 2017 the Engineering managers started repeating those questions “Do we need more people to deliver the projects for this year?” “Which profile do we need more?”
The three main reasons that made those questions appear were, a change of tech stack, the specialists role redefinition and new projects coming. I will give you more details.
T-shaped team
We used to have a really strict specialist definition (backend, frontend, designer, sys admin) , where every specialist was only allowed to modify their part of the code. An example: a task that needs to add business logic and then change a title color. The backend will do the backend and then pass the task to the frontend, but the backend will never change the color.
We believe that in a real cross-functional team, everybody will do their best to accomplish team objectives doing whatever it’s needed. That means that if a frontend can help a backend in a task or a Sys admin can modify some app code, the expertise name should not be restrictive. In the code review the expert could give an opinion but the task doesn’t get stuck. (I recommend to check out Jason Yip articles about T-Shaped teams and how to develop them. )
To reinforce this change of paradigm , from specialist to t-shape, we unified all job titles into Software Engineer.
With a T-shaped team we can adapt better to a variant demand and enhance new paths for people growth but certainly adds complexity to the skills definition of the team.
From PHP to NodeJS, embracing K8s
Around 2016 we started changing our web app backend from PHP to NodeJS and our infrastructure from On-premise Servers to Dockerized Cloud Servers.
We had a few experts in those technologies so we had to train our team, but instead of forcing them to learn we needed to know if people were interested or if we needed to find new people outside.
New projects
After a collective dismissal we had new projects in the mid-term, it seemed that we were in growth mode again, but we wanted to be sure about the real needs before adding more people into the team.
Which roles do we need? How many people? What are the role priorities?
The need
But to answer those questions we need to have a clear picture of the actual tech department.
The process
We brought the problem to our Organization Circle, a workgroup formed by volunteers from the tech department, and we decided that instead of a Key-Value (Name-Speciality) we used a Skills matrix to be able to have T-shaped skills.
Skills map definition
Because skill level is not binary anymore with T-shaped model, we defined 5 skill levels:
- Doesn’t apply to me
- Interested
- Started working
- Medium
- High
- Expert
To define the skills, the circle created a first proposal with some Technology & Speciality topics. Then we asked the whole department for modifications or appends to the list via form and permission to make the information and results public.
100% of engineers agreed to make the skills maps public and the final result was this list of topics:
Design / Markup / CSS/SCSS / JS/ PHP / Node.js / Laravel Framework / APIs / Legacy Environment / Noodle Environment / DevOp Cloud / Android / Behat / Selenium test framework / GIT / ScrumMaster / Coach
As you can see the topics were really custom and diverse, it gives you a first idea of what skills the department thinks are important.
Getting Data
To get the data the circles think about different systems, but because the result will not be related with salary increase or performance reviews and we wanted to make the process simple and fast, we decided that we will share a spreadsheet and every developer will fill their skills level.
We love this solution because it reinforces the trust of managers in the team and between engineers. Here you can see the result:
Analysing Data
Once we have all the data , the managers created aggregated data to get some stats. Here you can see and example with 4 topics:
We can see that we have few high/expert in NodeJS but a lot of people that started working on it or that wanted to learn it, and the same happens with K8s . If we wanted to reduce the bus factor we needed to design some training about those topics.
A part of this aggregated data , the managers used the personal information in one on ones to have conversations around tech growth paths and offering the training designed when needed.
About hiring, after reviewing the new projects needs and the possible progression of our team skills we decided to look just for one Fullstack with main expertise on NodeJS and a little bit of frontend.
Conclusion
Sometimes as a manager you have to make decisions about the future , and there will always be a part of subjectivity in the choice, and I believe that’s how it has to be, but as managers we need to get as much objective data as we can.
Skills maps help us to make the team more resilient, pointing into the right direction for strategic growth and defining training needs. One of the reasons why it works was because it was defined and completed with the collaboration of the whole department and not just the thoughts of the managers.
Again, alone we go faster but together we go further.
