Whimsical is a B2B SaaS company, striving to provide top-of-class online collaboration tools for the many digital tasks of product teams, such as documentation, wireframing, mind mapping, whiteboarding, and project management. Our primary goal is to "make innovation more accessible". Currently, our team comprises 44 employees, including 17 engineers. We appreciate our small size, as it enables us to stay agile and adapt to change.

In August 2022, when I joined Whimsical, we had well-structured compensation levels but we relied on our small size and ability to maintain relationships to go without fully defined expectations or role descriptions. So we decided to refine our management approach to better address the career growth and performance evaluation of our engineers.

In line with Whimsical's philosophy of being transparent, this article details how we developed our Career path framework and implemented it within our engineering department.

Examine existing frameworks

To begin, we researched the career path frameworks used by other technology companies - both similar in size and larger - which led us to examine various public frameworks. Although some were only accessible via internal channels, many were available freely and provided valuable insights into developing our own framework. Here are a few of the ladders we reviewed:

• Renttherunway
• Zenput
• Envoy

We looked at more than I‘ve shared, but some were not publicly accessible, so I won’t mention them. You can find more career paths or ladders here.

Compare levels and compensation

Our existing structure had five levels (depicted in the image below).

Compared to other tech ladders Whimsical was missing more levels to ensure proper career progression for our lead engineers and motivation for juniors to pursue growth.

We saw that at other companies, management positions made a higher salary than individual contributors, (ICs), at the same job level. Nonetheless, we decided to maintain similar salaries for managers and ICs to embody our belief that managers should not be significantly higher compensated than experienced engineers. You can read more about our compensation philosophy here.

Plot current and potential roles

Although we do not anticipate drastic headcount growth in the next couple of years, the framework must be adaptable enough to accommodate promotions across all existing levels. So we ended up with this.

The dotted boxes represent future roles

The observant reader will notice an absence of junior engineers. By being a globally distributed, remote company, with little overlap in terms of time-zones - early on we prioritised having very technically strong, self-driven folks that needed little guidance on a daily basis. And that tended to be senior engineers. Having a stronger culture and baseline for how we operate today, we are looking to hire junior engineers to create a healthy ecosystem of mentoring, coaching, and growth.

I should also mention the tech lead track, which we consider a bordering zone between IC and management tracks. As a tech Lead you are not compensated more. This role is given to strong performers that show strong leadership skills, and who want to take on the additional responsibilities like being responsible for the overall quality of code a team delivers, ensuring bugs are dealt with, coordinating who works on what, assessing incoming requests and a bunch more.

Define performance areas

To set clear expectations for our team, we needed to define each level in terms of performance, aptitude, and impact.

When we looked at other established frameworks, we noticed a big disparity in how they described the details of each level, some of the frameworks took inspiration from fantasy roleplaying, using Dex, Charisma, Wisdom, Strength. Others had 3 categories that covered, Scope, Skills & Experience, Behaviours & Mindset, or similar.

To create a framework that felt right for Whimsical we brainstormed around our core values, and what we want to emphasize and see people improve in.

The key performance competencies we decided on are:

1. Technical
2. Ownership
3. Business & Product
4. Collaboration & Culture

These competencies are linked to a "scope of Influence". which reflects the focus of each individual role. For instance, an IC2 is expected to concentrate on tasks and epics within their team, mastering the competencies listed under the four performance areas. Conversely, an IC4 has a broader scope, encompassing team and product engineering stakeholders, while an IC8 (Principal Engineer) holds company-wide influence.

Define role-specific competencies

The most challenging part was illustrating role-specific competencies for each level within the four performance areas. This involved providing clear examples and ensuring that expectations aligned with increased experience and skill mastery.

Despite the difficulty in capturing these nuances, we accepted the fact that the framework is a living document, subject to change and would evolve over time. Rather than attempting to list every detail, we focused on capturing the essence of each area for each level.

We’d use 1:1’s and performance feedback sessions as opportunities to delve into specifics and tailor growth initiatives to each individual’s needs, that’s the real magic that no framework would ever be able to capture.

We ensured we didn’t use language that gamifies the career path, or set binary goals with specific competencies, as they may cause people to focus blindly on achieving one specific thing on the list of competencies.

You can check out our public Engineering Career Path Framework here.

And now the real work begins

Developing a framework is only the first step; effectively incorporating it into regular operations is crucial to its success. We contemplated ways to integrate the framework into 1:1’s, annual and bi-annual performance feedback sessions.

During performance feedback sessions, we use the framework to identify strengths and areas for growth for each engineer.

By highlighting and color-coding these areas, we gain an overview of their progress and establish a benchmark for all engineers. The manager then shares this feedback with another manager for validation and gathers input from peers. These sessions result in concrete action points for growth, along with areas where the engineer has made significant progress.

Weekly one-on-one meetings ensure a mutual understanding of goals and guide them to approach these objectives in their day-to-day work.

In addition to these sessions, we initiate professional growth projects at least twice a year, catering to each engineer's unique motivations and goals for development.

What’s next?

Ultimately, we plan to introduce a management path; however, this is not an immediate priority, given our size and growth plans. Yearly retrospectives and assessments of the framework's efficacy will ensure it remains relevant and useful for our engineers. If the framework fails to provide adequate support and clarity, we will adapt our approach accordingly.