At Bitrise, our mission is to empower mobile teams across the globe with the best Mobile DevOps solutions in the market. That starts with our people and equipping them with everything they need to succeed.
We take our people’s growth seriously and want to support them to take their skills to the next level. In this post, I will share how we built a simple framework to increase clarity and transparency around performance and also to make it easy for the team to understand how they could contribute to the bigger goals of the company.
What is a competency framework?
A competency framework defines the specific skills, knowledge, and behaviors an individual needs to demonstrate to performance at each level. It's basically a set of expectations about what we expect, for instance, of a Senior Software Engineer, plus the wider structure around that role, such as salary ranges, titles, levels, and job descriptions. It helps us set and maintain a standard for hiring, tracking job performance, providing feedback, and setting growth goals.
While assessing competency will always be influenced by subjective factors, having a framework in place helps to eliminate bias from the process.
Skill matrix vs. competency matrix vs. competency framework
Over the course of your career, you have probably come across a competency matrix.
It's a very simple tool that sets the hard and soft skills someone requires at each level in their role. It's a very good starting point. But as your organization scales it becomes less effective, as there are always more deciding factors than simply skills.
Think about interviews: you might have a candidate with the best skill set for the job, but you end up hiring someone with a mix of skills, knowledge, and behaviors that fit your team better.
So what's the difference between these terms? A skill matrix is the simplest version - it maps hard and soft skills against levels, and nothing more. A competency matrix goes a step further by adding knowledge and behaviors into the mix alongside skills, giving you a fuller picture of what's expected at each level.
To elevate it to a competency framework, you need to include salary ranges, titles, levels and job descriptions. Together, these provide the tools to keep career progression transparent, fair, and manageable.
How our values guide our framework
Our values are what make Bitrise what it is today. They shape how we work, how we interact, and how we support our customers. And so it’s only natural they sit at the heart of our competency framework.
They’re not something you can just write on a website or display on your office walls (if you even have one) and expect people to follow. You have to live them day to day and be clear about what they mean in practice.
Here's a look at how our values connect to our competency framework.
- ⭐ We move with urgency and focus: We work in close collaboration, react quickly, iterate often, and aim to find practical solutions based on real data.
- 🤝 We are direct and open minded: We give and receive recognition and feedback, often and directly. Instead of focusing on the mistakes, we find a way to learn from them.
- 💜 We care: People come first. We listen to our customers and employees, and ask questions to better understand their needs and to help them be successful.
- 🌸 We help each other be better: We believe the best way to work is by working together in a diverse team, collaborating with each other and inspiring each other to be the best ourselves.
Our values apply across our whole organization, underpinning everything we do. We use them in our hiring process, sharing feedback, reviewing projects, and setting our strategy. But most importantly, in how we support our people’s career growth.
How we connect competencies and salaries
The other important player in our framework is salary.
Many people put salary firmly at the top of the "what's the most important factor when applying to a role" question. And so it goes without saying it's a crucial but also very sensitive aspect to get right.
Without a framework, here are some of the challenges you might face:
- You want to hire a new team member, and most candidates ask more than the average salary in your team. What do you do?
- When someone advances in their career and gets a promotion, they expect a higher salary. How do you decide what’s reasonable?
- If you want to give a salary increase to some team members, what are the appropriate levels?
Salary ranges help you to set the minimum and maximum salary for each role and level. Add multiple countries and continuously changing industry averages to the mix, and you'll have quite an exciting project to build!
Salary transparency
Salaries are a sensitive topic, so the more transparent your decision-making criteria, the better. With a competency matrix, you already have defined a set of expectations. With salary ranges, you already have the data. From there, it’s a small step to add salary ranges to your job descriptions and share them with your team.
Not necessarily the exact salary of each employee (but you can also go with a fully transparent salary system), but more the levels and ranges.
This way, salaries, and most importantly: the conversations and decisions around it become a lot more transparent and fair.
Building our competency framework
We decided to start with Engineering. This wasn't random: most of the available resources, benchmarks, and industry references for competency frameworks are focused on software engineering roles. And so this gave us a solid foundation to build on.
Also, a lot of the team we have at Bitrise work in an Engineering role, so we didn’t need to start from scratch. We already had a competency matrix in place, but as we scaled it became clear that it had significant gaps.
For example, it lacked consistency across levels, couldn't fully capture behaviors and impact alongside skills, and left too much room for ambiguity when it came to promotions and performance reviews.
Identifying our needs
Before jumping into a redesign, we wanted to make sure we actually understood the problem properly. So we sat down with every engineer individually. Not just to explain what we were planning, but to listen. We asked about their experience with career progression at Bitrise, what was unclear, where they felt stuck, and what they wished they had more visibility on.
The conversations were eye-opening. Many of the same themes showed up repeatedly: people wanted clearer expectations at each level, more transparency around promotions, and better tools to support growth conversations with their managers.
Armed with those insights, Engineering Managers came together to create a first working draft. Rather than designing the framework in isolation and presenting it top-down, we built it collaboratively.
Based on everything we'd heard, we aligned on what “good” looks like at each level and stress-tested it against real examples. It was messy and iterative, but going through that process is exactly what made the result feel grounded and credible.
How it’s evolved
After about a year of running the framework within Engineering, it was clear that it worked well.
Career conversations had become more structured, promotion decisions more consistent, and engineers had a much clearer picture of what growth looked like at Bitrise. That gave us the confidence to think bigger.
Keeping it alive
Since then, we've made it a habit to review the framework annually. We look at it as a living document, not a one-off project. And so each cycle, Engineering Managers revisit the expectations at every level, incorporate feedback from the team, and refine areas that have become outdated or unclear.
Expanding beyond engineering
Around the same time, our People team started partnering closely with Engineering Managers to explore how we could scale the framework beyond Engineering. This collaboration was the turning point that transformed what had been an engineering tool into a company-wide system.
And this is precisely why we call it a framework rather than a matrix: it was designed to be extensible. Other teams and departments could take the same structure (levels, expectations, behaviors, salary ranges, etc.) and apply it to their own roles without starting from zero.
Giving people a say
From there, each department lead took ownership, working with their teams to define what career progression looked like in their context. The key to success was the close collaboration between the People team and each department. This allowed expectations to be set correctly while giving teams the ability to shape them based on their needs and requirements, while also staying consistent with our company wide structure and standards.
The rollout has been deliberate and gradual. We extended the framework to every team that had at least three people working in the same role. A threshold that ensures the investment in defining a career path makes practical sense. Team by team, the framework has grown to span the whole organization.
What we’ve learned so far
As a team, we learned a lot, especially by taking the time to collaborate and listen to our people.
Building a competency framework from scratch can seem straightforward at first, but there’s a lot to figure out along the way. Here’s what we learned, and what to keep in mind if you’re building one yourself.
- Start narrow, then scale. Trying to build a framework for every role at once often leads to something too generic to work for anyone. Starting with Engineering gave us a somewhat narrow scope: we could validate the approach, collect feedback, and build confidence before expanding. By the time we brought other departments in, we had proof it worked.
- Listen first. The individual conversations we had with engineers before writing a single line of the framework were some of the most valuable hours we spent on this project. You can't design good career progression in a vacuum. The people experiencing ambiguity are the ones who can tell you exactly where it lives.
- Transparency changes behavior. When people understand what's expected at each level and what the salary ranges look like, the nature of career conversations change completely. Managers spend less time managing expectations and more time actually supporting people to grow.
- A framework only stays useful if you maintain it. An annual review cycle shouldn't be optional: it's what prevents the framework from becoming obsolete. Industries change, teams evolve, and a competency framework that was accurate two years ago might be quietly misleading you today.
- Don't force it where it doesn't fit yet. Setting the threshold of at least three people in the same role before rolling out a career path turned out to be one of our best practical decisions. It keeps the process meaningful and avoids the overhead of maintaining career ladders for roles that are still taking shape.
What's next
In our next post in this series, we’ll deep dive into how these tools were introduced to the whole organization across different teams, areas and roles.
