The Team That Changed My Mind About "High Performance"
Three years ago, I took over a team that looked perfect on paper: 8 senior engineers, impressive resumes, fast delivery. But when I joined, people barely talked to each other. Code reviews were battles. Nobody wanted to admit when they were stuck.
Six months later, after we fixed the real problems, we were shipping 40% more features with way less drama. But here's the thing: The technical changes we made weren't the important part.
Let me share what actually worked.
It's Not About Coding Faster (Surprise!)
When I was a junior dev, I thought high-performing teams were just people who coded really fast. Write more features = better team, right?
Nope.
The best team I ever worked on? We spent an hour every sprint playing video games together. Sounds unproductive, but that hour meant people actually knew each other. Which meant when Sarah got stuck on a bug, she'd message the team chat instead of struggling alone for 3 days.
High performance isn't about individual speed—it's about team velocity. Big difference.
Psychological Safety (AKA "It's Safe to Admit You Messed Up")
Google did this famous study called Project Aristotle. Want to know the #1 thing that made teams successful? Not technical skills. Not experience. Not even team composition.
It was psychological safety—basically, can you admit you don't know something without people thinking you're incompetent?
Example from my team:
Last month, I deployed a change that broke our staging environment. Old me would've stayed late, fixed it quietly, pretended it never happened. New me? I posted in Slack: "Hey team, I broke staging. Here's what I did wrong and how I'm fixing it."
You know what happened? Two people said "I did the same thing last month!" and another person helped me fix it faster. Zero shame. Just problem-solving.
How to build this:
- Leaders go first: I started sharing my mistakes in standups. "Yesterday I spent 2 hours debugging before realizing I had the wrong branch checked out." People laughed. Then they started sharing too.
- Kill the blame game: When something breaks, ask "How do we prevent this?" not "Who did this?"
- Celebrate learning: We have a #TIL channel where people share "Today I Learned." It's become our most active channel.
Clear Goals (That People Actually Care About)
Here's a mistake I made as a new tech lead: I gave my team really specific tasks. "Update the UserService to use async/await." Done. "Add validation to the form." Done.
Know what we didn't do? Ship anything users cared about.
Now we use OKRs differently:
BAD OKR:
Objective: Update our tech stack
Key Result: Migrate 10 services to Node 18
GOOD OKR:
Objective: Make the app feel fast for users
Key Result: Reduce page load from 3s to 1s
Key Result: Achieve 99.9% uptime
The team figures out HOW. Maybe that means Node 18.
Maybe it means caching. Maybe something else.
We give them the goal, not the solution.Suddenly people are engaged. Why? Because they're solving problems, not just completing tasks.
Small Teams Are Better (Trust Me on This)
Amazon has this "two-pizza rule"—teams should be small enough to feed with two pizzas. Usually 6-8 people.
I learned this lesson painfully. We merged two teams into a 14-person team to "improve collaboration." Result? Meetings tripled. Decision-making slowed down. People felt less accountable.
We split back into two 7-person teams. Better meetings. Faster decisions. People knew everyone's name again.
Real talk: If your team is > 10 people, you're managing, not leading. And people spend more time coordinating than building.
Mix Junior, Mid, and Senior Engineers
Another mistake: I once tried to build a "senior only" team for a critical project. Sounds smart, right?
It was miserable. Everyone wanted to architect. Nobody wanted to write the boring CRUD code. Code reviews turned into philosophical debates about patterns.
Balanced teams work better:
- Junior engineers (20%): Bring fresh eyes, ask "why" questions, excited to learn
- Mid-level engineers (60%): Get stuff done, growing into leadership
- Senior engineers (20%): Mentoring, architecture, unblocking
Last month, a junior dev on my team asked "Why do we use Redux here?" Great question. Turned out we didn't need it anymore. We removed 300 lines of boilerplate because someone wasn't afraid to ask a "stupid" question.
Code Review Without the Drama
Early in my career, code reviews stressed me out. Senior devs would leave 50 comments. I'd take it personally. Feel dumb.
Now I teach my team a different approach:
"This is wrong."
"Have you considered using a Map here? Lookup would be O(1) instead of O(n)."
"Why didn't you add tests?"
"Could we add a test for the edge case where user is null?"
"Everyone knows you shouldn't do X."
"I typically avoid X because Y. What do you think?"We also use this rule: If it's not a bug or security issue, add "nit:" to the comment. Means "nice to have but not blocking." Cuts bikeshedding by 90%.
Protect Focus Time
Know what kills productivity? Meetings. Slack interruptions. "Got 5 minutes?" (it's never 5 minutes).
What we did:
- No Meeting Wednesdays: Entire team has 8 hours of uninterrupted coding time. It's sacred.
- Office hours: Instead of random interruptions, I have "office hours" 2-3pm where people can drop in. Otherwise, async Slack.
- Maker vs Manager schedule: Meetings only in afternoons. Mornings are for deep work.
Output increased 30% just from this. Not because people worked more. Because they worked without constant context switching.
Celebrate Wins (Seriously, Do This)
I used to think celebrating was cheesy. Ship feature → On to the next one.
Then I noticed: people were burning out. Work felt like a treadmill.
Now we celebrate everything:
- Friday Wins: Everyone shares one win from the week. Doesn't have to be big. "I finally understood closures!" counts.
- Ship Notifications: We have a #shipped channel. Every deploy gets a 🚢 emoji and a shoutout.
- Team Lunches: Hit a milestone? Team lunch. Simple but effective.
Cost? Basically nothing. Impact on morale? Huge.
What About Performance Reviews?
Real question I get: "How do you measure individual performance?"
Honestly? I don't obsess over it. Here's what I track:
- Are they growing? (Learning new things, taking on challenges)
- Do teammates want to work with them? (Collaboration > Solo genius)
- Do they deliver reliably? (Not fast—reliably)
- Are they raising the team's level? (Helping others, improving processes)
The "10x engineer" who writes tons of code but nobody can work with? Not high-performing. The mid-level dev who unblocks everyone and writes solid, tested code? High-performing.
When Teams Don't Click
Not gonna lie: Sometimes teams just don't gel. I've had teams where despite everything we tried, people didn't vibe.
What helped:
- 1-on-1s: Understanding what people actually care about. Sometimes someone just wants to work on frontend, and you've got them doing backend. Simple fix.
- Retrospectives that matter: We do "Start, Stop, Continue." What should we start doing? Stop doing? Continue doing? Then we actually implement the feedback.
- Sometimes people need to leave: And that's okay. Better a good departure than a miserable teammate.
For Junior Devs: How to Spot a High-Performing Team
If you're interviewing, here's what to look for:
- Do people interrupt each other in meetings? (Good teams listen)
- How do they talk about past projects? (Blame game or learning culture?)
- Do they have on-call rotations? (Shared responsibility > Hero culture)
- What happens when you ask "What's the biggest challenge?" (Honest answer or corporate speak?)
My Top 3 Lessons
- Psychological safety > Everything else. Smart people who don't trust each other ship slowly.
- Small, focused teams beat large ones. Always.
- Celebrate and recognize. People stay at companies where they feel valued, not where they code the most.
What You Can Do Monday
You don't need to be a manager to improve your team:
- Start a #TIL channel and share something you learned this week
- In your next code review, add one positive comment: "I really like how you structured this!"
- Admit when you're stuck instead of struggling alone for days
- Suggest a team lunch or coffee chat with no agenda
High-performing teams aren't built in a day. They're built in a thousand small moments where people choose collaboration over competition, learning over ego, and teams over individuals.
Start with one small change. See what happens.