I’ll jump straight to the punch line: It takes more than agile tooling to make you agile.

That’s probably not what you expected to hear from a guy who makes sophisticated collaboration tools. (Or, if you did, congratulations on being a mind reader. Now please get out of my head.)

But it’s the truth.

And it’s a truth that’s easy to lose sight of because tools are seductive—even sexy—in their own way. Who doesn’t fantasize about a magical tool that will instantly remove bottlenecks in your team’s workflow? A couple of jobs ago, my team started using GreenHopper (now known as JIRA Agile), which made a massive difference in our team’s ability to stay on the same page despite being split across five different locations. So I understand the obsession with tools. But there’s more to it than that.

(Related: How improv can help your team do agile)

A lot of companies, especially large ones, talk a big game about agile. When I’ve had a chance to peek inside, far too often they’re agile in name only. They do standups and use an agile board to track work, but they haven’t embraced the fact that agile means dealing with uncertainty, constantly challenging yourself to change when you need to, and trusting your teams to make the right call when the moment comes.

When a company goes agile, questions like “When will this feature ship?” will be met with answers like “When it’s ready. We’re aiming for late next month,” or even better, “It already shipped, and we ship an improvement to it every day!” That’s a radical change from “Whenever we’re forced to ship it in order to meet our sales teams’ quota for the quarter.” And we managers should be motivating our teams to understand the importance of their effort and trust that our teams care as deeply about that feature (and the impact to our business) as we do.

For their part, team members from different disciplines have to work side by side instead of working in isolation, and then “throw it over the wall” to the next team. That means aligning road maps, planning cycles and schedules. It means balanced teams with product managers, designers, engineers, tech writers and quality, which means opening yourself up to new people and understanding the project from different points of view.

Like most revolutions, agile starts small. One team with enough grit to break the mold and show other teams what’s possible. They put in the hard work. They make their case. They prove just how much teams can accomplish in this brave new world. Neighboring teams catch on, and before long, agile is spreading faster than a Dominic Toretto quarter mile.

Atlassian was fortunate enough to emerge after the Agile Manifesto, so we didn’t have to go through an agile transformation—agile is just part of our DNA. What that looks like on the ground is an open, cubicle-free office space, so developers, product owners, marketers, and support staff can fling ideas around and fire questions back and forth with the least possible friction. It’s product owners, marketers and developers building product road maps collaboratively to ensure the right balance of business requirements and technical debt remediation. It’s engineering managers who investigate new technologies, and mentor 20 or more direct reports because they aren’t burdened with organizing their teams’ work. We trust developers to self-organize with the help of product management.

There’s that word again: trust.

Agile teams post their product road maps where anyone in the company can see them. They broadcast bug counts and build results on wallboards. They get a proof of concept out the door and iterate on it rather than succumb to analysis paralysis. They reflect on their successes and failures regularly, and share those insights with other teams. And the company understands those road maps will change in order to react to a rapidly changing trio of market forces, customer needs, and strategy.

Why? Because we work faster when we trust each other enough to ditch heavyweight oversight and hand-off processes, and simply do our work out in the open instead.

Agile should also mean embracing experimentation and, yes, even failure, in every aspect of the business. How should we position this product in the market? Let’s run some banner ads and test different messages. How do we get better-qualified applicants in the door? Try different phone screening scripts and see what works. An n-house server farm, or a third-party data center? Try some of each, and then make the call.

Knowing your teams will probably get it wrong the first time, and trusting them to learn the right things from their failures, takes some getting used to. But it’s worth it, because once you’ve built up that muscle, you can turn right around and try something else without even breaking a sweat.

That’s when you know agile has become a competitive advantage: when your teams trust each other to work collaboratively, are open and accepting of failures, and learn quickly. And that has very little to do with the tools you choose, which brings me back to my original point.

Don’t get me wrong: The right tools are critical for success if you want to move quickly. The wrong tools can actually hamstring your teams just as badly as a top-down, tightly controlled, waterfall approach. The way our teams work together inside and outside of the tools is a big factor in whether we reach our goals and how long it takes us to get there.

So here’s to the journey. Here’s to continuous improvement. And here’s to a culture of trust.