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 you’ll naturally have more experience with each other and build more trust. So on most teams, these kinds of things work themselves out over time. But if you’re going through hypergrowth, then unless you’re very proactive about this, any given time most of your colleagues will have some sort of trust deficit.
Symptoms I sometimes notice that can indicate a buildup of trust deficits:
- Too many decisions needing to be escalated
- Too many decisions requiring deep involvement from many stakeholders
- People having lots of FUD about whether projects they’re not involved in are on track
- Leaders frequently needing to do “deep dives” on individual topics
- Leaders needing to spending most of their time working “in the system” (problem-solving specific issues) rather than “on the system” (unblocking future growth)
- Hiring more people doesn’t make you (much) less busy
It’s easy to notice these and think that the solution is for people to “just trust each other more.” There are some situations and personalities where that’s the right advice. But often it’s reasonable not to trust someone yet! In that case, a better tactic is to be more proactive about building trust. In a large, fast-growing company you’ll probably never get to the utopian ideal of full pairwise trust between everyone—it takes too long to build. But on the margin, more effort still helps a lot.
Some ways to invest more effort in trusting others that I’ve seen work well:
Share your most important mental models broadly. At Anthropic, Dario gives biweekly-ish “informal vision updates” (hour-long talks on important updates to parts of company strategy) that I think of as the canonical example of this. Just about everyone at Anthropic is trying to build an internal “Dario simulator” who they can consult when the real one is too busy (i.e. ~always). For high level strategy, these updates do an amazing job of that.
Put in time. In addition to one-way broadcasts, trust-building benefits a lot from one-on-one bidirectional communication so that you can get feedback on how well the other person is building the right models. This is one of the reasons I schedule lots of recurring 1:1s with peers in addition to my team. Offsites are also very helpful here.
Try people out. If you’re unsure whether someone on your team will be great at something, try giving them a trial task and monitoring how it’s going more closely than you would by default, to catch issues early. This is a great way to invest in your long-term ability to delegate things.
Give feedback. It’s easy to feel like something is “too minor” to give feedback on and let it slide, especially when there’s always too much to do. But I’ve never regretted erring on the side of giving feedback, and often regretted deciding to “deal with it” or keep quiet. One pro-tip here: if you feel anxious about giving someone negative feedback, consider whether you’ve given them enough positive feedback—which is a helpful buffer against people interpreting negative feedback as “you’re not doing well overall.”
Inspection forums, i.e., recurring meetings where leadership monitors the status of many projects by setting goals and tracking progress against them. The above tactics are mostly 1:1 or one-to-all, but sometimes you want to work with a small group and this is an efficient way of doing that.
To help other people trust you:
Accept that you start out with incomplete trust. When someone, say, tries to monitor my work more closely than I think is warranted, my initial reaction is to be defensive and ask them to trust me more. It takes effort to put myself into their shoes and remind myself that they probably don’t have a good enough model of me to trust me yet.
Overcommunicate status. This helps in two ways: first, it gives stakeholders more confidence that if something goes off the rails they’ll know quickly. And second, it gives them more data and helps them build a higher-fidelity model of how you operate.
Proactively own up when something isn’t going well. Arguably a special case of overcommunicating, but one that’s especially important to get right: if you can be relied on to ask for help when you need it, it’s a lot less risky for people to “try you out” on stuff at the edge of what they trust you on.
Related reading: Inspection and the limits of trust
Comments
Nice post!
FYI the link to “common knowledge” is broken, I get some extra backslashes when opening the link on Android.
Thanks, fixed!
I’ve come to think of trust as basically central to team success, with everything else either flowing from it or being blocked by a lack of it. I’m going to be glad to have this in my back pocket to send to people in the future.
Four other quick tactics I’d throw out that might be helpful food for thought:
I’ve found that the dreaded coffee meeting is actually really valuable in a large org. I used to think they were dumb until I noticed that the people I’d even met once were much more pleasant to deal with than the people I’d met zero times. (I now like the rule of trying to make my first interaction with someone not me asking them for something)
In addition to asking ‘are you giving enough positive feedback’ when dreading sharing feedback (which I think is great), another tactic I like is to express the intention of the feedback (“this is a small thing, but I wanted to mention it early so it doesn’t cause friction later”) and/or add some validation for the other person (so they know the feedback isn’t about how I feel about them, which I think is where it runs the risk of being particularly toxic)
It’s almost too obvious to say, but I think first/early impressions really do make a significant difference in trust building (the learning rate when meeting someone for the first time is high, so people make quick updates that are hard to overcome later) so it’s particularly useful to focus on being reliable/on time/etc. It also sets a good norm for the relationship going forward bidirectionally (I think people often end up with mini-rituals with respect to each other, based on how each person behaves, so using high-trust rituals early on can bake in good mini-rituals that are mutually beneficial.)
I’ve found the idea of transitive trust quite useful - in large orgs, it’s tough for NxN trust to take root, but making sure that leaders trust each other means that they can “imbue” their reports with trust in another part of the org (example: at Dropbox we often had friction between our infrastructure teams and our product eng teams. This was always tricky to deal with, but one thing that did help was building product+infra leaders’ trust in each other. This let the product eng leaders explain, e.g., the rationale of a seemingly annoying infrastructure decision to the product engineering team, and if there was real feedback to pass along from their teams, the infra leaders would also be more likely to accept it as legitimate feedback. This then meant that the two orgs as a whole had more mutual trust than if the leaders distrusted each other.)
Great post, really glad you decided to share it outside of Anthropic! I found the section on helping others to trust you especially valuable - it really resonated with me. A few ideas:
One incremental step in breaking down what it means for person A to trust person B could be: it means that, for a relevant situation, person A’s model of person B is highly confident that person B’s behavior will align with desired behavior (at some level).
Like you mentioned, making more data available is a good way to deal with a main bottleneck to building such a model. Extending this a bit further, if you think of this data as time series, two ways to increase the quantity are to increase the sampling frequency (e.g. share more frequent updates), or to increase the detailedness of each sample (e.g. share more information with each update).
Your analysis is also applicable to the process of building trust with AI agents / LLMs. The occasional hallucination completely crushes the trust building process, and this lack of trust limits the value of these agents. As the ability of AI agents to build trust improves, I expect that their value will grow massively.