This article is about how we designed from scratch the pillars for our Engineering team’s Career Path.
Our context
Understanding the context is fundamental to understanding why a technique or design decision makes sense in a concrete company and why not in another one.
Packlink’s engineering has experienced several cultural changes in less than a decade. A lot of talented people have worked here and contributed to the culture that we have at this moment in the company.
Our engineering team is a medium-size one if we think in terms of a European Startup. At the time I’m writing this, we are ~60 in tech (engineering, product and design). And, last year, we had a growth of ~40%.
All the team members have their bags full of technical and cultural experience. In general, at Packlink, we have people from different cultures and countries. This diversity carries different points of view and perspectives that are critical to success when new enormous challenges arise.
We have a strong learning culture; all the people have a voice in the teams. Our people have direct ownership of the hiring process. We are very exigent in terms of soft skills and technical aspects to ensure a good cultural fit.
We had a first career ladder where all the engineering roles and progression levels were listed hierarchically. This basic ladder fitted very well when the team was smaller. When we started to grow, and new people came to the team, we needed to improve how the expectations are defined in terms of soft and technical skills for every role in the ladder.
We needed a better understanding of what paths were available and how the engineers could grow through them.
In our culture, there is an influence of the holacracy concepts. For example, we had roles that could be assumed by different profiles without being part of the ladder. People can have multiple roles that change depending on the context, not all of them are part of their growing ladder.
As managers, we have the responsibility and the compromise to help the people grow and succeed in the company. The Career Path was one powerful tool that we needed to achieve this.
What is a Career Path and why do we (and probably you) need one?
The way that you progress in your work, either in one job or in a series of jobs.
— Cambridge Dictionary
When we talk about a Company’s Career Path, we are referring to the way we can progress and grow in a company.
Having a well planned and clear Career Path ensures talent retention by allowing people in the company to design their objectives to be improving and succeed at the company.
The Career Path is more than a simple ladder where a list of roles is defined at different levels and you need to be ascending through this hierarchy.
When you have a clear, well-defined path, you can ask for feedback to your workmates about concrete aspects that you know you need to improve to reach the next level in the ladder.
You can also have a personal career path but when you join a new company, you need to know what is their career path and how you can grow there.
The process
There is a lot written about the importance of a Career Path and the benefits of having one. Still, there are not so many on the experience of building one from scratch.
A career path is a tool that is directly relative to the culture and the context of a company. All the resources or public examples must be interpreted as ideas and not as a silver bullet that would fit in your context.
The goal
Having clear the theory of the advantages that a Career Path could bring to the teams and culture, we also must clarify the goals that we want to achieve. These goals served as orientation when we needed to make design decisions aligned with that.
Our main goal is to get a tool that can answer the three questions:
- Why do I have this role and how can I reach this other one?
- What is expected from my role at Packlink?
- How do my personal expectations in my career fit with my current role?
- What are my growing possibilities in this company?
These were frequent questions that people were asking us on the one on ones while planning the objectives to achieve during the year. We, as managers, had the same questions about our own growth.
Also, we were expecting these questions during the hiring interviews.
We had an initial understanding of what every role means in many aspects. Still, when we started to document them, we found that the challenge was much more enormous than what we expected.
What we didn’t want to the Career Path become
We didn’t want to have a tool that would be perceived as a contract. We want a tool that serves as a guide that helps people to reach their goals or see a specific direction.
Also, we didn’t want unfair goals or expectations. For example, although we want people to write articles and share knowledge and give talks in conferences because it is beneficial for our own growth and to our company in terms of hiring and presence in the community, it has not been added as part of the career path.
Not every personal situation permits traveling to conferences or giving talks and we think there are other options to achieve these goals.
Searching for references
Keeping in mind the goal above described, we searched for references that could serve us as examples. They allowed us to get an idea of how to start and understand better what scope and expectations should be covered by this tool and what others not.
We found many compelling examples:
- Medium. Their Growth Framework and their discontinued snowflake visualization tool were our first inspiration.
- Monzo. They have an exciting and clear Career Path where they mix the mastery and soft skills through different growth levels.
- CircleCI has also published their career path with CC Attribution
When you use a physical crafted or digital product, you probably only see the deliverable itself, the result. But this is only the tip of the iceberg. There are always some engineering design decisions made and a context that validate if this product is right for the people who need it.
The same thing happens with a public Career Path. There are many questions that they are designed to resolve. And the questions usually teach more than the final solutions.
The importance of the culture
When we start to design our career path we make some mistakes. It was May of the past year when we estimated having the first iteration to the end of the summer. After an entire year of work, we delivered it in May of this year.
Our first approach started listing in a Google Spreadsheet different skills that we find interesting for each role. Those were tagged with different categories like “communication”, “leadership”, “backend engineering”, “frontend engineering”, etc. Also, they were associated with one or more roles of the ladder as, for example, “senior engineer”, “staff engineer”, etc.
We soon realized that it was a mistake.
With this approach, we were stuck repeatedly with discussions that make us being far from the important ones for that phase of the project.
For example, we list hundreds of tech skills. Still, we could easily find another thousand interesting to add to the list. We were too predictive and too much concrete.
We were drawing the trees without knowing that we probably need a forest. And we were lost because we underestimate the relevant questions for designing the right Career Path.
We have clear why we want a career path and a goal, but we first need to ask ourselves some questions about our culture and our values.
What do we expect of a workmate in our engineering teams? What cultural pillars do we want to ensure? Are they aligned with our values?
So we reformulated the plan.
Step 1. We begin to define the growing categories and our values
Before to list all the possible skills that we think were important in our career path we list the main areas where those skills will be specified.
Some of those areas were “Communication”, “Leadership”, “Problem-solving” etc; we find a total of twelve areas at that moment.
After this exercise, we conceive those areas just like “categories”, simply taxonomies to group the skill units and expectations that we find interesting for people on the teams.
But we were wrong. These are not just “categories”, they became cultural pillars that serve as a base for the expectations that will define “what an Engineer should be at Packlink”.
When we understand this, we find some critical discussion topics. Those concerns were not just about the Career Path but the culture. The discussions were now much more transcendental and productive.
Thanks to them, we start having a better understanding of our culture, our “broken windows”, needs, and cultural debt. And we could work in some of them even without having completed the career path yet.
The discussion about aligning the growing areas and skills unit with the Packlink’s values comes recurrently and not always we were agreed with the value of doing that.
To evaluate how we could make this alignment possible, we started asking questions about our values. By Improving our understanding of them, we could start using them more seriously when we talk about the expectations of the company and teams with our workmates.
These are our company values:
Think big and make it happen
It doesn’t matter how big the challenge is, you think about how to achieve it even if this challenge seems impossible at first.
Be positive and drive change
If you find something that we can improve, you will lead the change with constancy and your best attitude.
Trust others and earn their trust
We trust our workmates.
Trust is not free; it is hard to earn and easy to lose. So every person in the company commits to doing their work at their best.
These values are the result of reflecting on the challenges faced by the company and its people. Their meaning is inspired by the skills, attitudes and qualities of those people.
We look for these in the people that currently work in the company.
Understanding the values, we made sure that the categories and the expectations were aligned with them.
The overall exercise was very productive and clarified the cultural rails that the career path stands on.
Step 2. A discussion about the Engineering growing areas
A doubt went along with us while we were defining the Career Path. Do we need a category for every tech specialization (like Backend, Fronted, Infrastructure, QA, Data, etc.), or we just need a single one for all the engineering teams?
Our final approach was having the major abstraction balance possible. For example, we have a category for software engineering and others for Data, Infrastructure, etc, because they have concrete expectation units that could be hard to abstract in order to be able to fit in a single Engineering category.
However, many skills expectations will be cross engineering areas like “Infrastructure as code mindset”, “cloud mindset”, “QA mindset”, “observability mindset” etc. To share them between specializations, we added a cross engineering category that lists them.
Although we take this decision, it comes with some advantages and some pitfalls. We think this is the best fit for our context. Other public Career Paths have growing categories per each technical specialization.
Step 3. Defining the skill expectations or what we called “KPIs”
Once the first growth categories were defined, we could then add the different expectations or skills that we need for each of them.
We created a Kanban board in Trello. Each growing category has a different column that will contain a list of expectations per skill.
For example, we have “Active listening” or “Ask for help when needed” in the “Communication” category or “Infrastructure as code mindset” in the “Common Engineering” column.
We refer to those “skill expectations” as KPIs and they need to be:
- Understandable: the different KPIs should be clear for all the people on the teams. Every KPI has examples that contextualize and make it clear the expectations of it.
- Measurable: how will you know that you are making progress.
- Fair: every KPI must be inclusive and reachable without heroic effort or extra hours outside of the Packlink work time.
With these rules, every person in the team can give feedback about them to another workmate.
Every KPI has a level associated with it and we have a total of five levels. However, some categories could have a smaller number of KPIs.
Because we see the Career Path as a guide and not as a contract or a competition tool, we don’t have any punctuation. There is not a punctuation matrix.
We find it very difficult and even toxic to introduce the concept of punctuation to a cultural skill.
We started to add KPis to every column based on the feedback or needs that we saw during the time we have worked at Packlink. We asynchronously did this work during some months and then we start to make sync meetings to align and unblock some doubts with some of them.
One of the workshops to align KPIs in the growing columns.
Finally, we reserve a couple of days and we work with the entire focus on this.
That was very productive and made easy the work that comes in the next months.
Step 4. How the engineering roles fit on the path
We have roles that build different steps in our Ladders. And we have different ladders depending on the area: Software Engineering, IT Help Desk, Technical Project Management, etc.
On the one hand, in every one of our ladders, there is a technical branch for people who want to focus on growing at technical aspects mainly. Also, they can grow as individual contributors while also growing as technical leads.
On the other hand, we have another branch for people that want to grow in management aspects.
Also, we have additional roles that are horizontal and are not part of a ladder. Some examples are the Architect role, the Technical Writer role, the Driver role (for initiatives, proposals or meetings), the Buddy role, and many others. These roles can be assumed by any person from the Engineering organization.
Thanks to the previous work detailing the cultural growing categories and the KPIs, we were capable of specifying the expectations of every role at the engineering team in a scalable way. We can achieve this, configuring what level of each growing category that is critical for that role.
For example, we expect that a Staff Engineer at Packlink to have excellent business knowledge, high software engineering skills, excellent communication, and some other skills. We define what level we want for this role in every growth category.
The expectations for this role are covered by the examples of every KPI that fits in that configuration.
Step 5. Visualizing the career path and the ladder.
To follow the progress, consulting the information and KPIs and design progression or performance objectives we are using some tools to visualize the Career Path.
We use Jira to document all the categories and KPIs, configured on a specific board, Confluence for describing the different ladders and custom tools to visualize the status of a person.
Lessons learned from this experience
- A Career Path is a tool to communicate expectations about growing in a company
- We need to understand the culture and values to get all the expectations on the table
- The roles will make sense after those expectations are defined
- Extract ideas from other companies’ Career Paths, but don’t use them as a silver bullet. You will need to adapt them to it.
- See the Career Path as a Product that needs to be evolved iteratively.
- Many decisions don’t necessarily be right or wrong; just take the adequate, test the response, get feedback from the leads and teams and iterate.
Conclusion
A Career Path is a critical tool for assuring the growth and success of the people in the company.
You can see it also as a communication tool for the expectations of your team’s culture.
We are looking for new workmates; you can check our opportunities at jobs.packlink.com.
The path to our Career Path was originally published in Packlink Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.
