Providing Career Planning and Advancement

Welcome back to Room to be Awesome! I hope all my Canadian readers had a great Victoria Day, and all my US readers are able to enjoy Memorial Day with their families.

In my previous post on building deep connections with your team, I discussed the need to provide opportunities as part of building a successful team. In this post, I want to talk about some ways to build a useful career planning and training component in an engineering team. Depending on the size of your team and your role, not all of these will be applicable, but hopefully it gives you a jumping off point.

Goals

Before going any further, it’s critical that you define what it is you want to achieve and understand the why. Many of these items might seem obviously beneficial, but without articulating a why for your career program, it will be hard to focus on what to do first. Without a why, it will also be harder to explain the program to get buy-in from others.

Try and define a way to measure success. Do you want to target retention? Maybe you’re going to target happiness and will use a survey to track progress. Internal promotions? What about overall code quality and limiting re-work? I’d encourage you to choose a single, measurable goal for your program before starting out.

In a recent position, I chose “Increase engineering retention to over 24 months” and after achieving that made a new goal, “Increase every team member’s level of excellence in getting shit done” (getting shit done was one of the company values). Notice how in the first example, you can measure the average tenure of employees easily. In the second example, you can review output metrics and level of rework over time.

Definitions

Now that you have a clear goal, it’s time to provide some clear definitions. When you’re a smaller company it’s more likely you have a loose definition of roles and responsibilities. If it’s too loose, differences between levels might end up seeming almost arbitrary. The first thing you’ll want to do for a learning and advancement program is clearly define your roles and levels.

I don’t feel a need to wax long on this element, there are amazing resources for this now, and I’d recommend looking at what other companies are doing and build a version of this for your team that meets your companies goals and values. Levels.fyi provides a high level view of the levels between large companies and expected salaries at those levels. Progression.fyi will share full career frameworks for companies, and can be a great source of inspiration. Lastly, Eric Elliot wrote an excellent article a few years ago on this topic and evaluating different options.

Defining what your roles are is critical to planning out how to communicate your program and support your team. In a very real way, just having clarity around roles and advancement itself can provide dramatic value to your team. If you don’t think you are the main decision maker, you should work with your senior management team to create clarity.

How deep you go in this process depends a lot on the size of your company and your company’s culture. If you’re only a few dozen people having detailed level documentation isn’t going to be as needed, and some general guidance is likely to do well (along with personal conversations with your team). As you grow, the documentation and detail around roles (including their responsibilities and authority) and advancement should also grow stronger.

Self-Directed Opportunities

The lowest barrier learning and advancement program you can set up with your team is one that’s self-directed. How much direction you’re able to provide here can scale up as you scale up the size of the overall team.

Start by making sure your more senior engineers and architects are coaching more junior engineers on your team, and make sure more junior engineers are getting an opportunity to pair with and get feedback from those more senior engineers. In a past role I experimented with having folks sign up for mentorship, but found most engineers didn’t take advantage. It worked out much better to rotate through assigned pairing relationships at a team level.

Another source of great self-directed opportunity can be suggesting reading for different areas of the code base. List out resources to learn all the tools being used across your whole application(s), so those who want to dig deeper have a starting place. This can also be a handy resource for those onboarding. Consider adding a way for engineers to show off their skills, either with a badging system that shows their areas of knowledge, or by letting folks show off their Hanker Rank scores internally.

Every company I’ve worked with has either already had a “books are free” policy or I quickly convinced them to add it. Let folks purchase and buy books on topics related to their areas of focus. If your budget is limited, you can always direct folks to the local library and buy requested books that they can’t find there. The local library here provides access to the O’Reilly Learning Platform, which is incredibly handy.

Sponsoring Opportunity

You can only go so far by providing self-directed opportunities without supplying a larger budgeted initiative around it. This is the point where having the clearly defined goal we talked about above will be critical to getting buy in and to ensuring your program is working.

In the context of software engineers, sponsoring those that want to achieve certifications can help not only skill-up your team, but can also help ease imposter syndrome. Reimbursing career-related certifications tends to not be super expensive, usually around $250, and can provide a lot of value to your team members.

In my past role at Thinkific, we had a fixed $2,000/yr education budget that could be used for certifications, books, courses, and training platforms. I overall like this approach, as it removes the need for someone to avoid asking to take a certification due to fear of being turned down.

Other options to support your team’s career progress include encouraging your senior engineers to present at developer events, with some time and cost reimbursement. On the flip side, if you’re large enough to support it, inviting experts on topics to speak to your team can also provide a lot of value. Ideally, also invite folks you’d like to hire to your company to attend as well, so it can dual-purpose as a recruiting event.

Keeping Your Promises

The last element to providing a valuable career program is to keep the explicit or implicit promises you’re making that as someone achieves progress in their career that their role, title and compensation will adapt to their new skill level. This is also where having your definition clear will help a ton.

In general, I’ve found it best to think of levels within a role as merit based and specialty roles as need based. So, being an Associate Developer, Developer, or Senior Developer is all based on the merit of your ability and your influence within the organization over a period of time. If during a review cycle, an Engineering Manager advocates for a team member to move from Associate Developer to Developer, and they can show the person is performing at that level, then the only limiting factor is the salary budget allocated to make that happen.

On the other hand, a role like Architect or even Staff Engineer requires there to be a need for that role. As such, those go into a hiring plan and then existing staff have the ability to apply for those roles. They aren’t automatically given.

Keeping your staff engaged with the needs and growth of your company, while also making sure to properly acknowledge their career growth and achievements, can be a challenge. It’s also an area I think there’s still a lot of room for learning and improvement on. I’d like to end by sending this out as a question. What have you found that works well to provide career and learning opportunities for your team?