Skip to main content

Search...

Building Trust in Teams: Start Small

Building trust in teams starts with small kept commitments. A missed promise is a micro distrust signal, and self-trust comes before trusting others.

• • 11 min read
Cover of the expert talk on 'Building Trust in Teams: Start Small' with Michael Kutz, Linda Van De Vooren and Richard Seidl.

Building trust in teams means keeping small everyday commitments, because every missed promise works as a micro distrust signal. Trust in yourself comes before trust in colleagues, and honest feedback only builds a bond when the recipient can see that the critic cares. Stephen Covey calls self-trust the innermost wave of trust.

Key Takeaways

  • Building trust in teams can go fast when the right thing happens at the right moment, while the chance gets lost in the moments that pass unnoticed.
  • Stephen Covey’s waves of trust begin with self-trust, followed by relationship trust and organizational trust, and teams mostly deal with these inner three.
  • Michael Kutz holds that a team which bounces back from a disaster proves more character and competence than a team that only had smooth sailing.
  • Tuckman’s team phases make storming a necessity, because a team reaches high performance only after working through conflict and distrust.
  • The inner critic never goes away, so Linda Van De Vooren thanks it, makes a different choice and has practised that for over ten years.

Building trust in teams starts with the smallest kept promise

A Scrum Master says he will plan the team event. He never books it. Nobody mentions it, and still something has shifted: Michael Kutz calls this a micro distrust signal, and building trust in teams means working on exactly those small moments, long before anyone thinks of a team-building weekend. Team-building events are a mixed bag in his view. Something good can come out of them, but nothing has to.

The model behind this comes from Stephen Covey. He describes trust as waves moving from the inside out: self-trust at the core, then relationship trust, then organizational trust, with market trust and societal trust as the outer rings. The inner three are the ones a software team can actually work on. A developer who says “I’ll take care of that issue in the code base” and then does it adds one small stone. One who does not removes a stone, even if nobody says a word.

“You can build trust with very little Lego stones, and you should.”

(Michael Kutz)

Why does self-trust come first?

Because a person who does not trust their own judgment cannot extend trust to anyone else. Linda Van De Vooren describes it from the inside: years of imposter syndrome, plenty of facts that could be read as proof of being an actual imposter, and the daily job of trusting her own calls anyway. Her method is to check regularly with friends who will tell her the truth and to take their feedback seriously when it contradicts her own doubt. If everyone around her says she should trust herself, the question becomes why she does not.

Michael applies the same logic to commitments. Promise yourself something realistic, like working out once a week, then watch whether you actually do it. If you keep failing, the commitment may be wrong, but the monitoring is what builds self-trust.

Linda adds a second instrument: naming the behaviour that signals she is not okay. One of her shadow personas is called Hannibal Lecter. When she catches herself becoming sly, holding back or judging people, that persona has taken over, and it is time to fix something. The Dutch have a saying for how long the fixing takes: trust leaves on horseback and comes back on foot.

A team that bounces back is more trustworthy than one that never failed

A team that has survived a disaster has shown character and competence. A team with nothing but smooth sailing behind it has shown neither, because it never had the chance. Michael puts it in those terms: the team that recovers from broken trust can end up higher than it ever was, and the quiet team has simply never been tested.

He borrows a line from the Beastie Boys for the timing, it takes a second to wreck it and time to build, and still believes rebuilding can happen fast if someone does the right thing at the right moment, a moment most teams wave by when it comes.

Linda sees the same pattern in the Tuckman model she uses as a team coach. Storming is a required phase. Conflict, distrust, things going wrong that nobody controls: a team goes through that or it does not reach high performance at all. There is no way around it, Linda says.

Does brutal honesty build trust or break it?

It builds trust, as long as the other person can see that you care. Linda calls her approach limitless honesty. At a new client she is responsible for quality engineering practices across 12 teams, and nothing in place shows quality right now. She could soften that into tips about improving this or that. Instead she tells them straight: what you have now is nothing, here is the risk, here is what to try first. People feel that kind of honesty, and it creates a bond faster than careful phrasing does.

Michael, who describes Germans as brutally honest by default, adds the condition that makes it work. The signal that you care about the other person has to arrive together with the criticism. Someone who doubts your intention will misread anything you say, no matter how well it was meant. Someone who is convinced you share the goal of sustainable software, and the values behind it, reads a cut corner as a means to an end rather than an attack.

What happens when nobody takes responsibility?

Trust drains out of the team, and the people who work on quality usually feel it first. When the software runs, nobody sees the testers. When something blows up, the blame lands on them. That pattern is a stereotype, and it is also the daily reality in a lot of projects.

Two responses help. The first is transparency with data: measure what surrounds testing, root cause analysis for example, and show where the gaps really are, so the story of a defect does not default to “QA missed it”. The second is credibility through early warnings. Michael, a developer himself, asks the uncomfortable question after every real failure: why didn’t I see it coming? If the team warned about a risk and everyone decided to take it for business reasons, a later failure is a shared bet that went wrong, and nobody gets blamed alone.

Linda names a trap that is specific to consultants and, by nature, to many testers: they do their work, things improve, and they leave without ever stepping into the spotlight. “She was here, then she left, and it was fine.” The milestones in between stay invisible unless someone teaches the people who remain how to explain what is working and why, in a language management understands.

An example from an investment bank shows the other extreme. A client asked for a 50,000 dollar credit card limit for their kid. The account manager typed an extra zero, the kid spent 500,000 within a week, the client refused to pay the difference, and the account manager faced no consequences at all. Linda reads this as a company that preferred losing money over fixing the process, since a second check would have caught the typo.

Michael expects accountability without punishment. The person who made the mistake should be the one most involved in preventing it next time; Covey tells of an employee who expected to be fired after a bad investment and was told instead that the company had just spent half a million dollars on his education. The bank, for its part, later added a peer review for amounts of about 50,000 dollars and up. What Michael warns against is the reflex to stack a new process on top of an already overloaded one because of a single mistake. That, Linda says, is a good way to lose trust all over again.

Rest, fun and a wall of stickies

Staying mentally healthy in a crowded project is a matter of what you protect first, and for Linda that is rest and fun. A day fills itself with things she must do, should do or feels responsible for. If she does not prioritize rest, including feeding her body properly, the energy for all of that is gone. Fun recharges the battery: playing saxophone, walking in the forest, riding a bike. Ideas for work often arrive mid-tune; she writes them down and keeps playing.

Michael limits himself visually. His office whiteboard holds stickies with big items on them, prepare a keynote for a certain conference, that sort of thing, and the space is fixed. When it is full, something has to come off. The moments he forgets this are the ones where scope creeps in without a sticky, stress builds, and he lashes out at people around him.

His recovery routine is to write everything down honestly, put it on the wall and look at how much does not fit his square of attention. Sometimes the result is a phone call: “I cannot keep the commitment I gave you, I’m sorry.” That call hurts, and it is the only way he can keep trusting himself. The alternative is a half-done job on everything and a bill that family and friends pay.

How do you deal with the inner critic?

You do not get rid of it. Linda starts with that sad part: the voice never goes away. What changed is her relationship with it. She listens, tries to find out why it is chattering, and then tells it: thank you, I’ve heard you, I’m not going to listen today, I’m making a different choice. After more than ten years of practice she still calls it hard, because the voice says things she is genuinely afraid of.

Her rule is that choosing fear is not choosing herself. Followed to the end, fear would keep her inside the house. The bright pink skirt she wore to a testing conference is the visible version of that decision: the voice in the hotel mirror said no, she said thank you and wore it anyway, and she has never regretted choosing brave over scared.

The first step, before any of that, is noticing the voice at all. A critic you hear can be argued with. A critic you do not recognize as a voice feels like your own inner dialogue, and for a long time Linda took it for exactly that. Finding out it was a voice trying to influence her, and that she could choose, was a relief. A useful check is to write down what the critic claims and ask whether it is true or made up.

Michael’s version is darker and ends with the same advice. During a period loosely connected to COVID, which he calls gasoline on an existing fire, he stopped talking to people. The voice got louder, the things it said got nastier, and eventually he froze. Before that he had run on a hero pattern, wanting to be the super competent colleague, father and speaker all at once.

Talking to the people around him revealed that most of what he thought defined him did not matter to them. It was a distorted self-image, and the only way to verify your image is to check it against people you trust deeply. His test for that depth: who at work would you trust with your child?

Trustworthy software behaves the same way every time

Linda does not trust any system easily, and two things speed it up: the system responds the same way every time, and when it fails it tells her what went wrong. Her test case is the local travel app in every conference city, with its levels of logging in and its guessing game about which credit card it might accept if she holds the phone just so. Ten minutes of trying cards is enough to lose her. An app she can use quickly, in the moment she needs it, earns trust just as fast.

Michael reads system trust as the same wave model, from the inside out. A reliable source, like a company or a government he generally trusts, is the first signal. Then come a simple process, a good track record and, above all, meaningful error messages. “Unknown error” destroys trust; “our PayPal process is down right now, please choose a different payment method” keeps it, because the user can act on it.

His example is Uber: scarily easy the first time, and it has never let him down since. Linda has stopped trusting the same app after a driver in a European city stayed 20 minutes away without moving while the app offered her a cancellation at her own cost. One broken moment like that, and the trust is gone; Michael still trusts the app only because it has not happened to him. Software trust works like team trust, down to the horse and the walk back on foot.

Share this page