Early in my career, I was working at a large financial services company in Boston. A friend of mine was assigned to a group set to work with an external consulting company brought in to take on a large project. At some point, my friend, who was a very productive engineer, was pulled aside by the head of the consulting company to have a discussion. The consultant told him the story of a worker at a hat factory. This worker was twice as productive as all the other workers. He was making two hats for every other worker's single hat. This was becoming more and more obvious, and it made all the other workers uncomfortable. One day, this productive worker was visited by a representative from the other workers. He said this: "I see and appreciate your enthusiasm for making hats, but you are making everyone else look bad. Here's a suggestion. Keep working as hard as you like, but for every second hat you make, open your desk and put in the hat you just made." At that, the consultant paused and looked at my friend, waiting for a response. My friend sat there for a moment to let the meaning of the story settle in, then stood up and said, "OK." From then on, my friend did just enough to match the others in the group, and the project lasted for a long time. This was the goal of the consulting company.
I've remembered this story at various times in my career, always in relation to some sort of consulting company being brought in to "help." But recently, I thought of the story from a different angle.
I wondered: do strong performers sometimes hide extra hats on their own, and if so, why?
For example, I've noticed that in some groups, performance can sometimes devolve to the lowest common denominator. Strong performers sometimes start to slow significantly after the introduction of new team members, some of whom are poor performers. Could the strong engineers be holding back hats in reaction to the behaviors of newer members in the group?
It seemed that way. Now, assuming they are slowing in reaction to the others, why would they?
I believe it is a combination of factors. I do believe that a strong performer will slow if they aren't rewarded in an appropriate fashion in comparison to a poor performer. I also believe that some team cultures overindex on ensuring that everyone on the team is treated and leveled the same. This attitude really manifests itself in what I've seen in Agile environments as what I call a "taking a ticket culture." Teams in these environments have curated backlogs and are set up with the assumption that anyone on the team can take on any ticket. With no difference in tickets and the assumption that all engineers are the same, this sets up an environment of "sameness" where poor performers are treated equally with strong performers.
With these factors in mind, a manager can work to improve things with a few tactics. One is to provide a runway for strong performers to move ahead. I've taken this approach with strong performers by taking them out of slow-moving teams and making them leads. This has provided a wider field for the individual, and they've taken on far more work than I suspect they would have if they were still on the team. Another approach is to start to break the ticket-taking culture and put more emphasis on engineers providing input on tickets and owning more of the process. Strong performers will typically perk up when given more scope and visibility. You may find that they were getting bored taking easy tickets with the rest of the team. When taking on this approach, make sure to coach strong performers during one-on-ones as to the importance of their role and how their increased performance is being noticed. Sometimes, this will help break the "sameness" environment up a bit.
In any case, if you notice degrading performance from your strong engineers, you should investigate. Talk to them, and if you don't get a direct answer, think about whether they may be slowing down for the team or others. Even if they aren't, the above tactics are bound to help drive engagement and better overall performance.