Building High-Performing Teams: Insights from 1000+ Tech Interviews

A few years ago I watched a senior engineer sit through a forty-minute design review, nod along, and ship the plan he disagreed with. He'd seen the flaw in the first ten minutes — a cache invalidation path that would go stale under load. He told me afterward, in the hallway, not in the room. Three weeks later that exact path took down checkout during a traffic spike.

He wasn't incompetent. He was being careful. In the room were two people who'd argued him down before, and the cost of being wrong in front of them felt higher than the cost of staying quiet. That's the whole problem in one scene. The team had plenty of talent. What it didn't have was a room where the right objection was cheaper to say than to swallow.

I've conducted over 1,000 technical interviews across startups and enterprises, and led teams from a handful of engineers to a few dozen. The pattern that holds across all of it: high-performing teams aren't assembled from the best individual contributors. They're built around how disagreement, ownership, and standards actually behave under pressure — not how they read on a careers page.

Psychological safety is a measurable behavior, not a vibe

"Psychological safety" gets used as a synonym for being nice. It isn't. Niceness is often the opposite — a team that's relentlessly pleasant is usually a team where nobody risks the uncomfortable objection.

The behavior I actually look for is narrow and observable: will someone say "I don't know," "I was wrong," or "I think this is a mistake" to a more senior person, in front of others, without rehearsing it first? In interviews I probe for it directly. I'll describe a decision I made and ask the candidate where it's weak. The weak answers hedge — "it depends on context." The strong ones say "you'd lose data on a partial write here, wouldn't you?" and don't soften it.

You can't mandate this. You build it by what you reward in the first ninety days. The first time a junior engineer challenges your architecture and you say "good catch, you're right" in front of the team — that moment teaches more than any values doc. So does the opposite. The first time you get defensive, the room recalibrates and the objections move to the hallway, where they're useless to you.

This matters more, not less, in teams with strong hierarchical instincts. Where seniority carries heavy social weight, the default is deference, and deference is expensive precisely when stakes are high. You have to actively spend your authority to lower the cost of disagreement, repeatedly, until people believe it's real.

Ownership is what happens when no one is watching

The second predictor is ownership, and I mean something specific by it — not "responsibility" in the org-chart sense, but the instinct to care about the outcome past the boundary of the assigned ticket.

You see it in small tells. The engineer who notices the error rate ticked up after their deploy and rolls it back before anyone files a bug. The one who, asked to add a field, asks who else reads that table. In interviews I find it by asking about a project that shipped and then asking what broke afterward. People with ownership remember the aftermath in detail because they were watching it. People without it remember the launch and go vague on what happened next.

You can't hire ownership in and then starve it. It dies fast under two conditions: when people don't have enough context to make decisions, and when their decisions get overridden without explanation. Both are scaling problems. At 10 engineers everyone has context by osmosis. At 60 they don't, and if you haven't built the systems that distribute it, ownership collapses into ticket-completion — people optimize for the thing they can actually see, which is their own queue.

Standards have to be enforced by the system, not by you

The third leg is quality standards, and the trap here is thinking standards are about having high ones. Every team claims high standards. The question is what enforces them when you're not in the review.

Early on, you are the standard. You review everything, and quality tracks your attention. That doesn't scale — and the failure mode is sneaky, because it looks fine right up until it doesn't. Around 20–25 engineers you stop being able to read every meaningful change, and quality silently becomes whatever the least-careful path allows. If the only thing stopping a bad pattern is your eyes on the diff, the pattern ships the week you're on leave.

So standards have to move into the system: tests that fail the build, linters that aren't optional, a deploy that rolls back on its own when error budgets blow, a review norm that's enforced by peers rather than by the lead. The goal isn't perfection. It's that the cheap path and the correct path are the same path, so doing the right thing doesn't require heroics or your personal attention.

What works at 10 engineers breaks at 60

Most team-building advice is silent on size, which makes it useless, because nearly every technique is size-dependent. Here's the rough shape of where things break:

At 10, communication is free and you can hold the whole system in your head. The mistake at this stage is adding process you don't need yet — every premature ritual is overhead you'll pay daily for a problem you don't have.

Around 25, the lead-as-bottleneck breaks first. The fix isn't more of your time; it's distributing review authority and writing down the decisions that used to live in your head — not a wiki nobody reads, but the two or three architectural constraints that, if violated, cause real damage.

By 60, coordination overhead is the dominant cost. Communication paths grow roughly with the square of team size, and without clear decision owners, choices that took an afternoon at 10 engineers now drift for two weeks while five people want input. The single highest-leverage move here is naming who decides what, with timeboxes, so disagreement resolves instead of circling. I've written more on this in organizational design for product engineering and making architecture decisions that scale.

Hiring: technical skill is the floor, not the signal

Technical competence is table stakes — necessary, and almost never the thing that separates a good hire from a great one. The signal is in the three behaviors above, and you can interview for all of them.

For disagreement, I hand candidates a real decision and ask them to attack it. For ownership, I ask what broke after a launch and listen for whether they were still watching. For systems thinking, I give a scaling scenario — "this service is fine at current load; what's the first thing that falls over at 10x, and how would you know before users do?" — and watch whether they reason about failure modes or just recite caching and load balancing. The best candidates reason about how they'd detect the problem, not just how they'd fix it. They've been on call.

The one trait I weight heavily and most interview loops miss: can this person explain a hard technical idea to someone who doesn't share their context? It predicts who becomes a force multiplier. Engineers who can make the complex legible end up mentoring, aligning stakeholders, and pulling the team's average up — without a title change.

What to do Monday morning

• Pick the next design review and deliberately invite your own plan to be attacked. When someone lands a real objection, say so out loud, in the room. Watch whether the next objection comes faster.
• Find the one engineer who keeps things running that nobody else understands. That's not a strength of your team; it's a single point of failure. Schedule the knowledge transfer this week.
• Ask yourself: if you were out for two weeks, which quality standard would silently slip? That's the one that lives in your head and needs to move into the system — a test, a check, a peer norm.

Key takeaways

• The strongest predictor of team resilience is whether people will disagree with seniority in public, cheaply. Build it by what you reward in the first ninety days.
• Ownership is caring past the ticket boundary. It dies without context and without explained decisions — both of which are scaling problems.
• Standards must be enforced by the system, not your attention, because your attention doesn't scale past ~25 engineers.
• Almost every team-building technique is size-dependent. Match the intervention to where you actually are: 10, 25, or 60.

Your next step

Take your last production incident and ask one question: did anyone see it coming and not say so loudly enough? If the answer is yes — and it usually is — your problem isn't talent or tooling. It's the social cost of the objection, and that's the most fixable thing on this list.

Frequently asked questions

What's the single biggest predictor of a high-performing engineering team?

Whether engineers will voice disagreement and admit uncertainty in front of more senior people without social penalty. Across 1,000+ interviews and years of leading teams, that behavior predicts how a team handles a hard quarter better than aggregate technical skill does. The best objections are worthless if they only ever surface in the hallway.

How is psychological safety different from just being nice?

Niceness avoids friction; psychological safety makes the right friction cheap. A relentlessly pleasant team is often one where nobody risks the uncomfortable objection. The test is behavioral: will someone say "I think this is a mistake" to their lead, in a meeting, without rehearsing it first?

Why does team-building advice that worked early stop working as we grow?

Because almost every technique is size-dependent. At ~10 engineers context spreads by osmosis and the lead can review everything. Around 25 the lead stops being able to read every change. By 60 coordination overhead dominates and decisions stall without named owners. Advice that ignores team size will be wrong for most teams most of the time.

How do you interview for ownership?

Ask about a project that shipped, then ask what broke afterward. People with ownership remember the aftermath in detail because they were watching it. People without it remember the launch and go vague on what happened next.

How do you maintain code quality as the team scales?

Move enforcement out of your head and into the system: tests that fail the build, non-optional linters, automated rollback on error-budget breaches, peer-enforced review norms. If a bad pattern only gets caught by the lead reading the diff, it ships the week the lead is on leave. The aim is to make the correct path and the cheap path the same path.