LW - Trust as a bottleneck to growing teams quickly by benkuhn

Link to original article

Welcome to The Nonlinear Library, where we use Text-to-Speech software to convert the best writing from the Rationalist and EA communities into audio. This is: Trust as a bottleneck to growing teams quickly, published by benkuhn on July 15, 2024 on LessWrong.
This is an adaptation of an internal doc I wrote for Anthropic.
I've been noticing recently that often, a big blocker to teams staying effective as they grow is trust.
"Alice doesn't trust Bob" makes Alice sound like the bad guy, but it's often completely appropriate for people not to trust each other in some areas:
One might have an active reason to expect someone to be bad at something. For example, recently I didn't fully trust two of my managers to set their teams' roadmaps… because they'd joined about a week ago and had barely gotten their laptops working. (Two months later, they're doing great!)
One might just not have data. For example, I haven't seen most of my direct reports deal with an underperforming team member yet, and this is a common blind spot for many managers, so I shouldn't assume that they will reliably be effective at this without support.
In general, if Alice is Bob's manager and is an authority on, say, prioritizing research directions, Bob is probably actively trying to build a good mental "Alice simulator" so that he can prioritize autonomously without checking in all the time. But his simulator might not be good yet, or Alice might not have verified that it's good enough. Trust comes from common knowledge of shared mental models, and that takes investment from both sides to build.
If low trust is sometimes appropriate, what's the problem? It's that trust is what lets collaboration scale. If I have a colleague I don't trust to (say) make good software design decisions, I'll have to review their designs much more carefully and ask them to make more thorough plans in advance.
If I have a report that I don't fully trust to handle underperforming team members, I'll have to manage them more granularly, digging into the details to understand what's going on and forming my own views about what should happen, and checking on the situation repeatedly to make sure it's heading in the right direction. That's a lot more work both for me, but also for my teammates who have to spend a bunch more time making their work "inspectable" in this way.
The benefits here are most obvious when work gets intense. For example, Anthropic had a recent crunch time during which one of our teams was under intense pressure to quickly debug a very tricky issue.
We were able to work on this dramatically more efficiently because the team (including most of the folks who joined the debugging effort from elsewhere) had high trust in each other's competence; at peak we had probably ~25 people working on related tasks, but we were mostly able to split them into independent workstreams where people just trusted the other stuff would get done.
In similar situations with a lower-mutual-trust team, I've seen things collapse into endless FUD and arguments about technical direction, leading to much slower forward progress.
Trust also becomes more important as the number of stakeholders increases. It's totally manageable for me to closely supervise a report dealing with an underperformer; it's a lot more costly and high-friction if, say, 5 senior managers need to do deep dives on a product decision. In an extreme case, I once saw an engineering team with a tight deadline choose to build something they thought was unnecessary, because getting the sign-off to cut scope would have taken longer than doing the work.
From the perspective of the organization as an information-processing entity, given the people and relationships that existed at the time, that might well have been the right call; but it does suggest that if they worked to build enough trust to make that kind of decision efficient enough to be worth it, they'd probably move much faster overall.
As you work with people for longer y...