In an early one-on-one, a wise manager asked me a question that has stuck with me ever since: 

On a scale of 1 to 5, where 1 is “not set up for success and struggling to get your work done”, and 5 is “well set up for success, an interesting but not overwhelming level of challenge”, where do you land?

This question was brilliant for a couple reasons. First, it gave me a non-judgmental language I could use to talk about my experience. A rating of 1 didn’t mean I was bad at my job – it meant I was struggling and needed help. And a 5 didn’t mean I was a perfect software engineer – it meant I was getting the support I needed and could continue to grow. Second, this question neatly lined us up toward the same goal: we both wanted me to be at the top of the ladder. Using this framework, I was able to explain that, while I happened to feel like a 4 that day, there were plenty of times I was down at a 2. We talked about what moved me up and down and what strategies I could use to more consistently hit 4s and 5s in my work life. With my new manager’s clear communication and support, the work stress I’d been muddling through diminished rapidly, making room for me to learn.

Years later, as a manager myself, I have grown quite fond of these kinds of rating ladders. Using this idea, I’ve built out a ladder for technical skill rating that I quite like. It gives a concrete framework for discussing technical level and growth, while keeping me and my report or mentee lined up toward the same goal.

I’ll give the full ladder below and will also go through some specific situations where you can use it in day-to-day work. I’ve framed these situations as led by a manager or mentor, but they’ll work just as well if you use them as an individual working towards your own growth.

Here’s the ladder:

Use Case 1: Goal Setting

When I work on goal-setting with my team, one of the most common types of goals that I hear is “I’d like to gain expertise in…” While this is a nice idea, it’s not a good goal. How do you know when you’re done? Say you want to gain expertise in Java, something I often hear from members of my team. Java is a huge and complex system with a vast number of libraries, tricks, gotchas, etc. Not only have you set yourself to a task that is effectively impossible to finish, it also has a steep drop-off of diminishing returns when applied to your actual day-to-day work.

Here is a framework for setting goals with a direct report or mentee using the skill ladder. Below, there is an example conversation that uses this framework.

• Identify a specific skill to discuss. Scoping down the conversation will make it more manageable and specific.
• Agree on the current rung. Make sure you are both on the same page about their starting level. This is also an opportunity to further clarify the specific skill you’re discussing and why it is important.
• Determine a mutual goal. Discuss what they want to accomplish with the skill. Know when they are being extra ambitious (e.g., aiming for a 5 when their job requires a 4) and call that out.
• Agree on specific next steps. Try to get concrete together – see my post on Climbing the Skill Ladder for some ideas on how to build up skills at each level.
• Schedule a specific next check-in. Too often, we forget about goals after they’re set. Scheduling a next check-in will help both of you remember the goal and its importance.

I’ll present a conversation I might have with a direct report who’s set an ambiguous goal of gaining expertise here using this framework. I imagine this conversation as part of a longer goals discussion.

Individual Contributor (IC): I’d also like to gain expertise in Java this half.

Engineering Manager (EM): Sounds good, but let’s try to get more specific using the rating ladder I just sent you. Take a sec to read through it and then – where do you see yourself now, and where do you want to be at the end of the half?

IC (after reading for a moment): Right now I think I’m between a 2 and a 3. I’d really like to be at a 5.

EM: To me a 5 in Java would mean you could design major changes to Java as a language. Is that what you mean?

IC: Oh, no… I want to be better at working in the Java codebase.

EM: Gotcha. So maybe there are really two different skills here that we could rate: your skills with Java as a language and your skills with our Java codebase. Do you want to pick one for goal-setting this half, or set a goal for each skill?

IC: I think both – I want to understand our codebase but also understand the language so I can help the team build best practices.

EM: That’s fantastic, that would help our team up-level the quality of our code. Let’s start with our codebase. Where are you at now and where would you like to get to?

IC: Well I guess for our codebase, I am at a 3. And I want to be at a 5.

EM: A 3 sounds right to me for your current skill level. I do think a 5 is still pretty ambitious – I think most of our fully onboarded engineers are at a 3 or 4, with a few of the most senior engineers on the team up toward a 5. It’s OK to set an ambitious goal as long as you’re doing it on purpose. Does a 5 still sound good?

IC: I’d really like to be more of a leader on the team, so I do want to try for a 5. But yeah, if I make it to a 4 that would still be good.

EM: Great, let’s put that down for the half, and next one-on-one when we look back over your goals we can talk about specific next steps for getting up to a 5. After you take a sec to write it in your goals document, let’s move on to talking about the language…

For ideas on how to talk about those specific steps for getting to a 5, check out the next post in the series.

Use Case 2: Struggling Mentee

When I first started managing engineers, I was terrified to start feedback conversations with my reports about their technical gaps. I knew stress and uncertainty makes learning harder, so how could I possibly bring up an area of improvement without impacting their confidence (and, ironically, making their learning process even harder)?

Since then, I’ve learned a lot about these conversations. Most of the time, when someone is struggling technically, they know it. In fact, it’s reasonably likely they’re afraid of someone else noticing. By calmly bringing the conversation out into the open, you can actually reduce their stress. Done well, these conversations can show your report that your reaction to their struggle is not anger or judgment—but is instead to give them support and help them build a plan for improvement.

The strategy I use for helping a struggling mentee is based on the framework above for goal-setting, but with a few specific areas of focus. As a reminder, here’s that framework:

• Identify a specific skill to discuss
• Agree on the current rung
• Determine a mutual goal
• Agree on specific next steps
• Schedule a specific next check-in

In the case of someone struggling, you may hit some snags as you work towards agreement on their current state. Someone who has challenges with confidence may under-rate their abilities, while someone behind on technical growth may be unaware of the learning ahead and over-rate their abilities. Spend time going over specific examples to drive to agreement before moving on.

When determining a mutual goal, make clear what is a baseline requirement of their job and what is a nice-to-have. What level do they need to achieve to be meeting the expectations of their role? What would a stretch goal look like and how would that impact their performance?

As in the goal-setting use case, your specific next steps need to be concrete. They also need to feel feasible. My favorite question at this phase of the process is “what do you think will be hard about that?” Give your mentee the space to talk about their fears and work together to break down the particularly scary-looking steps so that each piece is more approachable.

Just like in the goal-setting use case, these steps can be used independently instead of with a mentor or manager. If you’re struggling with confidence in your work, this can help you get away from universal statements like “I’m bad at my job” and towards specific and actionable statements like “I would be more impactful if I had a better understanding of the modeling in my team’s SQL database”.

Wrapping it up

I hope that you can take this ladder and apply it to the conversations you have with yourself and anyone you work with.

I’d love to hear anecdotes of this rating ladder working in your world. I’d also love to hear about times it didn’t work – was it the fundamentally wrong strategy for some problem you were facing? If you find ways to adjust this ladder to more different areas – maybe outside of tech work – I’d also love to know that!

If you want to read about the strategies that I believe are most effective between each rung of the ladder, read my post on Climbing the Skill Ladder.