Your Team Doesn’t Need Well-Rounded Engineers. It Needs a Well-Rounded Team.
Most engineering managers follow a familiar routine during performance reviews. You meet with a team member, recognize some things they do…
Your Team Doesn’t Need Well-Rounded Engineers. It Needs a Well-Rounded Team.
Most engineering managers follow a familiar routine during performance reviews. You meet with a team member, recognize some things they do well, and then focus most of the conversation on what they need to improve. Even if you don’t mean to, it can feel like you’re telling them something is wrong and needs fixing.
I’ve led those reviews and written those development plans myself. Over time, I’ve realized this approach is actually backwards.
As an engineering manager, your goal isn’t to make every team member a well-rounded engineer. Instead, your job is to build a well-rounded team from people with different strengths.
Everyone Brings a Different Shape
If you’ve managed engineers for any length of time, you’ve noticed the patterns. Some people are incredible starters. They get excited at the beginning of a project. Whiteboarding, prototyping, exploring the problem space. They’re full of energy and ideas when the solution is ambiguous, and the path isn’t clear. But ask them to close out the last 10% of that same project, the edge cases, the documentation, the cleanup, and they’re suddenly dragging.
Other people are the opposite. Hand them a blank canvas, and they freeze. But give them a project that’s 70% done and needs to be shipped? They come alive. They’ll find every loose thread, close every ticket, write the runbook, and get it over the finish line with a level of care that the starters simply don’t have.
Some people are natural architects. They can step back, see the whole system, spot hidden complexity, and design solutions before any code is written. They might not be the fastest at getting things done, but they’re essential for making sure the team builds the right thing.
Then there are the executors. They prefer not to spend hours in design meetings. Instead, they want a clear problem, a well-defined ticket, and the time to write clean, thoughtful code. They’re the ones who turn ideas into reality.
Some people live for code review. They catch things no one else catches. They care about consistency, readability, and maintainability in ways that improve the entire codebase over time.
Every one of these profiles is valuable. And every one of them has weaknesses that come with the territory. The starter who can’t finish. The finisher who can’t start. The architect who can’t execute. The executor who doesn’t want to design. These aren’t flaws to fix. There are tradeoffs that come packaged with real strengths.
As a manager, your role is to see the big picture.
Stop Trying to Make Everyone the Same
The traditional performance review is built on an assumption: that every engineer should be working toward the same well-rounded profile. Strong at design, strong at execution, strong at communication, strong at mentoring, strong at project management. The review identifies where someone falls short of that ideal and builds a plan to close the gap.
But look at what that actually produces. You spend six months coaching your best systems thinker to be a faster executor. You spend a quarter pushing your most reliable closer to “take more initiative on new projects.” You invest time and energy trying to turn sharp, distinctive profiles into smooth, average ones.
At the end of it, you have a team of people who are pretty good at everything and exceptional at nothing. You’ve sanded down the very spikes that made each person valuable in the first place.
Gallup’s research is worth noting. They found that the most effective leaders aren’t well-rounded, and they don’t try to make their people well-rounded either. The best teams are well-rounded because they combine people with different strengths, not by making everyone the same. When leaders focus on strengths, engagement goes up eightfold. When they focus on fixing weaknesses, 40% of employees become disengaged.
Forty percent. That’s nearly half your team checking out, not because the work is boring, but because you’re asking them to spend their energy on the thing they’re worst at instead of the thing they’re best at.
See the Team as a System
Once you stop thinking about individual completeness and start thinking about team completeness, the whole picture shifts.
You begin to see your team like a coach sees a roster. You don’t need every player to play every position. You need the right mix of roles covered, with each person playing to their strengths.
That means mapping your team’s strengths honestly. Not their titles, not their levels, not their job descriptions, but their actual, demonstrated strengths. Who on your team would you want leading the initial investigation on a brand-new problem? Who do you trust to take a messy, half-done project and get it shipped? Who catches the architectural issues early? Who writes the cleanest code? Who’s the best at translating between your team and stakeholders?
Once you have that map, you can start making smarter decisions about how work gets assigned. Not everyone needs to be on every project from start to finish. The people who are energized by ambiguity can lead the discovery phase. When the direction is clear, and it’s time to build, you can bring in the executors. When it’s time to harden and ship, the closers take the lead.
This isn’t about creating rigid roles or boxing people in. People do their best work and are most engaged when they use their strengths. But at the same time, it’s important to encourage flexibility and growth. If someone wants to cross-train, try out new responsibilities, or develop new skills, make space for that. Supporting team adaptability and individual development is part of building a strong, resilient team.
The Conversations That Actually Matter
This calls for a different kind of conversation than most managers are used to. Instead of saying, “here are the areas where you need to improve,” ask a better question: what are you truly great at, and how can we help you do more of it?
That doesn’t mean ignoring weaknesses. But you look at them differently. I see weaknesses in three categories, and each needs a different response.
First, there are weaknesses that don’t matter. Your best architect is slow at cranking out pull requests. Your fastest coder doesn’t love writing design documents. If these weaknesses aren’t hurting the team, and someone else on the team covers that gap naturally, leave it alone. Don’t create a development goal around it just because it shows up as a gap on some rubric. The energy you’d spend making that person mediocre at their weakness is energy stolen from making them exceptional at their strength.
Second, there are weaknesses that are blocking someone’s strengths from landing. Maybe your most creative engineer has great ideas, but communicates them so poorly that no one listens. That’s a weakness worth addressing, not because communication is intrinsically important for every engineer, but because this specific weakness is preventing this specific strength from having an impact. Address it enough to unblock the strength. You don’t need them to become a keynote speaker. You need them to be clear enough that their ideas get heard.
Third, some weaknesses really hurt the team. If someone’s lack of attention to detail causes production issues, or if they can’t collaborate and create a toxic environment, that’s not something you can overlook. Some weaknesses have bigger consequences than strengths. Be honest about these and address them directly.
Not every weakness needs the same response. For most, it’s best to acknowledge them, work around them, and move on.
The Roster Mindset
Think about how you’d staff a project if you approached it like a coach preparing for a game.
You’ve got a new initiative coming. It’s ambiguous, the requirements aren’t fully formed, and there are significant technical unknowns. Who do you put on it first? Not your closers. Not your most detail-oriented code reviewers. You put your starters on it, the people who thrive in ambiguity, who can explore the problem space and come back with a direction.
Two weeks later, the direction is set, and the architecture is sketched out. Now you bring in the builders. The people who want clear, scoped work and the space to execute well. They turn the vision into code.
As the project gets close to completion, you bring in the closers. They find the edge cases, write the tests others skipped, update the documentation, and make sure everything ships smoothly.
Throughout the process, your reviewers make sure there’s quality, consistency, and maintainability.
No single person did all of these things well, but together, the team was excellent at every stage.
What About Growth?
A fair question is: aren’t you supposed to help people grow? If you never push someone out of their comfort zone, won’t they stagnate?
Yes, but growth doesn’t have to mean fixing weaknesses. Growth can mean going deeper into a strength. The engineer who’s great at system design can grow by tackling more complex systems, not by spending a quarter learning to write better status updates. The person who’s an incredible closer can grow by taking on larger, higher-stakes ship cycles, not by being forced to lead a brainstorming session.
There’s also a difference between someone who wants to develop a new skill and someone you’re forcing to develop one because a rubric says they should. If an engineer comes to you and says, “I want to get better at public speaking,” that’s great. Support them. But if they’re happy operating as your team’s most reliable executor and they’re producing excellent work, don’t manufacture a weakness to fix just because the performance framework expects it.
Some of the best engineers I’ve managed didn’t want to be well-rounded. They wanted to be world-class at one thing, and their teams were better because of it.
Having the Conversation
If this makes sense but seems hard to put into practice, start with one conversation. In your next one-on-one, ask each direct report two questions.
What part of your work gives you the most energy? What part drains you?
You might be surprised how many people have never been asked this directly. Most engineers know where they thrive, but no one has told them it’s okay to focus on it. School, performance reviews, and career ladders have taught them they need to be good at everything.
Let them know it’s okay not to be good at everything. Then do the harder work: change how your team operates so people spend more time using their strengths and less time struggling with their weaknesses.
This change won’t happen overnight. But shifting from “how do I make everyone well-rounded?” to “how do I make the team well-rounded?” is one of the most important mindset changes you can make as an engineering leader.
Your team is full of people who are brilliant at different things. Stop trying to make everyone great at the same things. Notice their strengths, combine them, and put people where they can succeed. The whole team will get better.
By Joshua McDonald on March 23, 2026.
Exported from Medium on August 26, 2026.
Reader discussion