Who of us hasn't heard this from some company, recruiter or executive:
"We only hire A-Players"
What does it mean? In this article, I will make some observations about this statement, with special emphasis on what it implies when hiring software engineers and other members of a high-end technology team. Specifically, I'll be looking at the implications when expanding software development teams in early stage companies that already have a core or founding team in place, and are now expanding after 2 to 6 years of operation.First, a Definition
Frankly, I've always been a bit confused by the etymology of this term. It seems to have its roots in sports, implying a "first string" player (as opposed to a "bench-warmer", I imagine). But I've read articles and blog posts that also speak in terms of "B" and "C" players, perhaps implying some relationship to academic letter grades. Or perhaps it refers to the way we grade a celebrity guest list, no one wants to be on the D-List!
Regardless of history and derivation, most would agree that an A-Player is one who has achieved not only mastery and experience in their field, but who also has the confidence, drive, leadership qualities and persistence to make things happen, even when odds are against them. Supremely confident, but without hubris, they naturally inspire the people around them. Others admire them and enjoy working with and learning from them. When a hiring manager speaks of desiring A-Players, they clearly want people who are well above average in virtually every area one might measure. But is this single definition appropriate in all cases?
This case study is fictional, but it is not entirely made up. Rather, it is an amalgam of real-life stories I've heard from colleagues, as told to me by the technical recruiters and software developers who lived them.
CoolTech.com is a software startup that is expanding their engineering team rapidly. They've been in business about 5 years and have had a popular product in the market for much of that time. They've just landed another round of funding and the CEO is saying this is the year that it will all come together. The core engineering team at CoolTech has been together almost from day one, and is led by one of the co-founders. They have a stated policy of making offers only to clear A-Players. Their interview process is rigorous, heavy on technology, cultural fit, and a drive to get things done no matter the odds.
Mary Smith is a software engineer with 12 years of experience. She graduated from a top-tier university and has a track record of start-up experience. Her references, both academic and professional, are impeccable. She is a contributor to a small but well-known open-source project and was the designer of several applications still available in their respective markets. Mary is a natural leader, focused and driven to succeed. She is looking for a role which will stretch her, while allowing her to apply her skills and contribute immediately. She likes CoolTech's strategy and technology, and knows she can make a difference there.
Mary is interviewing at CoolTech and doing very well. After the first three interviewers in a grueling 5 hour schedule, the team has switched from qualifying Mary to selling her on the merits of joining the CoolTech team. The co-founder and VP of Engineering has been brought in to seal the deal. He entices Mary with an overview of the new initiatives Cooltech has in the works and Mary is genuinely excited, as they seem to fit well with both her current skills and future interests. Before leaving the offices, Mary has a verbal arrangement in place, and by the next day, a signed offer. Mary is impressed with the offer, which includes a salary at the very top end of the scale and a generous equity package. She got along well with the people she met, but most importantly, she feels that the smart people there will challenge her and help take her career to the next level. It is easy for her to say yes to the offer.
Mary has been at Cooltech for a few weeks. She likes her co-workers and has been very busy learning the existing system. They have started her out working on improvements and defect resolution. Mary sees this as quite natural, though she is excited to move past it, as she knows that the core team is working on several new initiatives that look both challenging and interesting.
At six weeks, Mary is still working on incremental improvements to the system. The work is important, as sales are brisk and the customers are demanding. The company is growing and has plans for making many more engineering hires, but competition for top talent is fierce and hiring is slow. Mary has been helping to qualify and sell new candidates whenever she can. She has also been using her own time to keep up with the new technology she knows the core team is working on - she has offered to help out in areas that she can. Meanwhile, Mary is applying her leadership talent to her daily work and earning praise from those around her.
Mary and her manager talk about her career path in weekly one-on-ones. Her manager is extremely happy with Mary's work and with her work ethic. Despite this, it has been 3 months and Mary is continuing to find it difficult to break into the inner circle of the core team. Mary asks for more challenging projects to work on.
Four months have passed. Mary has been actively recruited since she started at CoolTech, but now she is beginning to listen. She wonders what else might be out there for her. It is difficult for her to consider leaving, as quitting in the face of tough odds is simply not in her DNA. Mary struggles a few weeks with tough decisions, and a short while later is attracted by an offer at MajorBreakthrough.com. Two weeks after that, Mary is gone.
The team at CoolTech wonders: What just happened?
It would be all too easy to say that CoolTech simply failed to challenge Mary and leave it at that. Perhaps they did not quite know what role they were trying to fill, and wound up bringing on an over-qualified candidate. It is possible, though unlikely, that Mary was a prima donna who wasn't willing to pay her dues doing maintenance programming.
The myth of the A-Player is at least partly to blame here. Popular wisdom has it that software companies compete for a talent pool that is much smaller than the demand. But do the ways some companies define A-Players make the available pool much smaller than it needs to be for a given role? Or worse, does it lead to the mismatching of candidates to certain roles?
Imagine any properly functioning society. There must be participants at all levels for it to succeed. Just as a society needs doctors to treat the sick and scientists to make breakthroughs, so it also needs bankers to handle commerce, plumbers to keep the water running and farm-workers to pick oranges and lettuce so everyone can eat. Any collection of humans working towards a common goal will exhibit a similar tendency towards specialization. In addition, once a certain population size is reached, is it realistic that everyone within it is above average? Is this even statistically possible? Or does the meaning of average merely reset around a new curve. Clearly the traits of a farm-worker and of a doctor are different. A software development team is nothing if not a collection of humans working towards a common goal. Is it possible that within the broader software development discipline, different roles require different traits as well? Common sense says of course it is, and if so, can we not have "A-Players" within each?
The popular mythos surrounding "Rock Star" software engineers makes for a captivating made-for-TV movie. The more mundane truth is, once a complex system has been in production for a while, attention must naturally turn towards keeping it functioning smoothly while moving it forward incrementally. Most such maintenance is characterized by comparatively small challenges requiring logic, problem solving, a can-do attitude and the ability to stick with a problem and not give up too easily. Major breakthroughs are rarely made fixing defects in production systems on tight deadlines, but rather in the quiet interstices between projects, in the innovation of dedicated R&D, or in the free-form analysis of the "pain points" of a current system or under served market. We can expect, and should foster, sudden flights of creativity from anyone at any time. It is just as clear that A-Players like Mary will naturally gravitate to and be happiest in roles that offer more opportunities to contribute at this rarified, strategic level. So who does the work of keeping an existing system running?
The solution lies in a more careful tailoring of the definition of "A-Player" to a particular job description coupled with an understanding of what roles are required on the team and when. If we look back at the case study, it becomes clear that, for better or worse, CoolTech already had the core engineering team handling the big-picture projects. What they really wanted and needed were people who could be entrusted with the important role of keeping the money-making systems running, thus freeing the core team to apply their creative abilities to those new initiatives. One could argue that hiring Mary for such a role, even had she not ultimately left the company, would have meant that they were wasting resources, if for no other reason than the higher salary and equity offered to entice her to join. In other words, CoolTech didn't just hire an over-qualified candidate, they overpaid for what they really needed as well.
As with many solutions to business problems, putting pencil to paper is a good the first step. We need to toss out our pre-conceived notions of what an A-Player software engineer looks like and start with what the actual needs of the team are. When building a team, it is helpful to create a matrix that matches a particular role with the distinct traits that would identify an "A-Player" within that role, all the while knowing that a top-performer in one role may or may not be qualified for another. We ignore titles at this stage and instead describe the role in terms of the job functions a person in that role will perform on a day-to-day basis.
Here is an example highlighting how I might go about this exercise for two imaginary roles from our case-study. One size does not fit all, so don't focus too much on how I've ranked the qualities of an "A-Player" for each role, adjust the concept for the needs of your company and team.
Under the supervision of the Engineering manager enhance major system components by implementing new features and resolving defects. Participate in the design and implementation of new features and components of existing systems. Provide technical expertise to product managers, support staff and other stakeholders. Help to improve the efficiency of the team and its infrastructure using automation, new methods or systems.
Under the supervision of the VP of Engineering design new products and new system components. Working with significant autonomy, provide technical leadership to team tasked with implementing the new systems. Working with executives and product managers, assist in developing product roadmap and future product strategy. Give presentations to audiences of various sizes on product technology and strategy; act as technical evangelist for company technologies and products.
Experience alone is not a general indicator of success in any role. It should always be used in conjunction with other traits. Some roles benefit greatly from having been through the "school of hard knocks" that experience provides.
The applicability of a candidates skills will depend upon factors such as the teams preferred technology stack. As used here, mastery refers to the level of skill attained in a technology, programming language, or the like.
People exhibit a wide range of communication skills. It can hardly be argued that a baseline for most technical roles is solid written communication skills. The ability to articulate ideas verbally, or to do so in front of large audiences may not be applicable to all roles equally.
|Written and Verbal|
|Advanced Written & Public Speaking||X|
The ability to think critically and untangle logical problems of various levels of complexity is critical for all technical roles. The ability to solve such problems in new or unusual ways (Creative); or to materialize entirely new products or services (Inventive) may be required if the role is highly strategic.
|Flights of Innovative Genius|
Tenacity is both the skill and the will to stick with a problem until it is solved. For particularly complex problems, refusing to give up can be a critical success factor. A person who occasionally needs another pair of eyes on an issue is usually capable of resolving most problems encountered in a technology setting.
|Needs occasional help||X|
|Will not give up||X|
Being a leader of other people is not for everyone and not everyone has a desire to lead. It is very important to assess a roles requirement for leadership traits. Placing a natural leader in a role where these skills go unused or worse, unneeded, sets that person up for dissatisfaction from the beginning.
|Skills need development||X|
|Skill and Desire||X|
But what about the egalitarian meritocracy?
Many early stage companies and software teams pride themselves on a flat hierarchy that values individual responsibility and contribution. Doesn't the notion of slotting people into specific roles within the team interfere with a purely merit-based environment?
Hiring for a particular role does not have to mean that a person in such a role has no lateral or upward potential. Conversely, the concept of the egalitarian meritocracy should not draw a false equivalence between every team members interests and capabilities. Finally, it does not mandate that all new hires enter on the same rung of the ladder and ascend from there. A restaurant that needs a chef does not hire a dishwasher to do that work. Nonetheless, it is quite interesting to note how many successful restaurateurs rose through the ranks from the comparatively lowly starting position of dishwasher!
No two companies are the same, no two people are the same, and one size does not fit all when placing people into roles within companies or teams. If this is true, then a single definition of A-Player is not sufficient to properly match people with the tasks that need to be executed. In this article, my objective is to get hiring managers to start thinking more carefully about what roles need filling for a given stage of their early-stage company's development. Tailoring your definition of an above-average candidate to the role you are trying to fill ensures that you will optimize the new hires chances for a long and successful career, while avoiding the problem of resource waste or retention problems that can occur when a new hire is not well matched to their role.