The Career Framework 2 years later: How it impacts our engineering culture at Kiwi.com
Two years ago, if you asked what you should do to get promoted, every team lead at Kiwi.com would give you a different answer (or just a shoulder shrug). And there are more questions you could ask: How do I grow my career? Am I performing well? What is the next step for me? Am I compensated fairly? Even in the context of other teams and departments?
To start giving proper answers to these questions, we put in place our career framework.
Read on if you are interested in how it has been working for us and what impact it had on our culture.
(This article is based on my public talk from our recent Engineering culture meetup we organized in Bratislava.)
The Career Framework bottom line: What is it?
We have already presented our career framework here on Medium. That older article is still very much relevant, so feel free to check it out. Also, this framework is fairly “standard” in terms of what other tech companies have in place.
So let’s dash now through the basics. You can drop a comment if you want more detail on any of these topics.
We no longer distinguish between JavaScript frontend engineers and Python backend engineers. Everybody is just an engineer and we have unified levels to determine everyone’s seniority.
For example, all juniors are level 3 (L3) and all senior engineers are level 5 (aka L5), regardless of their domain or technical stack.
When you want to be promoted, you go from the current level to the next level. This makes up a very clear career path. Some paths can branch, such as whether you want to continue as an individual contributor or rather a people manager.
To get promoted, you need to meet the requirements of the next level. These are defined in a skill matrix and are independent on your technical domain or stack.
Twice per year we conduct a performance review. You sit with your manager and look back at what you have accomplished in the past 6 months. Then you compare it against the requirements for your current level and the next level and have a conversation about what you could or should focus on.
As part of the performance review your manager can nominate you for a promotion. If that happens, your “case” is assessed by a centralized “crowd-sourced” committee consisting of experienced managers and senior engineers from the whole engineering organization. They compare your track record with the requirements of the next level and decide whether you should be promoted.
In this framework, promotions are retrospective, essentially a reward. You’re not promoted to a position but rather when you are already doing the job and meeting all the next level’s expectations. Your motivation and potential for the job are observed and evaluated continuously but they’re not a subject for discussion during the promotion process. All that the committee is looking at is your track record: What you have actually delivered.
Where we are right now
So what exactly happened in those past 2 years?
- So far, we have gone through 3 rounds of performance review and promotions (the 4th round is in progress).
- We have promoted roughly 80 engineers, more than 25 per round, which is 10% of our engineering workforce every round.
- After every round, we organized a focus group to analyze the feedback and come up with improvements. People with negative (but constructive) feedback were intentionally invited to the table.
- We revamped our skill matrix from the scratch to be more helpful in actual career and promotion discussions (this was a large source of negative feedback). We plan to open source our matrix, so stay tuned for that.
- The process is pretty settled, we know what to do, but the operational organization is still a bit painful as at the moment, we still rely mostly on Google Spreadsheets and App Scripts automation. The distinct advantage of this approach, though, is that it allowed us to start with defining the processes and then build the tooling around it (not the other way around).
- HR is now working hard to adopt the framework in other departments of Kiwi.com.
Is it successful? The hard numbers
The key question is: Does it work? Is it successful?
If anybody asks these days what they should do to get promoted, we can give them a rather clear answer: This is where you are and this is what is missing compared to other engineers on the next level.
We didn’t have that before.
In terms of whether people like those answers, it is safe to say that they do. Regularly collected feedback shows that our engineers consider the framework useful and worth keeping.
If you were expecting excited responses, keep in mind that this is at the end of the day yet another mandatory HR process that keeps people from coding. Considering that, the adoption and acceptance is a great success. This is supported by my own experience I get from talking to engineers around me.
When it comes to promotions, those are the most sensitive part of the whole framework. We collect dedicated feedback from committee members (who actively participate in the decisions). Most of them consider the process perhaps a bit slow and tiring, but generally fair, which is the most important metric.
As one can expect, not everybody is happy and we do get 1–2 pieces of rather harsh feedback after each round. But those remain to be isolated cases.
Let’s now get into more subtle topics around the career framework.
We are aligned on what good engineering means for us
How much should a senior engineer know about security?
Think about that question for a sec. Now imagine that whatever answer you come up with should work for React frontend engineers, Python backend engineers and Swift iOS engineers. Pretty hard, right?
When working on our skill matrix, which is the actual definition of what we expect from engineers (ourselves), we had to answer such questions. And while those discussions were lengthy and difficult, they forced us to really get to the bottom of what good engineering means for us.
Byproducts of our promotion process: knowledge sharing & networking
Our centralized promotions are perhaps the most prominent part of the whole framework. Twice per year we form committees consisting of senior engineers and experienced managers and we discuss whether nominated candidates meet expectations for the next level.
This is the main purpose of the committees. However, there are some interesting “byproducts” that I have personally noticed.
First of all, there is a great deal of knowledge sharing. When I sit on a committee, my job is to make sure that we apply the same bar to a JavaScript engineer, working on our customer facing UI, and a Python engineer, responsible for back office processes. I need to learn enough about both of them to make that assessment… and that way I learn quite a lot about what we work on in the company, even in areas I don’t usually get involved with.
This is useful especially because spreading information gets increasingly difficult once the organization reaches a certain size.
This leads to another aspect: networking. Yet again with the intention to ensure a fair bar across all of engineering, we invite and mix people from various departments in promotion committees. As a result, I can honestly say that thanks to promotions I have encountered a vast majority of our team leads. This is something invaluable in the highly cooperative environment of a modern tech company.
Diligent technical discovery
A process like this has a huge impact on our engineering culture. It is impossible to cover all of it but I always get surprised by little things that I keep noticing around myself.
These days, when I ask for a volunteer in my team to own and drive a new project, I rarely have to ask twice. Our framework rewards proactivity and ownership and people have learned that.
Even more prominently, there are design docs. Everybody agrees that writing down a proper technical analysis for a project before jumping into coding is good. But most engineers don’t enjoy writing anything but code and it is really easy to just pretend that a doc is not needed for a particular project… until it’s too late.
With our career framework, it just happens that a design doc is great to demonstrate your ability to understand a bigger problem and get other engineers aligned on your solution. Which is something we expect from all seniors and above.
Just like any system, this one is prone to gamification. I’m fairly sure that there are design docs that were created just for the sake of a promotion. But on the whole, writing a design doc is rarely wrong and engineers now have another incentive to be good engineers (how much immediate reward is there for writing tests anyway?).
When I look around myself, I can see the “design doc culture” taking off. We write more docs, of better quality, and spend more time in the “pre-coding” phase.
The opportunity to praise and be proud
One of my favorite aspects of our career framework is that it gives me, as a people manager, a regular opportunity to praise my folks.
You can’t talk about someone’s performance without looking into what they have done, where they succeeded and sometimes where they failed. So that’s what we do. It’s like a team retrospective but on a personal level.
The value of having a process for this is that it forces you to actually sit down together and do that retrospective. Look into the past projects and achievements that may have been already forgotten. Look into the improvements from last time. Look into how your folks stacked against the level requirements before and how they do now.
Then, more often than not, I find myself compelled to say “hey, you did a great job!”. And it’s not that kind of compliment that you just say to somebody to make their day good.
This is equally true for the centralized promotions, which I personally find many times really uplifting. Many of the projects that I learn about during the process are cool and the folks delivering them amazing. Then it just feels great to give somebody a clear thumbs up on their promotions, knowing it is more than deserved.
What’s next
What’s next for us? Actually, not much. The “product” is launched, it works, so now it is time to polish it and reduce the maintenance cost.
Now that the career paths are clear and everybody knows what is expected of them, it is time to give our engineers all the available support so that they can start growing at their fullest potential.
Regarding the cost, the process is still relatively heavy weight to run and we spend perhaps too much time on it. So that’s definitely going to be our focus.
As mentioned, we intend to publish our skill matrix so that others can take inspiration, and there is also an article in the workings that zooms in on the challenges of “fast & fair” promotions. Stay tuned for that.
On behalf of Kiwi.com,
Tobiáš Potoček, Engineering Manager for Booking & Self-Service
