We’ve been fortunate to have had a nice growth phase at Nutrient over the last few years, which led to our engineering team more than doubling in size. And as we grew, we recognized the need for a more structured approach to support individual development and enhance organizational effectiveness within our engineering team. Enter the Engineering Career Framework. Instead of just copying someone else’s solution, we rolled up our sleeves and crafted our own unique framework to suit our particularities and needs. And now, we’re here to share some insights, hoping it might help other companies that are thinking of embarking on the same journey.
We want to hire amazing people and keep them happy and productive for as long as possible. To do that, we wanted to create a framework that satisfies these key goals:
We needed a system designed specifically for individual contributors on product engineering teams, as we still have a fairly flat hierarchy on the engineering management side. It also needed to be flexible enough to grow with us and embrace team differences as strengths. While we wanted to make assessments more objective than a purely manager-led process, we still wanted to leave room for personalized, manager-led adjustments. What we didn’t want is to have individual contributors feel like they’re assessed with a magic formula in a random spreadsheet.
Teams need a mix of technical and non-technical skills to succeed. Some of them are universal, while others depend on the team’s focus. We don’t see the career framework as a one-size-fits-all system: The importance of skills varies by team, which is reflected by the weight of these skills in evaluations, and this mix of skills and their weights defines the ideal state for each team. We want all team members to pursue skills with high weights, while lesser weighed skills could potentially be developed by fewer team members. This naturally incentivizes everyone to pursue skills that are impactful to both them individually and the team as a whole.
All this means that our levels have enough team-specificity to be difficult to compare between teams. For example, an L3 engineer on a visual SDK team can have a completely different skill set than an L3 engineer on a core technologies team. This specificity is thus reflected in their titles.
Our Skills Matrix models the career framework as a spreadsheet, outlining software engineering skills in rows and their progression in columns, from basic proficiency to full mastery.
Skills are divided into two sections:
Skills are then segmented into six levels (L1 to L6 — with 1 being the lowest and 6 being the highest), where each intersection of a skill (row) and level (column) contains a verbal description that illustrates some specifics of what a person should master at the given level. Team-specific skills may be rated more simply, on a separate scale from 1 to 6, without detailed descriptions.
As mentioned above, it was key for us to weigh skills by their importance to the team, hence each skill gets a “team importance score” from 1 to 5. We defined a somewhat universal starting point for the weights, and then we asked all the teams to make adjustments according to their needs.
Team leads are meant fill out the Skills Matrix, listing team members and their proficiency levels for each skill. The overall level is a weighted average of these skills, serving as input for the final level selection. We defined some formulas to help with the overall level calculation, however, team leads can also adjust this level based on additional factors, while providing comments for any discrepancies.
Since this was the first time introducing formalized levels in our engineering organization, we wanted to be extra sure to take enough time to do a thorough assessment with enough opportunities for feedback. Team leads created a skills matrix for each team member, which was then discussed with engineering management to get a second pair of eyes on the assessment.
These assessments were shared with team members, allowing them to prepare questions and draft objectives. One-on-one meetings addressed any open questions, reaching consensus on final objectives, which were then recorded in our HR system. New employees undergo their first Skills Matrix assessment after a three-month onboarding period, and we plan to do assessments on a yearly basis for all employees.
Team members set goals in collaboration with their managers, aiming to build specific skills and progress in the Skills Matrix. These goals are discussed in one-on-one meetings and recorded in the HR system. For example, here’s a hypothetical team of four individual contributors:
| Skill | Weight | Bob | Alice | Carol | Dan |
|---|---|---|---|---|---|
| Code Architecture | 5 | L5 | L5 | L3 | L2 |
| Project Management | 3 | L2 | L4 | L2 | L1 |
We can see that for this hypothetical team, code architecture is weighted more heavily, so we want to encourage everyone, especially Carol and Dan, to continue setting objectives to further that skill. While project management skills are important, the immediate focus is on code quality.
Bob already has good architecture skills, so for him, focusing on project management objectives makes more sense, given that we have only one other person on the team who is stronger on this front. For this team, it’s OK if not everyone in the team masters project management skills, so other skills should be considered as well. We also always want to factor in personal ambitions and career aspirations if those don’t go completely against the team needs.
What about Alice? She can certainly have other goals (the example above doesn’t include many other skills), but a team lead should consider that for other team members to learn, someone has to teach. So if Alice is happy to, she could set up goals to train others in the skills they need to improve.
As we wrap up the initial rollout of the Nutrient Engineering Career Framework, we want to look forward to what’s next. We’ve defined what it means to be a successful member of our engineering organization, established the Skills Matrix to guide development, and begun the process of setting meaningful goals. However, in the end, a framework is only as good as its implementation and improvement.
Moving forward, we still need to focus on some key points and challenges:
Defining an Engineering Career Framework is an important milestone in the growth of a software engineering company. We’re happy to have taken the first steps, and by staying forward-looking and committed to these principles, we aim to create an environment where every engineer at Nutrient can thrive.
Thank you for reading, and stay tuned for more updates as we continue to refine and enhance our Engineering Career Framework! Happy framework building!
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。