“No Go” — Crew Resource Management as Flat Organization Training Wheels

If you’re transitioning to a flat structure, you HAVE to expect growing pains. Especially if you’re top-down implementing the change, you’ve got a really weird maze to navigate. Your final directive is that you can’t give any more directives. What happens when you get really passionate about a project? Is the rest of the company just going to bow out instead of fighting you if they feel it’s a bad idea?

There needs to be a bunch of education. I know that the Toyota Way talks about “stopping the factory so the factory never has to stop,” but I work in EMS. I don’t think about factories, I think about patient outcomes. I learned about Crew Resource Management from David Page ( http://twitter.com/davidpage ), and it’s the best framework I can find for easing your way into a flat organization.

At its most basic, Crew Resource Management means anyone can say “no go”. It comes from airlines, where everyone from the baggage handler to the air traffic control can decide that a plane isn’t flying today. Not only CAN they make that decision, but they are expected to.

In a company, and again, my experience is entirely in software, team members have to be empowered to say “No Go”. If you’re trying to transition to a flat organization, during planning meetings or any time when a major decision is made, take the time to ask the room “Is there any reason we’re not flying today?” Train your team that there is a difference between “I do not understand why we are doing this” versus “I think we shouldn’t do this”. Be willing to ask, when there is passionate discussion, if either side is saying “No Go”.

As an executive, you’ve actually got it tougher than the rest of the company. You need to be willing to back down off your fights earlier than you’d want the rest of the team to do it. You should eventually be just another member of the team whose role just happens to be strategic vision, talent acquisition, and business security. Early on, no one is going to have internalized that. You’re still the person who can fire them.

I’ve had to work with our CEO to get him used to having to walk back from lines of “what if we…” questioning. He thinks he’s just brainstorming. The teams he works with end up taking a line of pointed questions as implicit direction. Sometimes, you need someone in the room to straight up ask “is this an executive trump or are you just asking?”

It sucks. As the CEO, you’ve probably got more business acumen and specialized knowledge than anyone else in the room. And you might have the exact right way to do something. But by going flat, you’re telling the rest of the company that you trust them to make decisions. Like in parenting, sometimes that means you need to let them make mistakes. Obviously, if it’s going to be a gigantic failure, you need to exercise your own rights within Crew Resource Management and speak up—but there are times when, for morale, you need to fall on your sword. It’s World Cup time, so maybe I should say “take a dive”.

This isn’t just for executives. It’s for Product Owners and Scrum Masters (or project people and wranglers, if you’re not doing Scrum). If you’re in the transition from hierarchy to flatness, you have to be willing to lose some fights, even if you care a lot. You have to let your team HAVE the autonomy we claim we want to give them. Yes, you’re entitled to your own opinion and right to fight for your ideas. No, it’s not as important that you win as that the team gets used to collaboration.

The move to flatness is rough. Beyond the things I talk about above, you also have personnel mismatches, technology issues/siloing, and even over-communicating. I’ll dedicate future posts to those topics of course.

Let me know what’s working on the blog. I can cover whatever topics people want, and I’m happy to host posts from people who dissent or want to expand on what I’ve put up.

—

ADDENDUM:

This post felt really bleak. It shouldn’t be. Flat being hard doesn’t mean it isn’t worth it.

My best friend, Eryn ( http://twitter.com/eryno ), is much much smarter than me. She condensed my philosophy about transitioning to Flat/Agile methods  into eleven words.

“I got done being bad at it. And now I’m good.”

She was talking about our shared experience of being high school speech team competitors (because theater wasn’t lame enough), but it applies to implementing a flat or agile scheme.

You just have to fucking do it. You’re going to be really bad at it. You are not going to magically NOT be bad at it if you wring your hands and over-engineer it for months before trying it out. You are going to make mistakes. Your executives are going to swoop and poop all over team-driven projects. Meetings are going to be too crowded with too many people who don’t need to be there.

It will seem like a shitshow at first. You’re going to want to re-engineer a whole system of roles and regulations. Don’t.

You don’t know what you need yet. You’re going to be bad at it, and that’s going to teach you the small adjustments you need to make to nudge the org in the right direction.

 

Then you’ll be done being bad at it. And you’ll be good.

Wranglers

I’m a flat organization heretic. This is my confession. It’s scary to say, given how much I love flat orgs and work-driven teams.

I don’t hate managers.

More appropriately, I don’t hate people-wranglers. Good managers ARE people-wranglers. It’s just that sometimes they need to wrangle too many people doing too many things. They get abstracted up out of the work and are too focused on structure and psychology. One of the reasons teams go flat is that there’s a LOT of overhead to having managers who only manage. How many people can you reasonably be accountable for – 5? 10? 25? No matter what arbitrary number you pick, you end up with a scaling problem.

The first solution there is not to scale. Why are you scaling? Do you have to, or are you doing it because it’s part of Ries and Blank’s definition of a startup? That’s a different topic for a different time, though.

I talk about people who are only hired to tell people what to do as “mere managers.” Which, I guess, is kind of a diss. But in a flat org, I think it should be. Mere managers can be CEOs and VPs of What-The-Hell-Ever in a company that needs overt structure. But most companies that choose to go flat are creative. Projects and products don’t have a 10 year spin up like in biotech. Usually, we’re software companies whose biggest bottleneck is actually getting code to page (and maybe QA). Our biggest overhead is usually salary.

So every employee matters. There’s a lot of chatter about managers vs. individual contributors lately, and ICs are where the home runs come from in a flat org. One developer with a good idea of scope can make something that disrupts a market. If you want bang-for-buck, you get the hot shit IC every time.

But people don’t always get along. ICs don’t necessarily get fired up about everything that comes their way. Flat advocates (flatvocates?) always talk about “ownership” of work, as though that feeling magically means everyone in a company will bust their ass for everything. Ownership just means you invested in something, it doesn’t mean you’re always driven. I own a Wii. I have ownership there. I haven’t turned it on in three years. Chances are next to nothing that I’m going to go home and decide to play Boom Blox for ten hours.

So, in the pool of ICs, you still need people-wranglers. It’s easy to have ownership of big, impressive projects. Especially in the early, gigantic-visible-steps stages. You need people who are willing to get excited about doing the bullshit that needs to get done. Maybe that’s writing unit tests or refactoring your code to be more modular. Maybe it’s finally polishing up rough edges that were “good enough” for the initial iterative release. Maybe it’s making phone calls to every customer who is about to be affected by a change.

Someone has to make individual contributors get excited about that shit. I don’t ever expect someone to go to work saying “I can’t WAIT to rewrite the auth on this legacy application!” It’ll never happen. What people-wranglers are good at is getting a team to band together and hate all of that shit together.

My reference point, as always, is Ultimate Frisbee. People-wranglers are coaches. They’re captains.

In the end, the team has to do work to succeed, but there’s someone there pushing them. I like Ultimate as the metaphor here instead of football or something, because usually those coaches are also players on the team. It’s not someone with a whistle yelling at two dozen people to be faster, work better. It’s someone winded at the front of the sprint line saying “God, I fucking hate conditioning. Let’s do it again!”

People-wranglers are motivators. They’re the ones who are helping the team celebrate finishing their garbage tasks. They’re the ones publicly lauding teams for doing what they’re supposed to be doing.

They’re also the ones who make sure that the balance between the garbage and the interesting work is maintained. Because we work in a field with a lot of introverts, it helps to have someone who cares if their coworkers love their jobs.

I don’t really care if these people are called managers or Scrum Masters or wranglers or whatever. I don’t think it’s important that they be able to hire or fire. It’s important that one of the expectations for them is keeping the company working—as in actually doing work. It’s hard to do that well in a flat org, because you urging a coworker to take on harder tasks is a very thin line away from telling them what to do. People-wranglers need to learn to motivate. They have to be able to influence the culture around them.

Practical Implementation:

Audit your team. Who are the natural leaders, who are the authorities on technologies you use or markets you’re in? Are they the kinds of people who are able to get excited about process? If so, you’re in luck. You can speak with them about what you need in regards to people-wrangling (and don’t keep it secret, the rest of the team can know that you trust this person to have a finger on your company’s pulse).

More likely, you’re going to find that domain experts don’t necessarily map to people-wranglers. “I know better so just do it my way” is often toxic in a flat org. You need to find the people who are excited about your company, not just their role. This is why it’s so important, when hiring, to find candidates who are all in on your company and your vision. Honestly, that’s not going to be everyone. Sometimes you need ICs who are excited to work on your projects or technologies, regardless of their interest in your company as a whole. But they need to be balanced by hires that are going to get excited about process and people.

Pursuing Flatness

I’ve met dozens of people who claim to work at Flat Organizations. Sometimes they’ll say “flat plus one” or “flatish”. I’ve met even more people who work at hierarchical companies but _really_ want to make sure I know that they’re “pretty flat”. I love working at my current job, a place that’s flat plus one, except when it’s completely flat. I’m unsure, though, as to why we all care so much.

I’m not saying “it doesn’t matter”. I’m genuinely asking – what about Flat Orgs appeals to us? What makes them such a good idea? Why do people who AREN’T in flat orgs want us to believe they are? Is it mostly just fashion? Are autonomous teams the real key? Does it matter if that team is accountable to a manager or to a product owner or to a board? I want to know what we’re accomplishing with our grand experiment in flatness. I want to know what parts are functional and what are window dressing.

My title is usually something akin to “operations guy”. I answer phones, I specialize in our specific software, and I get customers to Buy In on an emotional level. I value the flat org because, frankly, it makes my job interesting. It helps me be _good_ at what I’m supposed to be doing. My CEO spent three hours this morning being bounced around tech support at Quickbooks – they’ve got a tiered and siloed support structure, so everyone was passing the buck. That’s crazy. That’s a bunch of support people—nominally (and fashionably) “customer advocates” – who are more concerned with cranking through calls and saying “not my problem” than diagnosing an issue to get a better result.

At Fisdap, we have the benefit of not having the volume of calls QB does, so that may be part of it, but our support personnel are expected to solve the issues they’re faced with. We’re empowered to vie for developer time, to present use-case information to UX, and to make business decisions on the fly. We’re not the lowest rung on the totem pole – we’re not warm bodies. We are there to do what we have to in order to help fix stuff.

Do we need to be flat to do that? No. We could have stricter rules about exactly what is allowed – a discretionary budget we can use to solve problems, like some hotels do, or a number of hours of developer time. Knowing that I’m responsible for making the _right_ call, instead of just a _permitted_ call, though, means I’m less likely to over-promise. I need to excel, not just avoid screwing up. If I’m not doing well, I’m letting down the whole company.

As a guy who started in a position that is usually expendable and replaceable, I definitely feel more valued in a flat organization. I’m not worried about stepping on toes or becoming a manager – being good at my job makes me valuable to development teams and our HR process. My daily tasks are more interesting and more visible to everyone. I feel like a huge part of my company.

What does that feel like for developers, though? Engineering and design – frankly, anyone who has ‘deliverables’—what is a flat organization bringing you? Is it empowering? Is it frustrating? Do you have more ownership or just less guidance? I know the answers are going to be “a little of all of those,” but I want to know details. Why are we flat, or why do we strive to flatness?