At 360Learning we have a strong culture of autonomy and transparency. It’s important that employees on all of our teams feel they have the tools and support they need to grow within the company—and our engineering team is no exception.
One of the tools we use to provide transparency to our teams around professional development is our Career Path framework.
A Career Path is a standardized set of skills we can use to assess performance and frame conversations around professional development. It's a tool that gives employees a clear perspective on how they can grow within 360Learning, and what exact skills they would need to develop to get there.
We had been using a Career Path system in 2019, but we realized it needed tweaking: it was too complex and difficult to use in practice; it didn’t reflect the value we place on soft skills; and it was too subjective.
So, last year, we decided to write a new engineering Career Path from scratch. We used the work of companies like Spotify and Medium as inspiration. Five volunteers from our team helped me design and write the Career Path and we gathered feedback from the whole team to refine it in the end. Big thanks to everyone on the team who participated in this project.
What follows is a detailed look at our updated Career Path for our engineering team. If you’re thinking about joining us at 360Learning, looking for a blueprint for your own team’s Career Path, or just curious how the process works, read on.
What our engineering Career Path looks like: the five skills
When revamping our engineering Career Path, we decided to limit the grid to five core skills: Technical Mastery, Product Crafting, Organizational Mindset, Collective Improvements, and Community. Any more, and the assessment process would be too complex, and certain important skills wouldn’t get the attention they deserve.
Then, each skill is divided into six different levels, which are ordered according to the scale of impact they have (from individual impact to impact on the whole company and the market). Level one, for instance, includes skills whose impact is mostly at the individual level—an employee who follows best practices, works autonomously, etc. Higher levels will reflect skills that have a farther reaching impact.
Standardizing the skills and levels in this way allows us to unify the progress in each skill, and maintain the same range of expectations for each level. In order to ascend the levels, the skills in all the previous levels need to be mastered.
1. Technical Mastery
This is the core skill of the engineering team. It includes every technical skill of the job: coding, dev cycle, quality, monitoring. Even though this covers a lot, we decided not to break it up into multiple different skills on the grid.
We like to look at ‘technical mastery’ as a whole, since excelling at one aspect of it without the others—coding without writing good tests, writing tests without monitoring them, etc.— will limit the value an employee can bring to the team. The lower levels are about applying technical guidelines; the highest levels are about driving the vision of the codebase architecture.
2. Product Crafting
Each developer is expected to share feedback and have an impact on the features. This skill represents the involvement of the developer in the design of the user experience. The lower levels are about understanding the product; the highest levels are about understanding the market and impacting the roadmap. You can see Product Crafting at work in this developer feedback, below:
3. Organizational Mindset
Each squad—a subteam including one Product Manager, one Product Designer, and a few developers—is self-organized and everyone in the team is involved in making things run smoothly. This skill represents the involvement of the developer in the squad’s organization. The lower levels are about communicating well enough to keep the squad aligned and the roadmap on track; the highest levels are about planning cross-team projects.
4. Collective Improvements
360Learning engineers grow as a team. Each member is encouraged to share knowledge by organizing workshops, improving our practices, writing articles, etc. The lower levels are about applying best practices, for instance never working on more than five different tickets at the same time to avoid losing focus.
5. Community
Above all, the engineering team is a cohesive community, in which each member helps others, and where we can rely on each other. The lower levels of this skill are about being benevolent and communicating clearly; the highest levels are about mentoring team members and onboarding new ones.
These five skills encompass what, at 360Learning, are the core competencies for our developers. When it comes to career development discussions, this is what we use as our guiding framework.
As mentioned above, we divide each skill into six levels, for a more granular way of assessing progress.
What our engineering Career Path looks like: the six levels
Each of the five skills is divided into six different levels, ordered from individual impact to impact on the whole company and the market. They define the expectations we have from developers in this skill, with level one being the lowest set of expectations and level six the highest.
For each level in the Career Path, there is:
- A brief description: this gives an overview of the expectations for this level. Here’s an example from level one of Technical Mastery: “Is able to develop simple features and is actively learning with the help of their peers. May infrequently have issues following patterns/practices in existing code.”
- A list of hard requirements: This is a list of precise and objective behaviors or actions that are required to reach the level. All of these hard requirements must be met for a developer to reach the given level. Here is an example from level one of Technical Mastery: “Always writes tests whenever it's straightforward to do so (test file already exists, or there are multiple examples to get inspired from).”
- A list of soft requirements: This is a list of examples of behaviors or actions expected at this level. There’s no fixed rule about how many requirements are needed to validate the level, so usually we estimate someone must reach half of the soft requirements to reach the level. Some of these requirements can be a bit more subjective. Here is an example from level one of Technical Mastery: “Knows when to ask for help, who to ask, and doesn't get stuck on a problem.”
This combination of hard and soft requirements allows us to have clear and equal expectations for everyone, while keeping enough flexibility to recognize specific behaviors.
An important thing to keep in mind is that a developer can grow or take on a new role, even if their progress isn’t evenly distributed among these skills. For instance, reaching a high level in Technical Mastery makes someone a good candidate for the Architecture squad, whose work includes architecture and cross-departmental topics.
If one is mostly interested in Product Crafting or Organizational Mindset, the developer may want to move to a Product Manager position later. The “Collective Improvements” skill naturally leads to being a public speaker or writer, and “Community” can help developers become mentors and/or onboarders.
You can see our entire Career Path, here.
How we use our Career Path to further our team’s growth
This Career Path grid is a cornerstone of how we coach the engineering team, and we use it at different levels of our feedback loops: to create alignment between reviewers, to help developers see how their role can evolve, and to establish clear expectations for everyone. Here are the main ways we rely on this document in our everyday operations:
To structure peer-to-peer feedback
In the engineering team, we rely heavily on peer feedback: Every six weeks, we assign random peers as reviewers for each engineer. This takes the place of the classic peer/manager relationship found at most other companies.
What do they use as a basis for their feedback? Mainly, reviewers look at all the pull requests created by the engineer. They share feedback about code style, code quality, functionality, etc. At the end of the cycle, the reviewers meet the engineer to share high-level feedback—for instance, trends they identified based on the pull requests they reviewed.
They share feedback about the non-coding tasks they observed as well, like remarks they shared to challenge the priority of their squad’s roadmap. They conclude by giving a rating to evaluate the engineer’s performance on this cycle.
In this process, the Career Path document is crucial as a baseline for making these assessments, allowing reviewers to calibrate their feedback according to the engineer’s level. Here’s an example:
Let’s say an engineer implemented some complex features while reviewers were able to find simpler solutions. If the engineer is level 1 in Product Crafting, the feedback will look like “You can improve by frequently challenging the spec of your tickets” and the rating will be something like A (“meets all expectations, in line with the 360Learning standards”).
Now if the engineer is level 3 in Product Crafting, the feedback will probably look like “Given your level, you should challenge the spec of your tickets systematically and suggest simplifications” and the rating will be something like B (“meets some expectations, misses others, with a strong potential to improve”).
Basically, the Career Path allows everyone in the team to adapt their expectations and share tailor-made feedback, which keeps everyone accountable and adequately challenged.
As a resource during Lead Feedbackers’ follow up
Having frequent and varied feedback about your day-to-day work is a great way to grow, but it’s not enough. In the long run, our engineers need more visibility about their own growth. In addition to the peer-to-peer feedback, we created a dedicated role of the “Lead Feedbackers” who act as mentors for others.
At the beginning of the year, anyone on the engineering team can volunteer to be a Lead Feedbacker, with some conditions (for instance, being level 2 in the skill Community).
Then, each developer chooses their own Lead Feedbacker among the volunteers. It’s important that we allow each engineer to select their own Lead Feedbacker, instead of imposing one: Choosing the Lead Feedbacker makes sure both the Lead Feedbacker and the developer are aligned, and removes any friction.
So, what do Lead Feedbackers do? They’ll follow the developer throughout the year, and receive feedback from different team members. They’ll use this to help the developer identify how they can further grow.
This work is also based on the Career Path. They can discuss which skill the developer wants to or should work on, how they can reach the next level, etc.
In terms of frequency, they meet at least four times a year, but they can organize themselves as they want. Most Lead Feedbackers meet the developer once a month, some even once a week. This is usually used as follow-up meetings to make sure the developer is putting their efforts where they’re most needed.
This follow-up ensures the developer has a clear vision of how they can develop professionally, and what is expected from them.
As the backbone of Career Path (re)assessments
Twice a year, we open a window for anyone to volunteer to be assessed or reassessed with the Career Path, to see if they can reach a higher level. Newcomers (not on probation period) will be automatically included.
Lead Feedbackers are responsible for the Career Path assessment. They discuss with the developer and any peer who is able to provide insights. Finally, the grid is shared with the developer to understand what new levels have been attained, which requirements are reached, and which aren’t yet. It’s also an opportunity to discuss the career plan for the following months.
Newcomers are assigned a default level during the hiring process based on their past experience and their performance during the hiring process. For the first 12 months in the team, we use the highest level between the default level and the assessed level. The Career Path is based on measurable requirements and some of them can require someone to be in the team for several months before reaching them. The assessments are still useful for newcomers to identify where they are in the grid compared to the team’s expectations.
Once an engineer is given a level in each skill, we can compute their overall level of seniority—using the same system as everyone in the company—thanks to a formula the whole organization has access to. These levels are transparent for everyone on the engineering team.
Anyone can see the individual level and the level in each skill from any other team member. This way, everyone is able to understand the expectations we have from them and act accordingly.
Want to be part of the team?
As you can see, the engineering Career Path is the cornerstone of individual growth in our team, and we’re proud of the reworked version we use today. Of course, this system is based on our unique company culture at 360Learning.
We learned from using our former Career Path that copy-pasting a Career Path from one organization to another simply doesn't work. But even though it was crafted with our specific team dynamics and company culture in mind, it can still be an inspirational blueprint for anyone else working on a similar project.
Do you like the way we empower our employees to learn and grow at 360Learning? Check out our open positions!
Our weekly newsletter of the best insights from L&D peer to L&D peer.
By subscribing to this newsletter, you agree to our privacy policy.