Character, Part 1: Building Trust

In his excellent book Integrity: The Courage to Meet the Demands of Reality, Henry Cloud says,

Cloud recognizes that technical expertise and leadership are both essential (as I’ve argued before), but adds a category of character integrity. He defines it as the ability to meet the demands of reality, much like the structural integrity of a jet allows it to endure the forces of flight and perform. Of the 6 dimensions to character he identifies, I’ll focus here on the first one, building trust.

If you’re a technical leader, then having others follow your lead is fundamental to your impact, and this requires trust.

Imagine yourself as a platform engineer working on build pipelines. You serve over a dozen teams. You’ve noticed how they each would benefit from shared infrastructure you could offer them: cached builds, smoother workflows, even automated AI analysis. The catch is, they each have their own setup and thus far don’t seem interested in changing. This is a huge hurdle in building solutions that all the teams can share. How do you get these teams aligned?

At this point many engineers would say you need to communicate a convincing, technically sound solution, and exercise authority to force people to use it. There may be a place for both of these, but I want to call out how much trust matters in the process.

One level of trust is technical: people see you as someone that’s competent, has good judgment and creates good solutions. This is foundational. Without it people won’t bother engaging you or will move as slow as possible.

But another level is about the heart. If people trust you as a person, they’re willing to give weight to what you say. You have their desires and passions on your side. When you tell them making a change is worth it, they’re willing to go along voluntarily. Without this, even extremely strong technical solutions go unimplemented, bogged down by people reticent to follow.

So how is this trust built?

Imagine your organization needs to change to a more cost-effective log analysis system. You’re in charge and have a good candidate in mind. You implement the new one and it seems to work. Then you find the engineers are calling it terrible and blaming you. Their complaints betray misunderstanding, and you try to respond, “guys, you can still search like you did before, just like this…” You tell them you can make it do what they want if they tell you what that is (“make me a ticket”). You reason that they just aren’t that interested in learning something new, because it wasn’t that hard for you to learn it. Eventually they’ll get over it.

In the end, you’ve lost trust from these teams. They won’t want to receive any changes coming from you.

Now suppose that instead you take a more empathetic, “connected” approach. You pick one team that you’ve had positive interactions with and ask them to help you shape this change, explaining the reasons for it. When they agree, you survey how they use the current system so you understand their world. You show them how those things would be done in the new system, asking them “does anything seem not functional here to you?”, only then finding out ways it really is confusing or inadequate. You express to that team that you understand these things. This is true even for confusions that really don’t seem valid to you; rather than invalidating them by getting into a debate, you acknowledge that this is how they feel and that you’ll see what can be done. All of this builds connection.

Further, you recognize that there are possibilities with this system that would benefit everyone even though they weren’t part of your original requirements. Instead of waiting for them to ask you to enable an MCP, you ask them if they’d use it and champion enabling it for them. The teams you serve recognize that with you, they don’t have to look out for their well-being, because you’re doing it for them. This is extending favor.

Lastly, you admit ways it was hard for you to make the change yourself. “When I first tried to query logs in this I kept quoting things wrong over and over!” It motivates the teams to learn, ask questions, and overcome their difficulties. They trust your expertise and know you’re competent, but sharing your imperfection helps them recognize that improvement is possible. This is sharing vulnerability.

By the time you’re rolling it out for everyone, this partner team is on your side, the onboarding is smoother, and everyone is far less negative. In the end you built up trust to do more.

I could list many ways my current team demonstrates the qualities I’ve named above.

We prioritize building connection. We meet in person twice a year for meetings, great fun, and food. We ask how life is going. We have retrospective meetings that often include criticisms or negative comments, always making space to see how we each can improve.

We extend favor constantly. People help each other on a zoom after almost every standup. Instead of making people be unable to detach from a computer because they’re on-call, we make our alerts quickly escalate from one team member to another, so we can easily cover for each other if now isn’t a good time to troubleshoot. Every time we get questions about the documentation of our services, we make changes to improve it and serve everyone better.

At one of our in-person gatherings we walked through the years of team history sharing significant moments and our big blunders. We talked about the time an integer overflow led to overwritten data. I talked about the time I accidentally unleashed an infinite loop of requests to a service that charges by volume over the weekend, and then embarrassingly repeated the mistake a second time, costing the company thousands of dollars. As a team, we knew even the best of us were not perfect.

Ask yourself: