Your Team Is Only as Fast as Its Slowest Engineer

I joined the startup as Head of Engineering into a team of six. They weren’t just colleagues. They were the original crew - battle-hardened by early startup years and bound by trust.

I admired the camaraderie. I wanted to preserve it.

From day one, my position was simple. Loyalty matters. The people who built the foundation deserve support, even if not all of them match what Silicon Valley calls “A-players”.

You know the famous saying: A-players hire A-players. B-players hire C-players. The idea is that great engineers bring in other great engineers, while mediocre ones feel threatened and quietly lower the bar.

I took that to heart through a frenzied year of hiring that grew the team from 6 to 17.

I aimed for the best - technically strong, culturally aligned. I also felt a responsibility to the people already on board. They had real domain knowledge. They had stuck with the company through the hard seasons. Wouldn’t a good leader elevate them instead of replacing them?

I set out to build the team without breaking it.

In an ideal world, I thought, we’d blend new A-players with the original crew and get the best of both. Jobs himself, despite the A-player mantra, spent plenty of time on teamwork and how ideas improve through long collaboration. The goal was a team, not a collection of stars.

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

Table of contents

Open Table of contents

The Long Year

Over the next year, I invested in coaching, mentorship, direct feedback. Weekly 1:1s that weren’t just project updates but real conversations about growth and challenges. Lunch-and-learns. Pairing programming with the stronger new hires.

For a couple of legacy engineers visibly struggling with the pace, I tried to be candid. We picked courses together. I gave them books. We talked openly about their career aspirations and the gaps between where they were and where they wanted to be.

Somewhere in there I read Kim Scott’s Radical Candor. The core idea - care personally, challenge directly - stuck. Looking back, I tried to live by it. I cared deeply about these engineers as people and made sure they knew.

It’s brutally hard to tell someone they aren’t doing well, especially when you like them. I thought about Bob, the charming but poor-performing employee in Kim Scott’s book - the one she kept on too long out of misguided empathy. When he was finally let go, he was shocked and hurt. She’d thought her silence was kindness. It had actually made her a ruinously bad boss.

I didn’t want to make that mistake. I gave regular feedback. If things didn’t work out, I wanted it to not be because I failed to warn them.

The belief in trust and second chances got tested. Some of the new hires - bright, fast-moving - grew frustrated. “I keep having to redo parts of the code after X works on it”. “Our velocity suffers because not everyone pulls their weight”.

I acknowledged it. I also tried to balance it with the mission to lift the whole team. I told myself that with patience and effort, our B-players could become solid A-players. Hadn’t they helped build the company before I joined? They deserved the investment.

For a while it seemed to be working. One engineer’s code quality improved. Another started contributing more in design discussions. I was hopeful.

The Breaking Point

In a startup, time is as scarce as trust.

By the end of the year, despite all the effort, two engineers were still far behind their peers. The gap was painful. We’d given it our all. They’d given it their all. Critical tickets kept slipping. The rest of the team was constantly on edge, bracing to pick up the slack.

Something else I noticed: the morale of my high performers was eroding. They were patient. They were kind. I was running out of ways to shield the underperformers.

One day it hit me. In the race we were running, the team could only move as fast as its slowest member.

That was the reality. Our progress was governed not by how fast our top engineers could sprint, but by how far our slowest ones could crawl.

The hard truth - despite all the coaching and compassion, the situation wasn’t improving enough. And every month I delayed the tough call, more frustration built and our delivery suffered more.

With a heavy heart, I made the call. We had to let those two engineers go.

I can’t share the details, out of respect. We’d had many conversations before. Performance plans. Clear warning signs. It wasn’t an ambush.

But on the day we parted ways, it still felt awful. I went home that evening and didn’t sleep much. I kept replaying every conversation leading up to it.

Am I a Bad Manager?

The next day was flooded with doubts. Did I try hard enough? Should I have pushed them more? Or less and accepted their style? Letting someone go felt like I’d failed my mission.

One thought gnawed at me: does this make me a bad manager?

I confided in a close friend - also an engineering leader. He reminded me that every senior leader goes through this at some point. Firing people, especially decent, likable people, hurts. It should hurt. If it doesn’t, something’s wrong with you.

The guilt makes you put off the conversation. You convince yourself to give one more chance. Meanwhile the team suffers and the weight follows you home.

Being torn up about it was a sign that I cared. That’s not a bad thing. The real question: does caring and firing have to be mutually exclusive?

I went back to Radical Candor. Care personally and challenge directly - both at once. If I only cared personally and never challenged, I’d fall into what Kim Scott calls ruinous empathy, where the desire to be liked harms the person and the team.

Had I swung too far into that? Probably. A full year of chances is generous in a fast-moving startup. If I’m honest, I knew by month 6 or 8 that it wasn’t working. I kept extending, telling myself one more cycle might click. I genuinely wanted them to succeed. But underperformers can damage team productivity and morale and sometimes the kindest thing - for them and everyone - is to remove the source of the problem.

It’s counterintuitive, but I had to learn: kindness and leadership aren’t always about saying yes.

How could letting someone go be kind?

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 find a role that fit. We freed the team to return to a healthier dynamic. The decision, painful as it was, didn’t make me a bad manager. Avoiding it would have.

Building a Team

This also made me reconsider the A-players-versus-B-players philosophy.

Startups idolize the 10x engineer, the superstar who supposedly does the work of ten. The Jobs quote gets thrown around as gospel. There’s truth in it - you need to hire people who raise the bar. Each early hire in a small company has outsized impact on culture and quality. A weak hire propagates more weakness.

I was mindful of that. It’s why I worked so hard to bring in top talent during the growth spurt. The cautionary insight in the saying is real: settle for “good enough” once and standards start to slip.

The real world is messier, though. Startups have constraints - budget, talent pool, time. Not every hire is a rockstar plucked from a top-tier company. And labeling people as B or C players becomes its own problem if it produces self-fulfilling expectations.

I avoided thinking of my team in those terms. Every person has strengths and weaknesses. One of my “underperformers” was an excellent mentor to junior devs and had irreplaceable context about our legacy system. That’s not captured by a blunt A/B label.

The shift I’ve made is toward building superteams, not collecting superstars. A superteam runs on complementary strengths, knowledge sharing and mutual growth. The team’s output is collective - it’s only as strong or as fast, as its weakest link.

That gives a leader a dual mandate. Elevate the weaker links. Keep strengthening the chain as a whole.

In practice, it meant splitting my time - giving top performers growth opportunities so they didn’t get bored and coaching the ones who needed more help. It meant building a culture where senior engineers mentored their peers instead of banishing the struggling ones. Otherwise, you end up with an elitist inner circle and the engagement survey tells you the damage.

I always communicated that we rise or fall as a team. Wins together. Misses together.

But team culture can’t be an excuse to tolerate persistent underperformance. Sometimes preserving the team’s morale means removing the element dragging it down.

On A-Players Hiring A-Players

I still believe in hiring the best people you can.

It’s a question of respect - for your team and for your business. Great people want to work with other great people. Fill your ranks with C-players and the A-players will notice and start to leave.

Over that year, we raised the bar and brought in phenomenal engineers. They lifted the rest of us. Some of the original team rose with them.

My view of the Jobs quote is more nuanced now. Aim for A-players, yes - but also aim for A-teams. An A-team knows how to work together, leverage each other’s strengths, cover each other’s weaknesses. In that environment a so-called B-player can grow into an A-player because the team lifts them. That only works if the person has the attitude and capability to grow.

The two engineers we let go - could they have eventually grown into A-players? Maybe, given infinite time and a different context. Startups don’t have infinite time and not every context fits every person.

Some would say I should have cut ties sooner. They’re not wrong. If I did it again, I’d set a clear improvement timeline and hold to it, rather than extending the runway on hope. Still, I don’t fully regret the year of effort. We tried. We parted with a sense of fairness. And the rest of the team saw that I don’t treat people as disposable - I try to exhaust every option before ending it.

Closing Thoughts

This was a humbling lesson in leadership. Being an engineering leader isn’t mostly about shipping features or designing architectures. It’s about people.

Trust in a team is paramount. Trust doesn’t mean turning a blind eye to problems - it means confronting them with honesty and empathy.

I also learned about my own conflict avoidance. I need to catch it before it slips into ruinous empathy again.

Leadership sometimes requires discomfort. Hard feedback. Personnel changes.

To fellow engineering leaders: you can care about people and still make decisions that look unkind in the moment. What matters is the how and the why. Done with respect, transparency and as a last resort after exploring alternatives, you’re likely doing the right thing. Your team will understand. Often even the person who was let go lands somewhere that fits them better.

Building an engineering team is humans working together. Hire brilliant people. 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.

The A-players-hire-A-players saying is a reminder to hold the bar. It isn’t a claim that people are static labels. The best leaders hire A’s, develop B’s into A’s when possible and let people go with grace when it isn’t working.

Trust and accountability go together. I trust my team to give their best. They trust me to keep everyone pulling in the same direction. That’s the kind of team I want to lead - one where we’re responsible for each other, where we hire smart, coach hard, celebrate growth and have the courage to make the tough calls when all else fails.

Leadership isn’t about being loved every day. It’s about earning your team’s respect by doing right by them as a whole.

References