liveBook · Manning

Trust

As explained in Think Like a Software Engineering Manager

Trust is confidence in another person’s reliability, intentions, competence, or support.

An engineer is more likely to raise a concern when they expect their manager to listen, respond fairly, and offer support. Trust is that confidence in another person’s reliability, intentions, competence, or support. For an engineering team, it helps people share ideas, ask for help, and work through disagreements. section 9.3.1 section 11.4.3

Build trust through repeated, observable actions:

  • Listen in one-on-ones and team meetings. Learn people’s goals and challenges, invite feedback, and make room for quieter voices. section 3.2.3
  • Communicate goals, decisions, project changes, and obstacles clearly. Make expectations mutual: explain what the team needs to do and what support it can expect from you. section 3.2.3 section 11.4.3
  • Lead by example, follow through on commitments, address bad behavior consistently, and treat mistakes as opportunities to solve problems constructively. section 3.2.3 section 9.3.1

Transparency supports trust, but it does not mean sharing everything. Give the team information relevant to its work while protecting sensitive details, such as individual compensation-band rankings. Psychological safety is related: people need to feel able to speak and be themselves without bad behavior going unaddressed. section 3.2.3

When a design disagreement stalls

Two engineers favored different approaches to a promotion tool. After letting them discuss the options, their manager stepped in when the impasse persisted. Individual conversations gave each person space to speak; questions about effort, timelines, reuse, and resources moved the discussion toward a shared decision. The resolution strengthened collaboration and trust. section 3.1.3

In cross-functional work, trust can take time because collaborators must learn one another’s strengths and ways of working. Opaque decisions, missed commitments, poor communication, and blame can weaken it. Watch whether people listen, share feedback, and offer help; use check-ins or surveys to uncover concerns, then address them openly. Ask yourself: whose perspective is missing from the next decision? section 9.3.1 section 9.2.5

How Think Like a Software Engineering Manager covers it

How deep it goes
Provides practical behaviors, warning signs, and ways to assess trust rather than a formal measurement method.
Examples
Uses a design disagreement resolved through facilitated discussion and a working-hours decision challenged through one-on-one feedback.
What it assumes
Assumes an engineering-manager setting while explaining trust-building through everyday team interactions.
What you can do after
Practice/perform trust-building through candid conversations, clear expectations, consistent behavior, and timely responses to concerns.
How it connects
Connects trust to transparency, psychological safety, accountability, conflict resolution, and expectation setting.

Also explained in

Compare how 14 books explain trust →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Think Like a Software Engineering Manager. The section links point to the parts of the book it draws on.