Coaching Corner Volume 3

Welcome to Cameron's Coaching Corner, where we answer questions from readers about leadership, career, and software engineering.

In this week's post, we look at how Alan can help their engineer figure out what they want to be when they grow up.

Hey Cameron!

I have a front-end engineer who's sharp, but they're not sure what their career growth looks like. I get the sense that they're interested in other roles outside of software development. How do you navigate this and help them grow?

Oh man, I love working with these types of engineers, as you have no clue what they'll end up liking. I call these types Eevees because, just like the Pokemon, they need to be exposed to a bit of everything to truly figure out what they want to do.

What Do They Like and Dislike?

To begin, you need to figure out what they like. You mention front-end development, but what about that type of work sparks joy for them?

For example, if they enjoy working with customers to come up with clean designs, they might be interested in improving their User Experience skills and leveling up there.

On the other hand, if they enjoy building reusable components and clean code, they might enjoy learning about a different part of the stack (like API design) and see how their knowledge can be applied.

The main thing to note is that they might be interested in different roles (User Experience, Product Owner) or different parts of the technology stack (Front-end, Back-end, or DevOps), so I'd recommend keeping an open mind on possibilities.

Just as important as their likes, you need to know their dislikes. For example, if they enjoy seeing the visuals of their work, then they may not like learning about databases or DevOps, as those parts of the stack aren't client-facing by default.

What you're trying to do is thread a needle for opportunities that include some of their interests and stays away from their dislikes.

You've Got a Plan, What Next?

Excellent, you know where a possible interest may lie, but how do you get started?

If it's something you're an expert in or a role you're currently doing, have them shadow you and teach them what you're doing and the why. I've had success with this approach when engineers express interest in leadership. Once they have some experience, give them tasks to run solo with.

If it's something you're not an expert in, you need to find that person where you're at and get a mentorship started. It can be an introductory conversation followed by a job shadow, but it should evolve into the person taking on tasks themselves.

At this point, you want to see if the role could be a good fit. In the ideal world, your engineer would immediately know that it's not a good fit, so you can pivot to something else, but it will take time to figure that out.

During this time, you need to understand that they will be learning new skills, and their focus won't be on their current responsibilities. To help, I'd recommend setting about 20% of their time for learning/trying out the new role as this continues giving you the engineering effort needed but gives the other person a real opportunity to try it out.

Putting up Guardrails

Nice, we've got a mentor identified and ground rules established, so let's wrap up by defining some guard rails.

Like anything new, your engineer is going to mess up and fail. That's perfectly normal, and it should be embraced as learning. As such, you shouldn't give them mission critical tasks to take on at the beginning.

When I've done these experiments in the past, I've defined failure criteria, where if any of these things happen, the experiment immediately stops. This approach is similar to a futurespective, where we hypothesize scenarios that could cause us to fail and then plan responses for when that happens.

In this scenario, that could be things like:

The engineer doesn't feel comfortable doing the new tasks
A critical project is in jeopardy, and the engineer needs to focus on the project
There's a struggle with balancing the current responsibilities and the new tasks
Then mentor doesn't feel comfortable working with the engineer

Keep Trying!

Unless you have someone who is genuinely amenable to everything, there will be some failures and setbacks, and that's okay! Instead of thinking about it like Oh man, I messed up, think more along the lines of Hey, that didn't work because of X; let's try something else where X isn't involved.

For Harry Potter fans out there, it reminds me of the scene where Harry gets his first wand at Ollivander's Wand Shop:

Harry tried. And tried. He had no idea what Mr Ollivander was waiting for. The pile of tried wands was mounting higher and higher on the spindly chair, but the more wands Mr Ollivander pulled from the shelves, the happier he seemed to become.

"Tricky customer, eh? Not to worry, we'll find the perfect match here somewhere"

If you are upbeat about the process, this will make the other person feel at ease, increasing the odds of success!

Do you have a question about leadership, career, or software engineering? Would you like a different perspective on these topics? Drop a line at CoachingCorner@TheSoftwareMentor.com or you can fill out this form.