Skip to content

High on high potential—drunk on a fallacy

In “The Surgical Team” chapter of his 1975 classic book on software development, The Mythical Man-Month, Frederick P. Brooks, Jr., introduces the notion that there are engineers that write code ten times faster than average engineers, supported by data published by Communications of the ACM in January 1968. Since that time, these 10x coders have been sought by hiring managers and idolized by aspiring developers. Is that admiration warranted? Let’s focus on the many inherent differences between individual engineers. Some developers are adept at debugging. Others are eloquent in speaking or insightful in design. There are folks who code quickly and folks who code carefully. Some are calm and clear-headed in times of crisis. Others bring people together to resolve intractable conflicts.

Let’s assume all the different kinds of engineers I just mentioned can code. They passed through interviews and have gotten at least one promotion. Which are the 10x high-potential engineers? Should we fire the rest? We’re only in the second paragraph, and readers are likely split. There are folks who say, “Hey, don’t confuse the issue. There really are highly productive engineers who produce working code far faster than others.” And there are folks who say, “Yes, thank you. It takes all kinds of engineers to produce complex software for a wide variety of customers and use cases.” Who’s right? Both viewpoints are right. Who’s got misplaced priorities? That would be the people seduced by 10x coders.

What does high potential mean? Surely, it’s related to the potential impact on the business and our customers. But which skillset is going to have that impact? Experienced engineers know that more code and more features aren’t necessarily better. Instead, it’s the right word, the right idea, the right collaboration at the right time that wins the day. You can’t know in advance what those will be. Thus, every qualified engineer has high potential, not just those who are quick coders. What are the implications for hiring, career development, team building, and organizational design? Let’s break that down.

Eric Aside

For more on different types of engineers, read You’ve got coding style.

The right person for the job

Given that different people are talented in different ways, who should hiring managers hire? First, candidates should be qualified. For software engineering jobs, that means they can code and work well on a team (software is a team sport). After that, it depends on what your team needs.

Do you need fast coders? Hire them. Do you need careful coders with great design skills? Hire them. Do you need people with more customer focus or collaboration skills? Hire them. Do you need better alignment of plans, resolution of issues, robust builds and deployments, or leadership and mentorship? Hire people talented at those things. All those people have high potential to improve your team and its products. They’ll all 10x at something, and it takes a variety of skills to form a high-performing team.

As for those one-in-a-million magical developers who are brilliant at design, create mistake-free code as easily as they breathe, come up with game-changing ideas, and inspire greatness in others, those folks are also nice to have. They report to VPs and get paid like VPs—rightfully so. A business is lucky to have one of them, and many successful businesses have none. A business built around a single individual is not sustainable (more on that later).

Eric Aside

That 1968 Communications of the ACM paper differentiated productivity in multiple areas: time debugging, time compiling, time coding, program size, and run-time performance. Fred Brooks talked about the value of different skills and specialized roles in his chapter on “The Surgical Team.”

For more on selective hiring, read Hire’s remorse. For more on hiring a diverse team, read Growth mindset and diversity.

You’re the best around

When software engineers think about their own career development, they often focus on their programming speed, seeking to be one of those 10x coders. That’s a mistake. Yes, you should be able to write quality code in a timely fashion and work well with your teammates. Beyond that, you should focus on your unique strengths, not some fallacy about what’s important.

Human beings like comparing themselves to each other. We’re wired that way. Yet, you can pick one pertinent metric that ranks one of your teammates first and another pertinent metric that ranks that same person last. There is no universal ranking of people, even specialized folks like software engineers.

Instead, you should focus on enhancing and utilizing what makes you great while mitigating what holds you back. Your 10x skills are the things you do with ease that others struggle to accomplish and the things you enjoy doing that others can’t stand. Those skills set you apart, will have the highest impact, and will accelerate your career.

As for your weaknesses, do what’s necessary to mitigate them. If you’re forgetful or unfocused, keep a list and use a calendar. If you’re direct or annoying, admit to being direct or annoying and learn to shut your mouth and listen. If you’re slow and analytical, grab a role that values quality, architecture, and system thinking (since other engineers may hate all that analysis in advance).

Eric Aside

For more on measuring people, read How do you measure yourself? and More than a number—Productivity.

Look who’s come off the bench

A sustainable business needs a constant influx of varied talent and new leadership. People grow out of their assignments and move up or leave. Others must take their place. Since every individual is unique, no one is a perfect replacement for someone else.

So, teams and organizations are constantly changing. That’s good since technology, customers, and businesses are constantly changing. Thoughtful leaders embrace this change and plan for it. They continually hire diverse young talent. They promote previous hires into individual and team leadership roles. And they put succession plans in place for their most critical business roles (including for themselves).

Succession planning typically involves a bench program to develop the business leaders of the future. Bench programs are not for high-potential employees; every employee has high potential. Instead, bench programs are for fulfilling succession plans, preparing individuals to take on responsibilities and situations that are often beyond their experience. Some bench programs place employees in new roles that expand their views of the business as well as their skill sets. Others offer immersive training, simulations, coaching, or executive engagement. Regardless, bench programs are not about special employees and special treatment. They are about planning for sustainable leadership success.

Eric Aside

For more on the flow of talent on teams, read Go with the flow—Retention and turnover.

Every game it’s a different player

The notions of 10x coders, high-potential employees, and high-potential programs are misguided, misplaced, and mistaken. All qualified employees are 10x at something valuable to the business. All employees have high potential that you can’t know in advance. All employees should receive the guidance, mentorship, and opportunities they need to reach their potential.

Hire a diverse set of qualified candidates that fill gaps in your team’s ability to perform at its best. Instead of measuring yourself against your peers with some arbitrary, biased metric, focus on enhancing and utilizing your own 10x skills that your peers don’t have or don’t enjoy. Mitigate your weaknesses by keeping a list, creating calendar appointments, admitting to your faults, listening more while saying less, and reframing your weaknesses as strengths. Avoid homogeneity on your teams to ensure you have the right balance of skills to deliver great products as well as broad opportunities for growth. And as a leader, have succession plans and bench programs in place—not to single out high-potential individuals (everyone has high potential) but to ensure the continued success of the business by preparing new leaders.

The number of different people who can successfully fill any role is surprising. Certainly, there is a base level of competency, but the spectrum of candidates who meet that level is broad. Defaulting to any one measure, one skill, or one set of experiences is foolish and hurts the business. Instead, we should be open to a wide range of possibilities to fill gaps and provide new perspectives. That’s how innovation happens. The whole becomes greater than its parts.

Eric Aside

Special thanks to Bob Zasio and Jason Zions for reviewing the first draft of this month’s column.

Want personalized coaching on this topic or any other challenge? Schedule a free, confidential call. I provide one-on-one career coaching with an emphasis on underrepresented, midcareer software professionals. Find out more at Ally for Onlys in Tech.

Published inUncategorized

Be First to Comment

Your take?

This site uses Akismet to reduce spam. Learn how your comment data is processed.