Sometimes, the fastest route to solving a problem isn’t necessarily the best route. That’s something I’ve learned while leading an open organization.

Top-down organizations can certainly excel at achieving efficiency—and if efficiency is your ultimate goal, then constructing a hierarchy is a valid way to go. Quite often, a command-and-control-style structure can produce the most accurate version of your vision, and quickly.

But don’t expect anything a hierarchy does to pleasantly surprise you. Don’t expect it to respond well to forces or events outside of your control. Don’t expect it to flourish without your meticulous oversight.

In short, don’t expect it to be agile. That’s because agility requires an organizational capability to respond and react that top-down, proscribed systems simply cannot achieve. It requires an organization in which every “box” has the latitude and responsibility to react and adjust to a changing environment. That’s not something central planning can accomplish. If that sounds messy and chaotic to you, then you’re right. But the long term results will surprise you in many positive ways.

Think about a perennial garden in its early days. It looks similarly messy and chaotic. To reach its potential, it will require a good deal of nurturing. But the rewards of keeping a perennial garden can be wonderful. Each year, new colors greet you. New configurations, things you could never foresee or anticipate, surprise you—all because you continued to invest in the activity sprouting there.

Sure, you could plant an annual garden. Doing that would actually take you less time. You could place plants exactly where you wanted them, arrange them in precise ways—control every aspect of the project, from start to finish. The garden might flourish for a bit, but its spectacle would only be temporary. You’d have to start all over again the following year, and the work of replanting everything would fall on you alone.

Leading an open organization—where hierarchy cedes much of its control to dynamic, networked structures—feels much more like maintaining a perennial garden. It involves working more on conditions (turning soil, locating those spots in need of watering) than it does on dictating direction. It means creating the context for things (things you might not have considered or even imagined) to occur.

And on top of that, tending to your networks is going to produce the best-performing results—every time. Because when you’ve entrusted your associates to grow and evolve their work in the ways they see fit, you’re going to enjoy more robust and effective solutions. You’ll also see speedier, more flexible ones. As I say in The Open Organization, networked structures more easily facilitate what US Air Force colonel John Boyd calls the “OODA loop“; they allow for quicker reactions to immediate, pressing situations. Hierarchies might let you make one-off decisions at a faster rate, but, ultimately, they’re just not as responsive in the long term.

Take what is probably the oldest participative, open system—the United States’ legal system—for example. Today, that system is incredibly subtle and nuanced; it’s highly adaptable and constantly evolving. But building it required hundreds of years of painstaking work: maintenance, upkeep, and tiny iterations in response to local, contextual changes. The system is built on legal precedent after legal precedent, opinion after opinion, and has emerged organically. You could dictate a legal system from above—”hatch” one fully-formed in a shorter amount of time—but it wouldn’t be nearly as adept at addressing real-world complexity.

Or, to use another example (one much closer to Red Hat’s core business): take the Linux kernel. Today, it stands as the very best solution to a growing number of technological problems, but it didn’t spring from a single person’s head overnight. Decades of work made it the flexible, superior solution it is today. Local improvements and impassioned debates between key stakeholders continue to refine it.

Yes, sometimes you’ll need to achieve an objective with maximum efficiency. We occasionally do at Red Hat. Rather than activate the rich culture of our various networks to grow the best solution, we opt for streamlining and expediting one. But we’re always aware of the sacrifices we make by doing so.

Because most often, the fastest solution isn’t the best one. Bear that in mind the next time you start feeling frustrated by your network’s slower pace of execution. When you’re ready to reap what you’ve sewn, you’ll be happy you did.