In the video below, Pavel Durov talks about A players and B players. I couldn't agree more.

Durov starts with something that sounds wrong until you have lived it: firing an engineer can increase productivity. Two Android engineers are falling behind on the release schedule, so you assume you need a third. Then you notice one of them is constantly behind, complaining, not taking responsibility. You let that person go. A few weeks later, the team catches up. You never needed a third engineer. The problem was not capacity. The problem was one person creating more issues than they solved.

That is counterintuitive in software. We are trained to think that more people means more progress. Throw bodies at the problem and it will get solved. Durov's point, and Steve Jobs' before him, is that the opposite is often true. A B player does not just contribute less. They slow everyone else down.

The part that really lands for me is the demotivation angle. Everyone on a team can tell who is competent and who is not. It is visible in the questions people ask, in how quickly they understand a problem, in whether they can go deep on something without getting distracted. If you are an A player working next to someone who keeps lagging behind, you start to feel it. You are not able to do your best work. You are held back by someone who is pretending to work next to you.

Durov is careful here. He is not saying B players are lazy. Sometimes the intellectual ability just is not there. It is not about years of experience either. More often, he says, it comes down to natural ability and persistence. In most cases, it is simply the inability to focus on one task for a long stretch of time. Not everyone has that. For the people who do, working alongside someone who cannot go deep is genuinely frustrating.

I have seen this play out. A small team of strong engineers moves fast. Add one person who cannot keep up, and velocity does not just drop by one person's output. It drops for everyone. Code reviews take longer. Discussions go in circles. The people who care start to disengage. The best people are the first to leave.

Building a great team is not only about hiring A players. It is also about having the courage to remove the people who are slowing the team down. That is uncomfortable. It feels harsh. But keeping a B player on the team is harsher to everyone else who has to carry the weight.

Durov runs Telegram with roughly thirty engineers serving hundreds of millions of users. He hires through coding competitions instead of traditional interviews, looking for people who can actually perform under pressure. That is an extreme version of the same principle: find the people who can focus, who can go deep, who make the people around them better. Do not settle.

If you manage engineers, take this seriously. Before you open another headcount, ask whether the team is actually understaffed or whether one person is the bottleneck. Protect your A players. They are the ones who will build something worth having.