Team Competency Matrix for Product Owner’s maternity leave

I was the Product Owner (PO) of a multidisciplinary squad of 11 people when I got pregnant in 2019. Concerned with the fact that we did not have a PO that could replace me during my maternity leave, I decided to list the skills needed for the job and to identify them within our team to distribute my responsibilities among them.

Okay, I know that Scrum states that in the prolonged absence of the PO, another PO should be named, but it is not always possible to play by the book given adverse circumstances.

After listing the skills, without worrying about methodologies, another concern came up: If I intend to distribute my assignments considering even the developers, what could I do to not considerably compromise the deliverables? The development team will naturally reduce capacity in the sprints, but how could this situation be mitigated?

So, I decided to map the necessary hard skills for our development team (which works with 3 technological profiles) and included the QA part (we have a QA analyst within the squad). The idea behind this action was:

1. To let the squad know each one’s hard skills so we could identify who was able to teach and who was willing to learn;

2. To identify how to fill technical needs within a sprint caused by the partial allocation of a developer to the role of PO. An example of this would be allocating a Java developer to a Front-end activity because the Front-end developer is partially committed to the role of PO.

After mapping the development team’s hard skills and the skills of a PO, the next step was to set up the Team Competency Matrix. I decided to make it on paper, instead of having it in an electronic form, intending to display it on the existing wall where we keep our daily meetings. That would make sure everyone would look at it daily, which would help in memorizing the team’s skills facilitating access to information when needed.

The caption used was the one suggested on the Management 3.0 website:

Expert, Practitioner and Novice

I printed a sheet with the skills vs. people matrix, asked the team designer to write the title on it, and voilà: we had a proper Team Competency Matrix! I called a meeting with everyone and explained to them how they should fill the matrix without mentioning that my goal was to find people to replace me, either totally or partially, during my maternity leave. I did that to avoid such thoughts as “I don’t want to be the PO so I will not let them know I am an expert in business analysis.”

I handed them round sticky labels in the colors green, yellow and red and gave everyone, including myself, 15 minutes to stick the labels on the matrix accordingly.

The team consisted of:

1. Product Owner;
2. Scrum Master;
3. Tech Lead;
4. QA Analyst;
5. High platform (mainframe) developers;
6. Low platform (API’s and integrations) Back-End developers;
7. Front-End Developers.

Below is the mapping carried out with the whole team:

Outcomes

1. We discovered hard skills among developers;
2. We identified an opportunity to train a developer to act as a QA Analyst;
3. I envisioned people who could absorb my activities.

This matrix, along with the Moving Motivators’ outcomes, allowed me to see a healthy scenario for the team during my absence.

The next step was to enlist my activities and group them by skill. After that, I held several conversations with people who had each skill to choose the person responsible for each task, so that I could teach them to work on the methodology we were using in time for my leave.

The choice of people, as well as the assignment of tasks, was not imposed. Everything was done in consensus with each person in charge and with the team.

Here are some examples:

During my maternity leave the squad did not have a PO for a while and the activities were absorbed according to the mapped distribution.

Lessons Learned

People tend to overestimate their own skill levels and this sittuation happened during the dynamic, where they put PRACTIONERS’ levels but they were actually NOVICES. We had a situation, for example, of a person who was not a developer qualifying as a Java PRACTICIONER. In this case and in similar cases, the following question was asked:

Can we assign you a task of this technology and you will be able to work on that by yourself, without any help, from beggining to end?

If the answer was not a YES right away, it was already an indication that the most correct level was NOVICE.

Next time I intend to change the knowledge levels’ classification and indicators because at the NOVICE level some know a little and others have never heard about it before. At the PRACTITIONER level, it was not very clear initially that it meant “I can do this on my own,” which ended up causing some confusion about the level of knowledge of an EXPERT.

This is an easy and quick to implement practice that allows numerous applications such as adequacy of team capacity, identification of knowledge gaps, and the anticipation of the need for hiring, among others.

Find out more about Team Competency Matrix at Management 3.0 website:

Team Competency Matrix - Management 3.0 Practice