How to Explain the Skills Required to Get to the Next Level

Imagine you have an intermediate software engineer. Super hard working. Smart. Quick learner. Writes beautiful code. She’s reliable and one to depend on for tasks. Basically, she gets shit done.

One day, she mentions to you during your one-on-one that she wants to become a senior and wants to know how to get there. You get super excited and start to ramble on about how she’ll need to expand her sphere of influence to not only impact her own work but others’ work as well. She’ll need to help elevate the team’s skills and expand her leadership skills. She’ll need to speak up more. She’ll need to advocate better team practices etc.

For some software engineers, they’ll get it. They understand how to get there from just that conversation

For the majority though, they don’t quite understand how spending time explaining concepts to others, mentoring, crafting handbooks are more impactful than churning out features. Even if they do, it’s starting to sound like they’ll have to do things they don’t enjoy.

What I’ve found helpful is to explain to them the concept of additive vs multiplying contribution.

Individual work like completing tasks tends to be an additive contribution. The impact of that work tends to be an addition of a completed task or feature. Important work, no doubt but at a certain point, we need a software engineer to go beyond additive contribution and to think about creating multiplying contribution.

Commenting on pull requests, suggesting better ways to write code, mentoring others are multiplying contributions. When a software engineer teach one person a better way to do something, that person hopefully will in turn, teach others and that one contribution begins to multiply!

Giving a talk at the next town hall or conducting lunch and learns are other examples of multiplying contribution. We as managers, want to be able to see that one workshop is creating a positive, and multiplying impact on the team.

For example, are the team’s technical skill level improving as a result of the initiative? Is the team working better together as a result of something that was introduced? Is our code base so much easier to maintain and we’ve increased the team’s productivity because someone had refactored the code?

I often would recommend to intermediate software engineers to stand back and take a holistic view of their interests, skill sets and the needs of the engineering team and figure out 1-2 things they can start to create multiplying contributions.