Loading...

Creating and utilizing an engineering career path

Rob Slifka

VP of Engineering at Sharethrough

Loading...

Problem

In the early days of a startup, engineering growth is taken for granted. You're often experimenting with new technologies, solving novel problems and iterating heavily on products. As the team grows and the product matures, stability is introduced, things aren't as frantic, and the "obvious" growth vectors (new technology and frameworks every other month) are no longer present. People naturally have more time to think about themselves and their careers. In our fifth year, when our team had grown to 25 engineers, both our teams and product mix had stabilized, and engineers were entering into longer tenures (1.5-3 years), we realized our ad-hoc responses to "what's next?" weren't cutting it. We didn't have a consistent response to what engineering growth looked like, and we hadn't articulated our expectations of engineers at their current levels. In addition, people began pressing for title changes when they were not yet performing at a high enough level. Until we articulated our expectations, we were unable to have conversations around performance with our staff.

Actions Taken

First, we began by researching career paths and corresponding material that explained the reasoning behind decisions that other companies had used. We collected a dozen different paths, picking the facets of each that appealed to us. Features such as the categories (quantity and qualities?), descriptions (how verbose?), titles (how many?) and even communication style (how corporate is the language?) stood out to us. Next, we decided on an overall structure. There would be:

  • Six positions and titles, corresponding to Radford for ease of pay-scale mapping.
  • Four qualities per position, aligned with the number of company values.
  • One to three sentences per quality, which were descriptive enough to be used and not overly lengthy to be confusing. Two engineering managers worked on the path and developed it until it was about 60% done - enough to establish a basic structure and tone. Afterward, all five engineering managers met to finish developing it. Before rolling it out, we received three waves of feedback from our most mature and experienced engineers. Having your most senior people involved is a great way to get buy-in. They can't create the path for you, but they can fill in your blind spots and help communicate the value of your new system to others. We rolled out the path with a short presentation at an engineering all-hands meeting. The path has made our 1:1s and our 6-month feedback cycles much easier. It's also made hiring and selecting titles for people easier, as we now have a consistent set of expectations.

Lessons learned

  • Understand the problem you're solving: This is perhaps the most critical learning for us. Having a strong "why" ("Why are you creating this? Why is it important?") and "how" ("What would be true of any path we created?") were our guiding lights. Use your engineering team as your gut check - why is the management team spending time on this?
  • Find a starting point: This is largely a solved problem, and creating a path from scratch (if you haven't created one before) means you're ignoring the learnings of those who have both created and rolled them out many times in the past. Of course, don't copy a path, but feel free to use others as inspiration to get you started.
  • Avoid "Not Invented Here": This is similar to the point above. As a smaller company, you are likely to have a unique culture and approach to doing things, but don't let it go to your head. Yes, every company and team are unique, but I would not suggest starting with the idea that you need to create this from scratch. It's incredibly difficult to do so and when you're talking about people's careers, you want to have learned from those before you on how to approach growth.
  • Manager Training: Train managers in how to use the path, how often to talk about it in 1:1s, and how to tell if someone is ready for a promotion.
  • Engineering Training: Do the same for engineers, but from their perspective. Set expectations about how they should use the framework.
  • Work with HR: Keep them in the loop as you're going along. They'll ask great questions, such as whether a step along the path comes with a salary or equity increase, and how to include the path in your yearly feedback process.

Be notified about next articles from Rob Slifka

Rob Slifka

VP of Engineering at Sharethrough


Leadership DevelopmentCommunicationOrganizational StrategyFeedback TechniquesCareer GrowthCareer ProgressionSkill DevelopmentRoles & TitlesCompensation & BenefitsTraining & Mentorship

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


Product

HomeCircles1-on-1 MentorshipBountiesBecome a mentor

© 2024 Plato. All rights reserved

LoginSign up