Presenting our developer seniority guide

It’s crazy to think that our company has been around for more than 10 years. I feel like it was yesterday when we started. While I always feel like we are not moving as fast as we could, the reality is if I look back on the years we have actually changed and improved so much.

I personally did not have the benefit of working in a large and organized development company before starting Borealis. And a lot of the early people that are now leading the company started at Borealis as juniors. This meant we had to figure out a lot of the stuff the hard way. Through mistakes, we would learn things that others have learned through their jobs.

When we started we had really basic processes on our whole development workflow. We did not have a proper project management workflow, instead everybody managed their projects in their own way. Slowly, with each completed project we learned something and improved.

One of the issues we ran into was career progression. Over the years our team members have advanced a lot. In the beginning we did not really have strict definitions of seniority levels. They would just start and get a basic salary based on my feeling on what level they are. As they would progress I would monitor their work. When I felt like their contribution to the company has grown, they would get a pay raise.

This worked good in the start when there was few of us and I worked closely with everybody. As we grew I found that I could no longer keep up. There were people with whom I would not work directly almost at all, and I would base all their progression on the feedback from others. Apart from the problem that one person just should not manage so many other people like I did, the other problem was expectations.

I found out that different people set them differently. I would ask some of our leads and seniors on feedback on their junior collogues. Some held them to very high and strict standards, while others were very forgiving. My own expectations were also different to theirs. I also realized when interviewing people and asking on what seniority level do they see themselves they would give out very different answers, because everybody has their own idea of what different senioritis mean. We soon realized we need to set a proper standard.

That’s why we introduced our developer seniority guide. The guide sets clear general expectations on what the company expects from all developers regarding of their level. It also describes each of our seniority levels in detail including expectations and salary ranges.

These days team leads have taken over managing their teams from me fully. They prepare personal development plans for their team members. These plans outline their career path and what they should focus on to further advance. Team leads are the ones in charge of their team members and their progression and advancement in the company.

Looking back it it now, this feels like such a no-brainer. But at the same time I’m speaking to a lot of other CEOs, and I find out that actually don’t have this clearly and transparently laid out and written. That’s why we have decided to make this guide public in the hopes that it will help other companies setup their own expectations for people. But also, we want it to be out there for all our future team members. This way, when they apply for jobs, they can get a very clear picture of our expectations even before the first interview.

You can download our developer seniority guide here.