Launch of the Financeit Developer Career Path

It’s been another long while since we posted anything on our tech blog, but this seems like an update worth sharing. Earlier in 2022, we launched our Developer Career Path internally, and now we’re sharing it with anyone else who’s interested in it.

How we got here

In Financeit’s earlier days, most people simply had the title of “Developer,” with a couple who had the title of “Senior Developer,” but it wasn’t specified anywhere what distinguished one title from the other or what one needed to do to ascend to the level of “Senior Developer.” While certainly not ideal this worked for the most part as we had a small development team and meaningful titles weren’t too important when we were putting together project teams (“pods” in Financeit lingo).

As we grew and more developers joined the team, we needed to give them an idea of where they were on their career path and what skills and behaviours they needed to demonstrate to move along that path. Additionally, as we added more pods it become increasingly important to ensure we built them with the right balance of skill levels. Out of these needs, the idea of the Financeit Developer Career Path was born!

How we did it

Back in 2019, our then Director of Engineering, Kallin Nagelberg, kick-started the design of a career path tool. They had noticed a critical mass of their team members, especially those newer to the company, who wanted clear instructions on progressing in their role.

Around that same time, Kallin had taken notice of a great resource in https://progression.fyi/ where many great technology teams had open-sourced their career ladders/frameworks/levels/etc. Working with the other development managers on the team, they all researched different companies’ approaches from Progression.fyi, reported on the parts they liked the most and used that to begin drafting a career ladder that made sense for Financeit.

After the initial draft was done, we solicited feedback from members of technology leadership and the broader developer team. Then, we made corresponding changes to get us to the competencies and levels’ final version (*the first final version).

Changes along the way

The number of levels that we established for the initial final version was designed so that our current development team was distributed across the four levels in the career path, which initially seemed pretty intuitive. However, we quickly realized we’d unintentionally created an upper limit on their career at Financeit as there was no higher level for the more senior developers to grow into. To address this concern, we adjusted the content and created a new highest level where only a very few developers would be placed initially so that more of the team had a clear next step in their career path.

How we launched it

To aid the process of assigning the initial levels, Gearoid Miggan offered the idea of involving each developer. We had them rank themselves for each competency so the developers and their managers had an idea of where they fit along the path. In our experience, the developers all had a realistic view of their current level, making assigning titles reasonably easy. I can’t promise this will be the same for other teams though!

Additionally, before making any final decisions on titles, the development managers met to discuss the proposed levels for the whole team. This was essential as the different managers interpreted the levels a bit differently and we needed to ensure we were aligned on how we evaluated the team and to remove any potential biases.

When launching the new titles, we also stressed that no salaries would be changed as a part of the process. In the long term, an additional benefit of the career path levels would be to help establish salary bands and ensure pay fairness, but in the short term, the goal was to guide career path development, so we focused on that when launching.

What’s next?

The hope is to use the Developer Career Path tool to aid in performance management and guide peer feedback during our semi-annual review process. Additionally, we’ll continue to refine the content when we find it to be unclear or irrelevant to the team. We are realistic that some (a lot?) of the content might need to change over time, but we felt good about this as a starting point, and we will be open to refining it as we continue to use the framework.