Establishing A Career Ladder By Involving Everyone
2 March, 2020
Chief Product Officer at Hired, DiverHERsity
When I joined Hired, we had a career ladder matrix that had some broad definitions. Typically, a career ladder ought to serve the purpose of helping an engineer grow into the next level and step in their career. They should even be able to understand the three to four levels above them so that they have clarity on what they should aspire for on the career ladder. Since engineers are highly analytical people, it is critical to be specific with the career ladder definitions. Without a properly defined career ladder, some significant problems can arise:
Engineers typically do understand what the role of an Engineering Manager, a Director, a VP, etc. entails as they usually see these people within their organization. However, if the only definitions and prototypes that exist are those of Engineering Management, then they may lead to the conclusion that the only way for them to grow is on the management track. This thinking leads to an abnormal number of engineers looking to become managers. Not everyone has the propensity to be a good manager, or even the desire to be one. Which is why it is critical to find ways to utilize everyone's capabilities. This refocusing helps them grow a career that celebrates and develops their strong suits.
Not having a well-defined career path for engineers either conveys the message that there is no growth path for engineers at the company; or that the company only grows people managers. Either message is unhealthy. There are no proper expectations established for engineers or management based on their titles. Job titles at different levels have very different expectations in terms of how much time they should be coding, designing, managing, or other tasks.
When career definition is poor, when making promotion decisions, subjectivity creeps into decision making, and as a result, titles often get inflated. Inflated titles improperly reflect the experience of the engineers. Misaligned titles were especially prevalent at Hired because a vast majority of the engineers had very senior titles despite them being fairly junior in terms of expertise.
Essentially, to summarize the problem, the broadly designed career ladder matrix at Hired led to a competitive group of engineers aiming to become managers who had limited experience, inflated titles, a misunderstanding of what they should be aspiring towards, and they did not know what the expectations were. These problems made the challenge of redefining the career ladder matrix a difficult one.
To solve this problem, we set about creating a career ladder, which meant coming up with new definitions.
I had a VP of engineering and a director volunteer to do the first draft. With input from a few members of the engineering team, they came up with the first draft. Following that first draft, the Engineering management team along with my HRBP, got together for multiple iterations of this draft. It was a long, lengthy process because coming up with these definitions is challenging.
Our first draft essentially defined the levels of progression at Hired and which we could compare to the industry. Part of this required us to ignore the career ladder matrix we currently had at Hired. We wanted to come up with a ladder the way it should be, keeping an eye towards the future. There would be a time to worry about what we do about the people currently in the org, but we decided to punt that problem to later.
Since we are a smaller organization, we wanted to make sure that there are not too many steps to climb the ladder. It is always a delicate balance in terms of an engineer being able to achieve the next level, but at the same time not requiring them to climb 20 levels. When it is harder to achieve or has too many titles, the ladder becomes meaningless.
Next, we needed to see how our new definitions would fit within the ecosystem of Hired. At Hired, we had internal HR levels, A, B, C, D, E, F, G, etc. We wanted to make sure that our levels and titles have parity with the rest of the company. As an example, we needed to make sure that if a level E outside of engineering was a senior manager or director level person, then we had the same title and expectations within Engineering.
Mapping this was painful because the existing levels also had compensation bands tied to them. We could not change HR levels (and hence change compensation), and if we did, we would likely create even more problems. With this, we again made a conscious and painful decision not to look at the population of people with certain levels. We made sure that we mapped our new titles to our HR levels and maintained parity across the rest of the company.
To validate that we maintained parity, I got the entire management team together, and I got feedback from my peers outside of engineering. We looked at people with specific titles outside of engineering to ensure that, from an expectation standpoint, we were asking the same of engineers.
Once we had alignment on the ladder, definitions, and how these titles mapped to HR levels, we opened this up for review. Members of the management team first reviewed this new ladder with a few key players within Engineering to get their feedback.
Now came time to determine how to map our existing engineers to this new ladder. Right out the gate, I had a strong point of view that we were not going to "demote" anyone, and since titles matched to comp bands, we were not going to reduce anyone's compensation. So the question became: how do we force-fit our existing engineering into these paths?
Furthermore, my preconceived notion was that the engineers did not want us to take titles away, either. My whole thing was, you do not take comp or titles away. As Hired continues to grow and hire, over time, we will achieve parity with this new ladder.
Much to our surprise, when we started talking to some of the key engineers, they were like, "I don't care if you're wiping the slate clean. One of the goals was for me to see the prototypes I should aspire to, but if we don't change the titles, then we are defeating the purpose of this exercise."
It took the longest time for me to budge. I felt that there must be the silent majority that was not telling us how they felt. Intuitively, I also knew that "demoting" someone can never feel good, and if we "wiped the slate clean," that would lead to a lot of unhappy folks. And of course, there was also the question of unfairness. All of a sudden, we had a new career ladder, and assigning everyone a new title based on this, felt very unfair. As a result, I stood my ground when we talked about title changes.
Given this, we decided to table the conversation and instead focus on making sure our definitions are correct. We sought out some of the key engineers and got their feedback. We also got feedback from others within the organization and outside the organization, which resulted in many iterations.
After the iterations, I held an all-hands to roll out the new ladder and explained to the engineers what was coming. Given the limitations of a large all hands, we could not cover every aspect of the ladder so we had to find another way to dive deeper. To do this, I had each manager sit down with their teams to review the ladder and help everyone get through the first wave of questions.
Each manager had one-hour meetings to go through the ladder definition and each level definition. We knew there would be some uncertainty with the team because we still had not answered the question of where the engineers fit into this. We were upfront about it. We told them we had not solved that yet, but we would.
We left the Google doc out for comments for about a month. During that month, anybody could put in any feedback. Of course, life is busy, and people forget, so we pinged people repeatedly once a week to get the teams involved.
At this point, it has been like a two to three-month exercise, and people were getting anxious because we used to do reviews every six months. People became apprehensive about this new benchmark and how evaluations would impact them during the next performance review. I assured them that if we got too close to the cycle, we would calibrate them on the previous benchmark, not the new benchmark.
Once we were locked and loaded on the new ladder, had buy-in from the engineers, they were ready to go. They were like, "So what do we do?"
I was still fighting the "good fight" and maintaining my stance of no-comp-or-title changes. This was until one of the engineers came up with the idea of doing a poll. They recommended we do an anonymous poll across the entire engineering team. I took comp changes off the table but agreed to do a poll on title changes. The question in the poll - “Do you want to get re-titled or not?”.
I was okay with this, as it seemed to be the logical next step. We have been at this impasse for a while, so a poll made sense.
To get full engagement, we bribed the engineers with pizza to complete the surveys, and it resulted in one hundred percent participation.
The results of the poll shocked me. Almost all of the engineers voted to be re-titled. I was shocked. Even though the engineers had voted for this, I was still very nervous. After all, how would it feel if one day you wake up and your title gets changed from "Architect" to "Sr Software Engineer"? I wanted to honor the team's wishes, but at the same time, I wanted to ensure that the change would be 1) fair; and 2) least disruptive.
To accomplish these goals, I came up with a compromise. We created individualized growth plans for every single engineer, which identified the gaps (if they existed) and what they can do to close those gaps. These plans helped the management team and leaders know what to do to help the engineers close those gaps. We gave them a year, and at the end of that year, if they have made it, then great. They got to keep their title or got promoted, as the case may be. And if they had not, they were re-titled.
This way, there was transparency, and we are not hiding away in a conference room making decisions for people. Engineers knew what they needed to do, and we have given them the time to do so, which worked out beautifully.
At the end of one year, we only had to re-title maybe two engineers. Outside of that, everybody grew into his or her titles, and some engineers got promoted, which was just amazing. I was elated at the outcome and had no issues with being wrong. I am happy with where we ended up because we finally had an organization where a level E engineer was truly operating at that level.
This whole process and journey helped me understand just how important it was to ensure that the engineers are a part of the process. Frequently a career ladder is a task of the management team and HR. They develop the matrix and then roll it out. The one major flaw is that the biggest impacted group has no input in the outcome.
In our case, engineers were part of the entire process, from soup to nuts. I think that was tremendously beneficial, not just in terms of having a smooth rollout, but also in terms of getting valuable input. For example, we would have never done a poll without input from the engineers.
Had we not done the poll, it would have defeated our primary goal of making sure that there were precise prototypes and role models for engineers to aspire towards in their careers. You cannot create organizational change unless you include and involve everyone affected.
I am a very goal-oriented person. I think articulating those two goals at the onset was very important because whenever we would veer off, we could go back to the target.
In this case, when the engineers said, "Hey, let's do a poll," it made sense. We are not just doing this exercise to appease the team; this exercise helped us meet the original goal that we had set for ourselves.
The other lesson I learned was to be open and honest. I have done many career ladders in my career. Re-titling is not the outcome I would have foreseen at all. I was surprised, shocked at the poll results, and very skeptical of it. Nevertheless, they opened my eyes, and when they did it, we had a great outcome.
Adam Surak, Director of Infrastructure and Security at Algolia, mandates that individuals contributors sell him on their decision to pursue management and what he’s looking for in the answers that they give.
Director of Infrastructure & Security at Algolia
Ian Langworth, CTO at Wilbur Labs, has had some defining moments in his career, and many of them have come as he utilized the resources around him. Without support, your career and personal growth may not grow at your desired pace. From an executive coach to books, Ian happily speaks on the value that these things can provide based on his transformational experiences with them.
CTO at Wilbur Labs
Ian Langworth, CTO at Wilbur Labs, utilizes his tech industry experience and exposure to help other founders and individuals with less familiarity solve problems and challenges they have faced or will face. Though he does not consider himself a thought leader, he understands that everyone has a level of value they can provide to the world. He happily shares this by getting involved in different communities. In this story, he discusses going from an engineer to a founder to helping people in online communities to assisting another founder in hiring an engineer for the first time.
CTO at Wilbur Labs
Chris Rude, Senior Engineering Manager at Stripe, talks about focusing engineers on core KPIs over the feeling of being a ‘hero’ and fixing ad-hoc problems.
Senior Engineering Manager at Stripe
Matt Nemenman, Director of Engineering at Lyft, shares how he relied on data to introduce strategic changes that challenged the company status quo.
Director of Engineering at Lyft