Trust inside teams is not built through grand declarations. It grows in the quiet, repeated moments where individuals take risks – proposing ideas, admitting uncertainties, asking for help – and where those risks are met with respect rather than judgment. Pull requests are one of those moments.

Amy Edmondson, who formally introduced and studied the concept of psychological safety in teams, defines it as the shared belief that a group is safe for interpersonal risk-taking. In environments where psychological safety is strong, individuals feel free to share unfinished work, voice doubts, and ask for feedback without fear of humiliation or retaliation.

Submitting a pull request fits squarely into this model. It is an act of vulnerability: exposing your assumptions, logic, and blind spots to others, trusting that your teammates will engage thoughtfully rather than punitively. The way a team handles pull requests is not just a technical process. It is a visible, repeated signal of whether trust and learning are truly valued.

How Trust is Built – or Broken – Through Pull Requests

Clarity and Scope

A clear pull request respects the reviewer’s time and sets the stage for useful collaboration.
It does more than describe what changed – it explains why the change matters, and how it fits into the broader context. When possible, connecting a pull request to existing issues or discussions helps maintain a clear project history and reduces duplicated work.

The size and focus of a pull request also matter.
Cognitive Load Theory, developed by John Sweller, shows that working memory has a limited capacity. When individuals are asked to process too much novel information at once, the quality of their decision-making and learning degrades. Small, tightly scoped pull requests help reviewers stay focused, spot important details, and contribute meaningfully without being overwhelmed.

When authors make the effort to write clear, scoped pull requests, they reduce friction for everyone – and signal that they value the attention and time of their teammates.

Timely Reviews

Trust is reciprocal. If submitting a pull request is an act of vulnerability, responding to it promptly is an act of respect.

When reviews are delayed, the cost is not just technical – though stale branches, merge conflicts, and rework often follow. The deeper cost is psychological: contributors start to question whether their work is valued, or whether collaboration will happen at all.

Timely reviews maintain momentum, keep changes relevant to the evolving trunk, and reinforce the idea that participation is worthwhile. They show authors: your work matters, and we are paying attention.

Feedback and Trust

Patrick Lencioni’s model of team dysfunctions identifies absence of trust as the root problem of ineffective teams. He emphasises that real trust is built on vulnerability – and that teams must be willing to engage honestly with each other’s work without posturing or defensiveness. To me, pull request feedback is one of the clearest expressions of this.

Good feedback stays anchored in the code, not in the individual.
Instead of saying, “You missed an edge case,” good feedback frames the concern neutrally: “This condition skips token expiration – should we add a check here?”

Good feedback invites conversation rather than issuing commands.
Phrasing a comment as “Could we extract this into a helper?” leaves space for discussion, alternatives, and better solutions. Dictating “Refactor this” shuts conversation down.

Setting expectations about feedback also matters.
When leaving a comment, distinguishing between blocking issues (which must be addressed) and non-blocking suggestions (which are optional or highly subjective) helps maintain momentum and prevents unnecessary friction. Clear communication avoids misunderstandings where authors might otherwise feel pressured to rework changes that were simply up for discussion.

Transparency about the depth of review.
In some cases, it makes sense to stop early and share conceptual feedback before diving deeper. If a reviewer spots a potential design flaw or a significant alternative approach during an initial scan, raising it early can save everyone time. Respectful collaboration means it’s okay to challenge the direction early, and it’s okay for both sides to acknowledge that exploring those questions is often a better use of time than completing a full technical review of work that might fundamentally change.

Receiving feedback also demands trust.
It requires assuming positive intent, resisting reflexive defensiveness, and staying open to the idea that other perspectives can make the work stronger. It’s worth remembering that many engineers – regardless of seniority – can struggle with impostor syndrome at times. When a pull request feels like a referendum on their abilities rather than a discussion about code, defensiveness can rise. Reinforcing that feedback targets the work, not the person, helps create an environment where learning and contribution feels safe.

The Long Game of Trust

Trust is not something teams declare once and possess forever. It is built – and rebuilt – through hundreds of small interactions where individuals take risks, and where those risks are met with care.

Pull requests are a microcosm of this.
Every time an author shares work before it is polished, every time a reviewer engages seriously with the work rather than treating it as a checklist, every time feedback stays anchored in the code rather than the person, trust is reinforced.

Healthy teams do not treat pull requests as bureaucratic hurdles to clear.
They treat them as ongoing conversations: about the product, the codebase, and how they want to work together. Trust grows when small vulnerabilities are met with steady hands – not once, but consistently over time.

A pull request is never just about merging code.
It is about signaling who we are as a team, and what kind of collaboration we expect.

Further reading

If you’re interested in code reviews and pull requests, then you might enjoy Rethinking Code Reviews: Trust, Speed, and Ownership, where I explore how trusting engineers to determine if code needs attention can help improve speed, ownership, and the feeling of being trusted.