I've been on a lot of teams. Some of them looked great on paper. Smart people. Good intentions. Modern stack. And somehow, every decision turned into a three-week debate that ended with everyone exhausted and no one satisfied. I've also been on teams that delivered value fast and consistently. The difference wasn't talent. It was something harder to define, and harder to build. I spent years assuming I'd figure it out eventually, that experience would make it obvious. It took longer than I expected. But I believe I can finally name it. The best teams I've worked with share four traits. The best teams I've worked with share four traits. Not methodologies. Not tools. Traits. Ways of being together that make everything else work. 1. They commit fully to decisions they disagree with You've heard "disagree and commit" before. I believe most teams get it wrong. They think it means: voice your objection, get outvoted, then quietly comply. That's not commitment. That's resignation. Real commitment looks different. It means putting your all your energy into an approach you wouldn't have chosen. It means actively trying to make it succeed, not waiting for it to fail so you can say "I told you so." I'll be honest: I've failed at this more times than I'd like to admit. Early in my career, I'd disagree with a decision, get overruled, and then just follow blindly. I wasn't sabotaging anything (at least not consciously), but I wasn't helping either. That's a terrible way to work. And it's a terrible way to be on a team. I watched an engineer do the opposite. Arguing passionately against an architectural change for weeks. Good arguments, valid concerns. The team decided to proceed anyway. What did he do? He became the biggest champion. He found edge cases the rest of us missed. Started looking at improvements to actively make the idea better, and started supporting it even more. From that point I understood disagree and commit. 2. They separate ideas from identity Here's a pattern I see constantly: someone proposes an approach, another person critiques it, and suddenly we're not talking about the approach anymore. We're talking about who's right or wrong, not what is right or wrong. who what High-performing teams have figured out how to argue about ideas without making it personal. They can say "I think this approach has problems" without anyone hearing "I think you're incompetent." This goes both ways. You need people who can give direct feedback without being cruel. And you need people who can receive direct feedback without feeling attacked. Neither skill is natural. Both can be learned. I'm still constantly learning them, if I'm being honest. The teams that figure this out move fast. The teams that don't spend half their energy managing emotions instead of solving problems. 3. They're pragmatic without being careless There's a certain kind of engineer who treats every decision like a thesis. Every choice needs to be the theoretically optimal solution, fully considered, perfectly designed and 17 confluence pages along side of it. There's another kind who just wants to ship something, anything, and deal with the consequences later. The best teams live in between these two. They care about doing things well, but they also understand that a good solution today beats a perfect solution next quarter. They also realize that everything has it's price. And that they might be building something that is not needed in 6 months. But (and this matters) pragmatic teams like this don't use "move fast" as an excuse for sloppy thinking. They make quick decisions, but informed ones. They cut scope, not corners. Finding that balance is hard. But the teams that find it tend to build things that actually get used, while keeping stakeholders and, most importantly, users happy. 4. They have informed captains Every decision needs an owner. Not a committee. Not "the team." One person. Netflix popularized the term informed captains, but the name doesn't matter. What matters is this: someone has the context, the authority, and the accountability to make the call. The key word is "informed". A captain who doesn't understand the problem is just a bottleneck. A captain who understands deeply can move fast because they don't need to ask for details or approval before every decision. To be clear, informed captains aren't dictators. They gather input. They listen to concerns. They genuinely consider alternatives (and I mean genuinely, not the kind where the decision was already made before the discussion started). But when it's time to decide, they decide. And the team commits. This only works if you've already built the first three traits. Commitment requires trust. Trust requires the ability to disagree without damage. And the captain needs pragmatic judgment to know when good enough is good enough. The uncomfortable truth None of this is a process you can implement. You can't mandate commitment. You can't enforce the separation of ideas from identity. These are cultural traits, and culture is built one interaction at a time. I used to think the answer was hiring - find the right people and everything clicks. But I've seen great individuals form dysfunctional teams, and average individuals form extraordinary ones. It's not about who's in the room. It's about what happens between them. That's the thing about these four traits. You don't notice them when they're present. Everything just works and you assume it's because the people are talented or the project is well-scoped. You only notice their absence - in the meetings that drag, the decisions that unravel, the slow bleeding of momentum that no retro seems to fix. I'm still learning how to build these types of teams. I suspect I always will be.

Netflix

What One Month of Writing in Public Taught Me

Checkout My Blog

Newsletter

The Best Engineering Teams Share These Four Traits

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Five Years Later: Clean Code Is Still Right (But Not Always Useful)

What Frontend Devs Want (From Backend Devs)

Solving Practical Puzzles: A Qualitative Look at Pair Programming Challenges

10 Common Product Management Mistakes that Could be Slowing Your Progress

The Noonification: How to Dockerize And Deploy Django Applications (10/14/2023)

1:1 with Alex Roetter: Leading Engineering at Twitter

Five Years Later: Clean Code Is Still Right (But Not Always Useful)

What Frontend Devs Want (From Backend Devs)

Solving Practical Puzzles: A Qualitative Look at Pair Programming Challenges

10 Common Product Management Mistakes that Could be Slowing Your Progress

The Noonification: How to Dockerize And Deploy Django Applications (10/14/2023)

1:1 with Alex Roetter: Leading Engineering at Twitter

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps