How to build a career framework like an RPG

This article originally appeared on the Mews Developers blog.

The CTO role, especially for a first-timer, is sometimes tough because nobody gives you specific things to work on or tackle. Of course, there are some expectations imposed on the technical department which can be summarized as "delivering quality solutions as fast as possible". People outside of tech or product would sum it up as just "building features". However, at some point the delivery process works reasonably well and improvements start to feel more like polishing than radical progression.

So are there other topics that a CTO should tackle that are not implicitly expected from them? Googling "responsibilities of CTO" definitely helps and it's good to have a general notion of all the areas. When asking myself what to tackle next, it helps me to imagine what would be the question that I would never want to be asked in a panel discussion or on a company all-hands. This naturally yields the topic that you perceive as the weakest spot.

So about a year ago, when our team was going through rapid growth, the question I was the most afraid to get was: "What are you doing for the career development of your people?" Because I'd have to answer: "Nothing much." At the same time, a few developers started discussing their career with me on our one-to-ones, so I knew I should do something about it. The rest of this article will describe what we’ve done so far and how we rolled it out across our team of 60 tech people.

Competencies

Building an engineering career development framework sounded boring at first and I didn't know where to start. However, I was familiar with a lot of role playing games that I played during my teenage years. As a programmer at heart, I decided to reframe the problem as if I was designing an RPG where, for example, a developer is the character. They would gain skills, level up in some competencies and that would increase their overall progress.

Starting bottom up, first thing to decide are the competencies (the equivalent of strength, endurance, and charisma in the RPGs), their levels (should it be 0-5 or 1-10), and the skills needed to achieve particular level. Luckily for me, a few companies including Etsy and Spotify did exactly this and open-sourced their competencies and skills – here’s Etsy's competency model. It works really well because it contains lot of very specific and objectively measurable skills, so people can easily understand what they need to do in order to get better. Also, it’s extremely ambitious; it takes a lot to get to the higher levels, which goes in line with our principles.

The competency model is designed primarily for engineers, but with a slight tweak and little bit of interpretation, it is usable for other roles within a tech department or even outside. There are five competencies:

• 🚚 Delivery – Planning, prioritization, delivery, testing, and monitoring.
• 📚 Domain Expertise – Knowledge of domain, tools, business, and product.
• 💡 Problem Solving – Analysis, creativity, decomposition, and architecture.
• 💬 Communication – Collaboration, documentation, and relationships.
• 🎖️ Leadership – Responsibility, decision making, and mentoring.

Skills

A competency consists of levels and skills. There are many skills, for example: "You test your work by following relevant examples." That is a skill within the competency: delivery on the beginner level. For each skill we evaluate its completion using the following scale:

• 0 – Not at all, meaning that the person doesn't possess the skill.
• 1 – Person having the skill somewhat, but not fully there yet.
• 2 – Fully possessing the skill, being able to provide a few examples.

Thanks to this tri-state scale for each skill, it's not black and white which makes it much easier for managers to have discussions with their people.

Levels

‌Each of the competencies has six levels of expertise:

• 0 – Starter – At the beginning of the learning path.
• 1 – Beginner – Possessing basics of the competency – still rather junior.
• 2 – Intermediate – Progressing further within the competency – mid-level.
• 3 – Advanced – Having more advanced skills – senior in the role.
• 4 – Expert – Passing the knowledge and having organizational impact.
• 5 – Leading Expert – Advancing the industry forward – thought leader.

The competencies are rather aspirational – to get to level 3 is already a big achievement. Levels above that require the person to have impact past the standard boundaries of the competency and to affect whole organization or even industry. Putting all of the above together, we created a simple file that tracks all of this and automatically calculates the levels for each competency.

In order to reach a level, average completion of skills on the level has to be above 1.7 and there cannot be any skill with 0 completion. Also the previous level has to be reached, you cannot skip levels :)

Directions

In RPGs, not all competencies are relevant to the character choice. For a warrior, it's important to boost strength, for a mage, you usually need to level-up intelligence. The same applies to tech teams: different roles need different competencies, and the most common split is with individual contributors and managers. However, we decided to adopt another approach – not to think about the orgchart in the first place and instead define three main "character" directions. For each direction, we then determined the importance of the competencies (and skills there) and assigned them weights according to that. This might differ in your case if you don't have same expectations as us.

👨‍💻 Individual Contributor

🚚 25%      📚 30%      💡 30%      💬 10%      🎖️ 5%

The most straightforward direction, individual contributors are primarily responsible for their own tasks, and they don't have responsibilities involving management or coordination of people. The most important competencies are those around individual technical skills and to progress forward, you really need to become a domain expert who is able to consistently deliver excellent solutions. However, no one can fully avoid interacting with people – that is needed even for this direction.

👨‍🏫 Functional Leader

🚚 5%      📚 30%      💡 25%      💬 20%      🎖️ 20%

This direction is the natural evolution of the individual contributor. In our setup, functional leaders are responsible for longer term strategic decisions in their domain, the career development of other people of the same function, expertise, problem solving and mentoring. There is still big focus on problem solving and domain expertise, but the primary goal is to help individual contributors. Communication and leadership is important on top of that, but delivery no longer matters. A functional leader is successful if the individual contributors they mentor are successful.

👨‍✈️ Cross Functional Leader

🚚 30%      📚 10%      💡 15%      💬 20%      🎖️ 25%

A cross functional leader is primarily responsible for the speed and quality of delivery of a team or group of teams. One person cannot be an expert on everything, therefore domain expertise is not needed that much. When it comes to problem solving, individual contributors within the team can consult with their functional leaders regarding technical problems. On the other hand, delivery is crucial, together with communication and leadership. Compared to a functional leader, this role is more tactical, shorter-term and also requires more communication with various other stakeholders. A cross functional leader is successful if their team delivers predictably, fast and with high quality.

Progress

In order to determine how far a person is in their career, we need to know what direction they are pursuing (e.g. individual contributor) and the levels in each competency (numbers between 0 and 5). We then apply a weighted average on the levels using weights based on the direction. This way, we arrive at single number which represents overall career progress.

As an example, let's consider a developer with the following levels:

🚚 2      📚 3      💡 2      💬 2      🎖️ 1

If we then apply weighted average using weights of individual contributor:

🚚 25%      📚 30%      💡 30%      💬 10%      🎖️ 5%

We arrive at overall career progress 2.25.

Reviews

With the framework described above, you can already start having career discussions and performance reviews. How to conduct a performance review is a whole topic on its own that could take another article, so I'll only describe the process we use:

1. A person creates copy of the competency sheet.
2. They conduct a self-assessment and fill it in.
3. They have an one-to-one session with their manager where they discuss it, and the manager might push the person up or down.
4. We record the outcome so that we can utilize the data.

After everyone finishes with their self-assessment, it's best to perform the one-to-ones top-down. I set the baseline when I review my managers, they do the same thing with their managers and it traverses down the orgchart (for people with computer science background, it's a BFS algorithm). In practice, it takes multiple rounds of reviews to adjust it and really balance it across the whole organization – some managers might be overly strict, some might be too tolerant. However, thanks to objectively defined skills, even if there are some discrepancies, they're not big.

Helping people grow

Initially I found this whole framework pretty complex, and was worried that it would not gather traction and we would have to force it on people. But actually the feedback was really positive; people like it and even other departments in the company started adopting something similar. The best part is that it gives everyone a really clear guide on what to focus on based on their direction. And within the important competencies, it lists specific examples of what is expected of them. Actually, just doing the self-assessment on its own is eye-opening and when I tried it on myself, I found out that I need to get better at gathering and receiving feedback.

It’s one thing to show you where you need to go, but it’s another thing to help you get there. We have already been doing extensive code-reviews, solutioning discussions, regular one-to-ones and sponsoring conference tickets, but that is mostly centered around "hard" skills. We wanted to cover the "softer" skills as well, so as a follow-up, we started extending the range of what we offer to people in terms of engineering career development. We started using Pluralsight as a skill development platform and PlatoHQ as a mentorship platform. We introduced "monthly mentorship days" where senior leaders dedicate whole day to mentor others who are interested. We, together with people team, started organizing trainings on various topics, e.g. presentation skills, communication, and management skills, and we're still looking at ways to improve this.

"What if I train them and they leave? …What if you don’t and they stay?!"

This first part covered mainly the technicalities of the framework and how it internally works. In the second part, I will focus more on what we built on top of this (engineering career tracks, compensation strategy) and also reveal some tools for managers that utilize data gathered during the reviews. I'd be more than happy to hear your feedback in the comments (you see what I did here, trying to fulfill the feedback skill in my communication competency) or answer any questions. You can DM me on Twitter or LinkedIn as well.