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?
Flatvocate 
We’ve had some luck with creating cross-group “Feature Teams” to implement high-visibility/low-complexity (in the relative sense) advances quickly and effectively. In effect we’re spending a lot of Trust Capital up front and hoping that it pays off down the line. In a sense it’s generating a bubble of hyper-focus across teams, but what we haven’t yet accomplished is keeping the benefit of that focus bubble obvious and transparent.
Trust Economy (or the Emotional Piggy Bank if you’re a Covey follower) is a pretty universal concept and just makes sense no matter what the organization. And I definitely believe that it is great to foster this concept. However, I think the one thing most organizations and people don’t want to talk about it what to do about those that are perennial breakers of the Trust Economy.
From personal experience I’ve seen trust breakers ruin organizations simply because the person in charge doesn’t take action. I’m a hardliner in that if you’re demonstrating a trait that breaks trust, you’re made aware of it, given a grace period, and if nothing changes you should get removed from the organization. Simple. But when that’s not done, such as in organizations I’ve been involved with, the toxicity of the individual will push those you want to keep to leave.
I think this is doubly hard in a flat org since you don’t have a hierarchy. There’s no definitive chain of command that can be appealed to to remove a problem person. I mean, either it’s gotta go to the COO or CEO or someone at that level, at which point they are wasting time catching up on low level issues, or the organization somehow has to convince the person to leave or to change (which they may not want to) which can be a HUGE time sink.
It’s a tough issue for a traditional org, so how would you propose handling perennial trust breakers in a flat or quasi-flat environment?