How to reward skilled coders with something other than people management

You have awesome engineers, and they want to advance in their career. Their team is growing because of advancements they've made, and you want to recognize the work they've done with something. The obvious answer is to put them in charge of the team they've built, especially as they're the de-facto leader of the team already. But is this what they want? Or just what they believe they're supposed to want? 

People Management Is A Different Skill

It's well known in the engineering world that engineers often will reach a technical peak, only to be asked to learn an entirely new set of skills, revolving around social and soft skills that they've spent the past chunk of their career probably ignoring. Building these skills involves a lot of trial and error, and above all, most of their time. Their time is now spent not coding, which is what they were originally rewarded for. Suddenly, they go from being good at their job to bad at it, which destroys confidence and job satisfaction. 

The problem here is that people management is a different skill than technical leadership. What you want is to reward someone with recognition that they are a thought leader, an exceptional performer- to make them an example of what others should strive to be. Everyone can't strive to be a manager, who would do the work? Additionally, you don't want to send the message that management, as a career, is somehow "better" than coding or anything else in the company, for that matter. 

What Is Technical Leadership?

Technical Leadership is composed of several aspects of purview over parts of job responsibility. Think about the day of a typical engineer- many decisions have to be made, problems have to be prioritized, solutions need to be found. Those are the fun parts of any engineer's job, and indeed all engineers must exercise some degree of technical leadership.

The rest of the job involves answering questions about how a thing you made works or doesn't work. Bugs need to be found and fixed. Documentation has to be written. Code has to be reviewed. Estimations must be made. Most of all, the longer an engineer remains at a company, the harder it is to find a few hours of isolation, free from interruption, to get work done. These parts, they are the worst parts of the job.

All of the fun work happens in these uninterrupted times, and these uninterrupted times happen only when your disappearance doesn't materially slow down someone else's work. Innovation happens when you have the bandwidth to hold the entire problem in your head- most of the time that takes a great deal of "load time" - research and contemplation about the problem. For introverts this means quiet, for extroverts this means dedicated time in a room of other people you work well with, thinking about the problem. 

So what gets in the way? Why can't exceptional engineers have more fun work, and have someone who is yet to be recognized do more of the less fun things? The key is in empowerment, and an engineer's ability to say "No". This isn't a function of courage, it's a function of empowerment - most exceptional engineers can't just let problems go unsolved, and if they feel responsible for a product or service, they end up chained to the project forever. Engineers often feel responsible for a project for the rest of its life, and this is exacerbated by the tendency for information to "silo" in one person, rather than distributing across a team.

How To Empower Your Technical Leaders

As a project grows, a technical leader might naturally accrue team members, and accidentally transform into a people manager. This is the biggest risk. The way to empower your technical leaders is to set expectations early and often, encouraging them to be clear about their ultimate goals, without sending the message that they will be less respected if they don't transition into people management. If their goal is to be the best programmer imaginable, or to create a system that scales to 10 million users, or to understand deep processes in the operating system, then finding ways to help them reach their goals is rewarding for everyone. 

Technical goals are easy to meet - there will be plenty of opportunities as a company grows to reward engineers with "fun" projects, and the ability to learn and grow as an engineer. Identify when someone will have to learn a lot for a role, these roles are rewarding and coveted. Also find opportunities to allow for professional development outside of your company, such as encouraging engineers to go to conferences and give talks, and become thought leaders in their field. Most engineers don't have an actionable plan for their own professional development, and so can benefit from advice on how to celebrate their accomplishments by putting them in a favorable position. This also will help you make the case for raises and bonuses, and will increase the esteem of your engineering department in general, which in turn attracts more talent. Seeing someone speak on something that interests them is the number one reason why mid-to-senior level engineers seek employment in an organization, rather than being recruited. Developing a strategy for positioning your technical thought leaders as the technical thought leaders is empowering, and it helps them empower themselves. 

The ability to say "No" is the second component of a technical leader - develop a strategy around handoffs. The objective here is to reward innovators by not chaining them to their innovations forever - it encourages those who create to continue creating. Junior developers are perfect to hand off smaller creations to, it helps them develop a sense of ownership without having to understand deeply the best practices that created the idea. Handoffs create opportunities in both directions- both for the person with more time, as well as the person accepting the responsibility. The incentives align well, but make sure there are expectations for the person receiving the responsibility- be honest about what it means for their career, and set up a strategy around them getting help with the project.

I came up with these ideas by helping Simple activate and reward their talent with things they actually want, rather than taking the obvious-but-wrong path. If you need help developing strategies for creating opportunities for your technical leaders, email me. I'm a consultant and I'm also an engineer myself, so I can provide insights into how to keep engineers happy and productive.

73 responses
Scott Barbian upvoted this post.
A posthaven user upvoted this post.
"Everyone can't strive to be a manager, who would do the work?" That makes no sense at all. "Everyone can't strive to be a teacher, who would be the student?" "Everyone can't strive to be a knowledge worker, who would collect the trash?" "many decisions have to be made, problems have to be prioritized, solutions need to be found. Those are the fun parts of any engineer's job" You're projecting again. You seem to have a preconceived notion of what an engineer ought to enjoy, and are building a narrative around that.
This is exactly the situation I'm in. My company uses a flat structure so there is literally no where to progress to, so I've decided to start project managing. A job that uses all of the skills I've been avoiding all this time.
@Francis There's a flaw in your comparison. "Everyone can't strive to be a teacher, who would be the student?" When a student becomes a teacher, they aren't removing any value from the class. Imagine a team of 3 engineers. If everyone of them wants to become a manager, then who will they be managing? Becoming a manager more often than not results in you contributing significantly less if not all to technical work. - Not Francis
Did anybody speak to Bobby Bizzler or his wife Miranda?
A posthaven user upvoted this post.
A problem can arise when 2 junior developers are working at the same level, one decides to be a "technical thought leader", and the other one becomes management. Now they both have moved to the next level, however 1 reports to the other
This article really resonated with me. Thanks for posting. I would love to find some more ways to reward technical leaders outside of management, though I love the idea of handoffs and speaking arrangements. I worked closely with the U.S. Military in the past and that organizational structure has had good success with the Warrant Officer career track. It' a way to promote specialists without saddling them with line management roles. Helo pilots for example are typically Warrant Officers. To implement effectively it would have to be more than just a title; it would have to be a career path. But it's a potential model to consider.
Hello, I'm wondering if I could see a reference for the following quote: "Seeing someone speak on something that interests them is the number one reason why mid-to-senior level engineers seek employment in an organization" thanks,
Being a developer and a manager I can agree the two skills are quite different. Technical aptitude is developed using a different part of your brain than leading people. Most of us in IT are quite analytical and this can lead to issues when working with departments that are more creative in nature i.e. Marketing or Sales. Even if someone doesn't want to lead I would suggest they work on their soft skills. Their career will definitely benefit.
Awesome post! I've just published a small article that follows a similar idea and someone pointed me to yours. ( I guess we have a pretty similar point of view :)
Let everyone know your view on what software helps you manage people
"Let everyone know your view on what software helps you manage people — Kevin Peter" We're working on a web-based tool that solves resource allocation conflicts while managing a multi-project environment. It's totally for you if you have a team of 10+ resources and have the feeling that you can improve output.
59 visitors upvoted this post.