Monthly Archives: July 2014

The Trust Economy

Erik commented on one of my previous posts that empowerment is what’s important to take away from a flat org. His quote is that it’s a “culture thing, not a structure thing”. And he’s exactly right. Flat is LARGELY a culture thing, not a structure one. That’s something I’ve wanted to explore here — how do we adopt pieces of flat organizations and make them useful within more hierarchical companies?

The thing that makes flatness possible is also something that doesn’t require flatness to function — what I call the Trust Economy. Roughly defined, it’s the belief that your coworker is going to do what they said they’re going to do. More than that, it’s about believing that your coworker is going to do what they said they’re going to do well. That they’ll be open to feedback. Open to criticism.

Importantly, though, it’s also the understanding that your feedback isn’t the most important. Part of the trust economy is trusting that roles and domain specialization exist for a reason. If a job belongs to someone else, and you’re not giving a No Go, you need to know your feedback is being considered. You need to trust that even if your ideas aren’t implemented, they’re being heard.

The reason I call it a Trust Economy and not just ‘trust,’ is because when you build up trust with your teammates, you can also spend it. Someone who’s constantly questioning design decisions months after they’re made and presented, or is giving No Gos on things which aren’t actual blockers, is never going to get the benefit of the doubt from their coworkers. On the other hand, stepping back gracefully when countered, supporting projects that made decisions you publicly disagreed with, and helping other teams with resources you could have hoarded are easy ways to make your voice carry more weight. Being demonstrably altruistic earns a lot of listening.

I say this is what enables flat organizations because without a trust economy, you’ve just got a bunch of separate teams who get paid by the same people. It makes a lot more sense to protect your super sweet project than to aid the other ones happening simultaneously. A trust economy means that, when your coworker comes to you and says “can your product spare a few devs for a couple weeks? We really need to release by such and such a date”, you can trust them. You can understand that “giving up” your time isn’t being wasted. If that same coworker asks for your help EVERY TIME something needs to get done, and is making less and less effort to do it themself, you’re eventually going to say “no”. They have no trust capital, so they’re SOL when it comes to borrowing.

These transactions are good for the company. Not just because everybody pulls together or some other hippie crap. But because if people are constantly asking for and granting small (and not so small) favors, you’re avoiding siloing. Devs who need help from sysadmins have just taught the infrastructure team something new about one of the company’s projects. Support asking content/UX for help creating user forums is more intimately connecting UX with users. The Trust Economy is important because it keeps pieces of the company in contact with each other outside of structure. It doesn’t matter what team you’re on — what matters is that you’re helping the rest of the company succeed, and you’re learning little bits about a LOT of facets while you’re doing someone else a favor.

As I said in the beginning, this is by no means exclusive to flat orgs, but flat orgs can’t be healthy without it. It’s one of the aspects of flatness that can be brought into an existing hierarchy without a need to re-org. There’s plenty of concern about being taken advantage of in that situation, but as Erik said — that’s a culture thing, not a structure thing.

Thoughts? I suspect devs who prefer hyper-focus time are often left out of much of the Trust Economy because they like to get lost in flow and aren’t seen as “available.” Any recommendations on keeping them involved? Or, for devs reading, is that not really an issue because hyper-focused devs still reach out to other technologists for support?