Poor-Performing Individuals on a High-Performing Team

Before we get too deep into this particular subject, it’s important to note that not everybody on a high-performing team will always be a “10X programmer.” In fact, on any given high-performing team, you’ll see a wide range of skills. Merely being the slowest developer on the team does not indicate a poor performer, particularly if that individual provides valuable contributions in other ways.

People can contribute in lots of different ways. During his time on the Microsoft patterns & practices team, Ward Cunningham (the inventor of the “wiki”) was praised for his contributions that had nothing to do with code. It turns out that Ward has an uncanny ability. He can sit in a meeting, listening to groups having difficult discussions and saying nothing until the discussion reaches an impasse. When nobody can see a way forward, he’ll ask that one critical question that breaks the logjam and gets everybody moving again. That’s not a skill you pick up as part of a Computer Science degree or boot camp certificate, and it made him invaluable to the teams, regardless of what his code looked like.

Identifying your poor performers means finding those individuals who don’t struggle with just one part of the job, but with all parts of the job. They don’t deliver their code on time, their code is constantly incomplete or incorrect, they don’t communicate their current status well, and so on and so on. The people on your team who consistently underdeliver (and often, if they are seeking to compensate for their shortcomings, overpromise) are your poor performers.

Keep in mind, too, that this quality of “not everybody on your team will be a 10X Programmer” is the norm, not the exception, regardless of how much time, energy, or training you invest into them. Instead, the definition of a high-performing team is one in which the team feels comfortable with each other—they have that quality of psychological safety that I keep mentioning. That doesn’t mean you tolerate shirkers or slackers, but that you recognize that a team is more than just the sum of its parts. Be very reluctant to break up a team that is performing well unless you have a strong reason to believe that removing an individual will benefit the team—and not harm it.

The team knows, sometimes better than you do. A high-performing team knows each other pretty well, including strengths and weaknesses. When in doubt about somebody’s performance, ask other members of the team—they will often spot it quicker than you can. It’s just too hard to hide poor performance from teammates for very long. Asking this can be tricky, however—you don’t want to give your people the impression you’re looking for scapegoats or planning to fire whomever is “last.” Trying to obtain this feedback from the team is what has led to certain management practices like “360 reviews” during performance review time; in general, my personal preference is to rely on the one-on-one. Ask, “Hey, how’s the team? How’s Alfred? How’s Betty? What do you think I can or should be doing for them right now?” and listen carefully to the response. Assuming you get into the habit of asking this on a regular basis—and following up on any suggestions, as best you can—your team will grow to trust that when you’re asking, it’s because you genuinely want to strengthen the team.