A former report reached out recently. It was one of those unexpected messages that stops you mid-scroll, the kind that makes you put your phone down and actually think.

They wanted me to know I’d been a good manager. More specifically, they remembered how I’d believed in their technical leadership ability early on—perhaps before they believed in it themselves.

I sat with that for a while. Not because of the compliment, but because it crystallized something I’ve been practicing and preaching in one-on-ones since becoming an engineering manager: The only way to build trust is to give trust.

It sounds almost tautological when you write it out. Of course trust requires trust. But here’s what I’ve learned in my decade as an engineering manager, across multiple companies, one failed startup, and three kids: most of us do it backwards. We wait for trust to be earned. We require proof before we extend belief. We manage risk instead of enabling growth.

And in doing so, we become the limiting factor in our own organizations, relationships, and lives.

When “Senior Hire” Wasn’t an Option

At Firebase, we needed platform leads for iOS, Android, Web, and other critical SDKs. The obvious move would have been to hire senior engineers, proven leaders with battle scars and war stories.

But we needed to move fast, and the engineers we had were talented—some of them just earlier in their careers than traditional wisdom would suggest for these roles. So I asked a different question: “What if they’re already capable of this?”

I remember conversations that went something like: “I want you to own the [platform] SDK.” Pause. Visible gulp. “But I’ve never—” “I know. And I trust you to figure it out. I have your back.”

Each one struggled initially. Of course they did. One faced interpersonal conflicts that threatened team cohesion. Another made technical decisions that we had to unwind months later. A third went too deep into perfectionism and nearly missed crucial deadlines.

Here’s what I didn’t do: rescue them.

Here’s what I did do: coach them through it. Made sure they knew that struggling was part of the process, not evidence of failure. Reminded them—sometimes daily—that they were doing exactly what they were supposed to be doing.

Today? They’re among the best engineers and leaders I’ve ever worked with. Not because I’m some management genius, but because they always had that capacity. They just needed someone to see it first and create space for it to emerge.

The Framework (Because Everything Needs a Framework)

“Give trust to build trust” sounds great in leadership books and TED talks. But when you’re staring at a critical project and wondering whether to hand it to someone unproven, theory doesn’t help much. Here’s how I actually put this into practice:

1. Assess what someone can handle, then dial it up a notch. Not recklessly—you’re not throwing someone who can’t swim into the deep end. But if you think they can handle a project, give them a program. If they can handle a feature, give them a product area.

2. Make failure safe, not comfortable. This is crucial. You’re not setting people up to fail, but you’re not preventing failure either. One technique I use: identify the two-way doors—decisions that can be reversed if they don’t work out. When someone knows a choice can be undone, they’re more willing to make it, learn from it, and course-correct if needed.

Not every decision is reversible, of course. But more are than we typically acknowledge. That architectural decision? You can refactor. That process change? You can roll it back. That feature launch? You can iterate or even deprecate.

Your job is to ensure that when (not if) they fail, it won’t be catastrophic. They can recover, learn, and try again.

3. Be explicit about the trust. Don’t make people guess. Say it out loud: “I trust you with this. I believe you can handle it. I have your back.” You’d be amazed how many people have never heard those words in their professional lives.

4. Coach through challenges without stealing growth. When they struggle—and they will—your instinct will be to jump in and fix it. Don’t. Ask questions. Offer perspectives. Share similar experiences. But let them own the solution.

Trust Doesn’t Stop at Your Direct Reports

Here’s where it gets interesting: this principle extends far beyond the manager-report relationship.

When Teams Won’t Play Nice

At Firebase, we had a partner team in the Android world that we were constantly butting heads with. The friction was affecting both teams’ productivity and morale.

My solution? I invited their lead to join our API Council, which I was responsible for. It seemed counterintuitive—why give a “difficult” partner more influence over our decisions? But I wanted to give them visibility into how we operated and, more importantly, give them a stake in our success.

That trust transformed everything. I built a strong relationship with their lead through our close collaboration. When our teams got frustrated with each other (which still happened), we had a foundation to work from, manager-to-manager. We could assume positive intent because we’d extended trust first.

That relationship led to some of my most successful collaborations during my time at Firebase. Choosing to trust before it was “earned” didn’t solve everything, but it gave us something real to build from—and that made all the difference.

The AI Trust Fall

We’re in an AI revolution, and I watch engineers approach these tools with deep skepticism. “It can’t really understand context.” “It’ll never match human intuition.” “I can’t trust code I didn’t write.”

All valid concerns. Also, potentially limiting beliefs.

What I tell my teams: Trust it just a little more than feels comfortable. Not blindly—verify everything. But give it the chance to surprise you. Use it for something slightly beyond what you think it’s capable of. You might discover capabilities you didn’t know existed—both in the tool and in how you work with it.

The engineers who will thrive in this new world will be the ones who extend trust to these tools early, who give them space to be useful rather than waiting for proof of perfection.

The Hardest Place to Give Trust: Home

I have three kids—7, 4, and a 3-month-old. Every parental instinct screams at me to protect them from failure, to step in when they’re attempting something beyond their ability, to rescue them from frustration.

But then I remember: the only way to build trust is to give trust.

So I let my 7-year-old take on “big kid” responsibilities, even when I’m not sure they’re ready. I watch my 4-year-old attempt the monkey bars that seem impossibly far apart for those little hands. And with the baby? I’m already learning to trust that they’ll let me know what they need (usually at 3 AM, but still).

Do they sometimes fall? Frequently. Do they sometimes fail? Absolutely. Do they sometimes need rescue? Occasionally.

But more often than not, they surprise me. And more importantly, they surprise themselves. By stepping back and trusting them with challenges, I hope I’m playing a small part in helping them build confidence in their own abilities.

Give Developers Superpowers, See What Happens

Back at Parse, we built something that fundamentally changed what mobile developers thought was possible. We created a backend-as-a-service that gave them powers they may not have even realized they could wield—database design, server scaling, complex backend logic.

Before Parse, many mobile developers saw themselves as “just” building the client side. We showed them they could own the entire stack. Yes, there was a learning curve. Yes, there were lots of ways to make mistakes. But it was also extremely empowering.

The creativity and innovation that emerged when developers discovered these capabilities was incredible. They built things we never anticipated. Developers who thought of themselves as “mobile only” suddenly became full-stack builders. They solved problems in ways we hadn’t imagined, simply because they now had the tools to do so.

That’s what I mean by democratizing development. It’s about giving developers power they didn’t know they could have, then supporting them as they figure out how to use it. When you do that—when you trust users with real capabilities—they don’t just build apps. They reimagine what’s possible.

Firebase continued this philosophy, giving developers real-time databases, authentication systems, and infrastructure that previously required entire backend teams. Each time, the same pattern: give developers more power than they expected, support them through the learning curve, and watch them create things that amaze everyone—including themselves.

My Biggest Trust Fall (And Why “Failure” Is Relative)

When I left Facebook to start Hoomi, I took the biggest trust leap of my professional life—trusting myself to be a CEO and founder, to build something from nothing, to navigate the uncertainty of a startup.

The company didn’t succeed in the traditional sense. We built an identity platform that gave users control of their digital identities, but the product turned out not to be what the market demanded at that time.

But here’s what I gained: I grew more in that year than in any other period of my career. I learned about product-market fit the hard way. I discovered muscles I didn’t know I had—and weaknesses I needed to address. The experience of trusting myself with something that big, that uncertain, developed me into the leader I am today.

Most importantly, I learned that taking big leaps—even when they don’t go where you planned—is how you grow. That experience made me better at creating psychological safety for others to take their own leaps. When I tell someone “I trust you with this,” I mean it, because I know firsthand that the leap itself is where the growth happens.

The Uncomfortable Math of Trust

Here’s the uncomfortable truth: people won’t always meet your expectations when you extend trust. They’ll disappoint you. They’ll drop balls. They’ll make decisions that make you wonder what you were thinking.

But—and this is crucial—if you never give them space to exceed your expectations, they never will. That means you have to keep extending trust, over and over, even when expectations weren’t met the last time. Especially then.

Trust is a paradox. You have to give it to build it. You have to risk it to earn it. You have to extend it before it’s “justified.”

The alternative—waiting for proof, requiring earned trust, managing to prevent failure—creates exactly what you’re trying to avoid: teams that don’t trust each other, people who don’t grow, relationships that stagnate.

Why Write This Down

I’ve shared this philosophy in countless one-on-ones, team meetings, and skip-levels over my years as a manager. It’s not a revolutionary idea—plenty of people have said versions of this before. But it’s become such a core part of how I lead that I wanted to articulate it as part of my own philosophy.

That message from my former report reminded me that these ideas can help others too. There are engineers managing for the first time, wondering if they’re being too trusting. Teams stuck in cycles of mutual distrust. People holding themselves back because no one has ever said, “I trust you with this.”

So here it is: The only way to build trust is to give trust.

Start small if you need to. Trust someone with a task slightly beyond their proven capability. Trust a team that’s disappointed you before. Trust a tool that seems too good to be true. Trust your kids with that too-big challenge.

Then watch what happens. Not just to them—to you.

Because here’s the final thing that message reminded me of recently: when you extend trust, you don’t just change what others are capable of.

You discover what you’re capable of too.