"Those who show no trust will not be trusted."
– Tao Te Ching, Chapter 17
Tech Leads are handed big responsibilities and commitments. Necks are on the line for code and product quality, risk management and oversight, good system design. We are also handed a set of individuals, often with a mix of skills and experiences, to produce something new.
We have to find a way that aligns these people into a team to meet these commitments, and that starts with trust. Why does trust often prove to be a puzzle?
Where can trust go wrong?
We can't see trust. Instead we try to feel it. We often take it for granted until it's not there. Then we really feel it. And navigating this immaterial thing, we often fall back on feelings and extremes.
We fail if we just feel it out
If we base our trust on how we feel, then we risk being a random trust generator, driven by our proclivities, mood and what we had for breakfast. No team wants a vibe-driven leader.
We fail if we use polar thinking and favourites
There are two opposing poles of trust in teams: total handover and micro-management. Neither works. Total handover is a passive surrendering to what happens. We are not leading or using our wisdom, we are just handing out work and hoping it goes well. At the other pole, micro-management is often rooted in fear and control. It's a sure-fire way to kill creativity, thinking and passion for the work.
We fail if we don't think of it as something we can influence
Yes, trust is a bet on the future, but it's something far more in our control than it might feel like. So rather than accept whatever happens or demand attention, we can build 'invisible' team infrastructure to gather the trust we need.
Trust is structural
In a team, trust can be something that gets built. And like any structure, it has foundations, and pieces to assemble. So what does it look like to build trust deliberately?
Story: Trust as structure
I spent some time leading a team at a betting company. Integrating a white-label platform into multiple branded homes. I had two talented senior engineers working with me, and it was clear both were not happy. Neither was interacting well or producing the results I expected. I sat down with both to find out what was going on.
The first was burnt-out from rolling with the punches. Caring deeply and dealing with the complications that teams are constantly presented with had made him crispy at the edges. The second was frustrated; bored, coasting — rusting. She had signed up wanting to learn, and that was not happening any more.
My burnt-out engineer needed recovery time. Not a day off, but some proper space. Of course, I couldn't give them a month off. But I did have a whole pile of tech debt, some of which was contributing to these complications.
He was off the hook for feature work, and would take time to uncover and fix some deep annoyances that would pay off. He deep-dived into the tech debt. We met often, paired on plans, and shaped approaches he could actually deliver. Our agreement: Bring me ideas that could pay off; let's pair on plans.
My rusted-out engineer, I let loose. She needed to experiment — to test the ideas she had — and find out how they could work.
I gave her a sub-team, a white board and a real delivery challenge. Stakes, ownership, room to lead. Our agreement: Come to me when you need something.
Both recovered. Both thrived.
Principle: Trust your people. Teach them to reach out when in need.
One key discovery for me was to always build the structure for progressive trust to develop. Provide what they need, and make the path back to you visible.
Trust is a progressive conversation. It starts with not centring yourself. It builds toward effortless alignment.
Make it active and dynamic. Build a series of progressing conversations and agreements where together we actively choose what level of control to surrender.
Trust must be examined
Examination means building in the behaviours that keep trust visible.
- There's verification (you check, with care, not with suspicion).
- There's reach-out (they come to you before things break, because you've shown that's safe).
- There's autonomy with attention (they own the work; you stay close enough to know when help is needed).
Each of those is a behaviour, not a feeling. Each can be built. Each can be neglected.
I have not always got this right. Let me share a story of a failed delegation, leading to a near miss.
Story: failed delegation
On a project where we were rebuilding a dating site, we needed to refund some customers, a feature hadn't landed right and customers had been rightfully upset. A decision was taken to return some subscription fees.
I delegated the tech leadership for this work. I trusted the person, and I'd been right to trust them. But a mistake was made with an encryption key pair, a risky one-way door.
We narrowly avoided a very big operational problem. A check that was made a few hours after we invited the first customers found that the credit card data was corrupt. We did not know why. With a clear live failure happening, we stormed into incident mode, and worked to identify our root cause.
The team worked fast and we had the problem identified and fixed in an hour.
It was a tense moment. The lesson stuck.
Principle: Hold the space. Trust instincts. Verify
I learnt that trust cannot be blind. As in the first story, I was right to delegate. It was a good choice. However, I still held responsibility and had the experience to spot where there was an extra-special risk to be managed.
I didn't check in. I didn't ask for a plan, a design doc or a risk assessment. I didn't set up the structure for verification and support.
And that was on me. I was untrustworthy.
Trust is structural
Trust is not blind faith, but it is not purely logical either. It's not built by stepping back and hoping. Nor can it be developed by controlling. It arises from openness, experience and alignment. We build this structure, making it safe to reach out. We verify with attention and with data, not ego, being there before you're needed.
Trust is often strongest when it is not overtly demanded. A leader who is trusted acts silently, letting the team take credit.
The signal it's working
Will this make your problems go away? No, there are always problems. It might mean you feel like you have more of them. When you build trust, expect the team to start coming to you before things break.
Don't see this as a hassle. It's a signal the structure is working — and an opportunity to build stronger trust.