Your Team Is Only as Fast as Its Slowest Engineer

Table of contents

Open Table of contents

Joining the Team

When I joined the startup as Head of Engineering, I walked into a small, tight-knit team of six engineers.

They weren’t just colleagues - they were the original crew, battle-hardened by early startup struggles and bound by trust.

I admired their camaraderie and was determined to preserve it.

From day one, my philosophy was clear: loyalty matters. I believed in supporting the people who built the foundation, even if not all of them were what Silicon Valley might call “A-players”.

In the tech world, we’ve all heard the famous saying: “A players hire A players; B players hire C players”. Steve Jobs taught a generation this lesson.

The idea is that great engineers will recruit other great engineers, whereas mediocre ones might feel threatened and bring in weaker talent, causing a downwards spiral in quality.

I took that wisdom to heart during a frenzied year of hiring that grew our team from 6 to 17.

I strove to hire the best - people who were not only technically strong but also aligned with our culture. Yet I also felt a responsibility to the folks already on board.

These original team members had valuable domain knowledge and had stuck with the company through thick and thin. Wouldn’t a great leader find a way to elevate them rather than replace them? I set out to build the team without breaking the team.

In an ideal world, I thought, we could blend new “A-players” with our “OG-players” and have the best of both worlds. Steve Jobs himself, despite the “A-player” mantra, often emphasized the importance of teamwork and how ideas get polished through collaboration over time - building a great team, not just finding great individuals.

I was betting that with enough support, every one of my engineers could shine.

The Long Year

Over the next year, I invested heavily in coaching, mentorship, and candid feedback. I conducted weekly 1:1s focused not just on project updates but on growth and challenges. I organized lunch-and-learn sessions, paired programming with more seasoned new hires.

For a couple of legacy engineers who were visibly struggling to keep up with the fast pace set in the engineering organization, I tried to be candor. We identified courses they could take, I provided books for their growth and mindset change, and frequently discussed their career aspirations and gaps.

Recently I read Kim Scott’s Radical Candor and I like an idea of caring personally while challenging directly. And looking back I can say I tried to live up to that: I cared deeply about these engineers as people and made sure they knew it.

It wasn’t easy. It’s brutally hard to tell someone they’re not doing well, especially when you genuinely like them. I remembered Kim Scott’s story about Bob, the charming but poor-performing employee she kept on for too long out of misguided empathy. In the end, Bob was shocked and hurt when he was finally let go. Kim thought her silence made her “nice”, but in reality her empathy made her a ruinously bad boss.

I tried my best not to make that mistake. So I gave regular feedback. I wanted to ensure that if things didn’t work out, it wouldn’t be because I failed to warn them or provide support.

During this year, my belief in trust and second chances was tested. Some of the new hires - bright, fast-moving engineers - occasionally grew frustrated. They’d come to me with complaints like: “I keep having to redo parts of the code after X-engineer works on it” or “Our velocity is suffering because not everyone can pull their weight”.

I acknowledged their concerns and tried to balance them with my mission to uplift the whole team. I truly believed that with patience and effort, we could turn our “B-players” into solid “A-players”. After all, hadn’t these folks helped build the company before I joined? They deserved that investment. And for a while, it seemed to be helping - one of them improved his code quality and the other began contributing more to design discussions. I was hopeful.

The Breaking Point

However, in a startup, time is as scarce as trust. By the end of that year, despite all efforts, two engineers were still far behind their peers. The gap had become painfully evident. We’d given it our all – they had given it their all - yet critical tickets slipped through cracks, and the rest of the team was constantly on edge, bracing to pick up the slack.

I noticed something else: the morale of my high performers was waning. They were patient and kind to their teammates. I was running out of ways to shield the underperformers.

It hit me one day, that in the race we were running, our team could only move as fast as its slowest member.

We were living that reality. Our progress was governed not by how fast our top engineers could sprint, but by how far our slowest ones could crawl.

I had to face the hard truth: despite all the coaching and compassion, the situation wasn’t improving enough. In fact, by continually accommodating the chronic underperformance, I risked losing my true top performers.

Every month we delayed the tough call, the more frustration brewed and the more our delivery suffered.

And so, with a heavy heart, I made the hard decision: we had to let those two engineers go. I can’t divulge all the details out of respect for them. We’d had numerous prior conversations, performance improvement plans, clear warning signs - it was not a sudden ambush.

But still, on the day we ultimately parted ways, it felt awful. I went home that evening and didn’t sleep much. I kept second-guessing myself, imagining their faces, replaying every conversation leading up to it.

Am I a Bad Manager?

Next day, I was flooded with emotions and doubts. Did I try hard enough to help them? Should I have pushed them more? Or pushed them less and accepted their style? Letting someone go felt like I had failed my mission. One thought gnawed at me: “Does this make me a bad manager?”

I confided these feelings to a close friend (who is also an engineering leader). He reminded me that every senior leader goes through this gut-wrenching experience at some point.

Firing people - especially decent, likable people - hurts. It should hurt; if it doesn’t, something’s wrong with you.

The guilt and second-guessing can make you put off the conversation, convincing yourself to give just one more chance. But meanwhile, the team suffers and even your home life can get stressed by the weight of it.

I realized I wasn’t alone in this feeling. In fact, being torn up about it was a sign that I cared, and that’s not a bad thing. The question was, did caring and firing have to be mutually exclusive?

I revisited Radical Candor - the core idea is to care personally and challenge directly at the same time. If I only cared personally and never challenged, I’d fall into what Kim Scott calls “ruinous empathy”, where my desire to be liked actually harms the person and the team. Had I swung too far into that territory? Possibly. I gave a full year of chances, which in a fast-moving startup is quite generous. If I’m honest with myself, I probably knew by month 6 or 8 that it wasn’t working out, but I kept pushing the decision off, telling myself “let’s try one more cycle, maybe it’ll click”. I genuinely wanted them to succeed. But as one leadership coach put it, under-performers can seriously damage team productivity and morale, and sometimes the kindest thing you can do - for them and everyone - is to remove the source of the problem.

It’s counter-intuitive, but I had to learn that kindness and leadership aren’t always about saying “yes”.

How could letting someone go be kind?

After this experience, I understand. Keeping someone in a role where they are failing, unhappy, and a source of pain for the team isn’t kindness. It’s avoidance. By letting them go, we freed them to hopefully find a role that better fits their skills, and we freed the team to return to a healthier dynamic. I chose to believe that this decision, painful as it was, doesn’t make me a bad manager. If anything, avoiding the decision would have been worse management.

Building a Team

This journey also got me reflecting on the whole A-players versus B-players philosophy in the real world. Startups idolize the idea of the “10x engineer”, the superstar who can do the work of ten people. The Steve Jobs quote about A’s hiring A’s and B’s hiring C’s gets thrown around as gospel. And yes, there is truth in it - you do need to hire people who raise the bar. Each early hire in a small company has an outsized impact on culture and quality, so a weak hire can indeed propagate more weakness.

I was mindful of that; it’s why I worked so hard to bring in top talent during our growth spurt. There’s also a cautionary insight embedded in that saying: if you settle for “good enough” in your hiring, you risk a cascade where standards slip further and further.

However, the real world is nuanced. Startups face constraints - budget, talent pool, time - that sometimes force trade-offs. Not every hire will be a rockstar plucked from Google or Meta. And labeling people B or C players can be problematic if it creates a self-fulfilling low expectation.

I consciously avoided thinking of my team in such overly simplistic terms. Every person has strengths and weaknesses. One of my “underperformers” was actually an excellent mentor to junior devs and also had an important historical context about our legacy system. Those are qualities not captured by a blunt A/B label.

My approach, inspired by many leadership thinkers, has shifted to focus on building what one author calls “superteams” rather than just superstar individuals.

A superteam thrives on complementary strengths, knowledge sharing, and mutual growth. It recognizes that the team’s output is collective - in other words, the team is only as strong (or fast) as its weakest member. That means as a leader, you have a dual mandate: elevate the weaker links and keep strengthening the chain as a whole. In practical terms, it meant balancing my time between grooming the top performers (challenging them with growth opportunities so they don’t get bored) and coaching the ones who need more help. It also meant fostering a culture where peer support is valued - encouraging my rockstar engineers to mentor rather than banish the struggling ones. This, I hoped, would prevent an elitist “inner circle” mentality, which can be toxic.

Research shows that when employees suspect there’s a favored clique of high potential superstars, overall engagement drops and trust erodes.

I always communicated that we rise or fall as a team. We celebrate wins together and take responsibility for misses together.

That said, an important lesson I learned is that team culture cannot be an excuse to tolerate persistent under-performance. At the end of the day, preserving team morale sometimes means removing the element that is dragging it down.

One of my core beliefs now is that compassionate leadership involves making decisions that are best for everyone, not just one individual. Sometimes that individual will be me (like stepping back to let others lead), and sometimes it will be an employee who needs to find a role where they can truly thrive.

On A-Players Hiring A-Players

In hindsight, I still believe in hiring the very best people you can.

That principle is about respect for your team and your business. Great people want to work with other great people.

If you start making compromises and filling your ranks with C-players, your A-players will notice and may start to exit.

I’m proud that, over that year, we raised our hiring bar and brought in some phenomenal engineers. They, in turn, lifted our capabilities to new heights. And to be fair, some of our original team members rose to the challenge too.

At the same time, I have a more nuanced take on the Steve Jobs quote now. Yes, always aim for A-players on your team, but also aim to cultivate A-teams. An A-team is a group that knows how to work together, leverage each other’s strengths, and cover for each other’s weaknesses. It values trust and continuous learning. In such an environment, even a so-called B-player can turn into an A-player over time, because the team raises their game. But that only works if the person has the right attitude and capability to grow.

The two engineers we ultimately let go - I think about this a lot - could they have eventually grown into A-players? Perhaps, given infinite time and a different context. But startups don’t have infinite time, and not every context is right for every person.

Some might say I should have cut ties sooner. They’re not wrong. If I had to do it again, I might set a clearer timeline for improvement and stick to it, rather than continuously extending the runway out of hope and sympathy. Yet, part of me doesn’t truly regret giving them that year of effort. We tried our best. We parted with a sense of fairness. And the rest of the team saw that I don’t treat people as disposable - I am trying to exhaust every option before resorting to termination.

Closing Thoughts

This experience has been a humbling lesson in leadership. I learned that being an engineering leader isn’t just about shipping features or designing architectures - it’s deeply about people.

It’s about juggling compassion with performance, loyalty with logic, and heart with head.

I learned that trust in a team is paramount, but trust doesn’t mean turning a blind eye to problems; it means confronting them with honesty and empathy.

I also learned a lot about myself - about my conflict avoidance tendencies and how I need to catch them before I slip into ruinous empathy again.

Leadership sometimes requires embracing discomfort: whether it’s giving hard feedback or making personnel changes.

To my fellow engineering leaders and startup founders reading this – I offer this reassurance: you can care about people and still make hard decisions that seem unkind in the moment.

What matters is the how and the why. If you do it with respect, transparency, and as a last resort after exploring all other avenues, you’re likely doing the right thing.

Your team will understand, and in time, often even the person who was let go lands in a role better suited for them.

In the end, building an engineering team is about humans working together.

Strive to hire brilliant people, yes, but also strive to build an environment where everyone can do their best work.

Recognize when someone is holding the team back, and address it - first with help, and if necessary, with a change in role or company.

The “A-players hire A-players, B-players hire C-players” saying is a reminder to uphold high standards, but it doesn’t mean people are static labels.

The best leaders hire A’s, develop B’s into A’s when possible, and are willing to let people go with grace when it’s not working out.

It reinforced my belief that trust and accountability go hand in hand. I trust my team to give their best, and they trust me to ensure everyone is pulling in the same direction. That’s the kind of team I want to lead: one where we all feel responsible for each other, where we hire smart, coach hard, celebrate growth, and yes, where we have the courage to make the tough calls when all else fails.

To any leader out there facing a similar dilemma: I feel you. It’s tough. But remember, caring about your team sometimes means making choices that weigh on your heart. Leadership isn’t about being loved every day; it’s about earning your team’s respect by doing right by them as a whole. In the long run, that’s what sustains trust and excellence.

References