Org your Org: Who’s Right?
Your organization structure sucks. You know it, I know it, and the rest of the organization knows it, whether they talk about it or not. But everybody has a different idea of the problems and what should be done.
So who’s right?
Let’s meet some of these folks and then do a mental experiment
Development: Their primary mission is to make stuff people want: applications, scripts, tools, products, knowledge systems. They do that through applying technical skills and process.
Finance: Their primary mission is keep track of and plan the financial health of the organization: where money comes from, where it goes, how we handle it.
Sales: Their primary mission is to take people who are interested in what we do and make and exchange money (or time) for us doing or making more of it. They do that through ongoing interactions and conversations around Key Selling Points, Unique Selling Propositions, feature lists, guarantees.
Marketing: Their primary mission is to generate interest in the public about who we are to begin meaningful interactions and conversations.
Management: Their primary mission is optimizing the machine: making sure people are trained, groups are coordinated, and work flows smoothly throughout the rest of the organization.
Planning/Logistic: Their primary mission is figuring out what we can deliver to whom at what date. Other people depend on us to do their work, so we have to make and keep commitments outside (and inside) our org.
Operations: Their primary mission is keeping the lights on: making sure the infrastructure is in place for everybody else to work.
There might be a lot more, but you get the gist. Everybody looks at the problem of organizing people from their own perspective of what’s important or not.
A friend of mine used to sell office equipment to little groups of folks deep inside the bowels of large corporations all across the globe. He would go visit these folks. Usually he got a tour of the facilities and ended up in the manager’s office.
In every office he visited, no matter what their group did or what the company did, he told me that somewhere on the wall would be an org chart. In the middle would be this manager and the group they manage. All around it? All the rest of the organization.
Good organization requires looking at the entire thing, and it’s very difficult to take an outside-in look when you’re living deep inside a large group of people that’s been around for a while. You’re used to your own little corner and you’ve spent a lot of time talking about how “If only the rest of them would fix the problems and help us do our work better, the rest of this stuff would sort itself out easily!”
What might some various opinions be?
Development: we need stability and expertise. We should group things so that experts in various areas can do deep work. Finance: we need control. We should group things into cost centers where we can better track where the money is being earned and spent. Sales: we need customers. We should group things according to what our customers need. Marketing: we need to get people interested. We should group things according to the things that generate the most interest with the people we’re trying to help. Management: we need to eliminate waste. We should group things into logical work unit that can be observed, assisted, and optimized. Planning: we need flow. We should group things according to the commitments we’ve made and when they’re due. Operations: we need reliability. We should group things into components and subsystems that we can easily move around, scale, test, and deploy.
Everybody’s got a viewpoint. They’re really good points. All of it is important. And if were honest with ourselves, we’d probably admit that we suck at a lot of it compared to other people.
So who’s right?
To figure that out, we have to take everything apart, pretend like we’re starting again with just one person. Then we’ll add people and see what makes sense in terms of organization.
Congratulations! You are now a one-person company. So what do you start doing? Making some plans for when you’re going to deliver stuff? Setting up your cost centers? Renting an office building and some server space?
I sure hope not. Instead, I hope you get out of the building and go meet people and figure out what interests them. Figure out who’d you like to help and what gets their attention.
Whoa!. Dude! That’s marketing!
I know. And no matter what kind of company you’re making, and no matter what your skills, you have to be doing things to generate interest in the group of people you’re trying to help. So you’re blogging, going to user groups, calling people, writing essays (like this one!) and becoming friends with people.
Your first org structure is based completely on generating interest. Marketing. That is primary, and if your ten-thousand person org suddenly lost all its money next week and there was only one person? They’d be marketing.
Marketing comes first. (Although in fairness, much of marketing doesn’t look like marketing to people who don’t know any different. Ever read an essay by a developer telling you how awesome their build process is at company X? Surprise! You’ve just been marketed to.)
Ok. Congrats! People are interested in your values, your mission, and what you’d like to do. Yay! What’s next?
Next you start this back-and-forth with those folks, this ongoing conversation among friends that we call business. You make something. You like how that looks? Would you like me to finish building it? They tell you about a problem they have. So you make a little more. Is that something you want?
It’s not a linear, sequential thing. It’s ongoing. It’s that sales-development relationship we all love. But you really don’t have to build much of anything to get started. You just have to find out in some way the stuff you can make that people want.
“Big hunks of plain-English phrases describing stuff one group of people want”
We call these features. Or at least I do. “Feature” is one of those words that’s been given a thousand different definitions, sadly.
So we have a pretty good organization system so far. Our ranking is Marketing -> Sales -> Development. That is, first we organize by groups of people we engage with. Maybe that’s a demographic, maybe it’s a LOB of a large company that’s our customer, maybe it’s a combination of geography and job title.
We organize this way because we want to become experts first on what interests these folks and what they care about. That is the #1 primary mission of any organization and it needs to be our highest level of organization: our passion for the people we want to help.
Next up is the stuff they want. Not the products, the features. Products are how we have decided to deliver features, but we could decide to do it another way tomorrow — and our competitors might. We have to stay focused on how we’re helping, not how we package things.. So we have to stay laser-focused on features/benefits we bring to people based on our marketing. We can break that up into products, schedules, delivery mechanism and so forth based on our top two priorities: engagement and features.
Finally comes development. Making the stuff we’ve been talking about. After we’ve grouped by market/feature, we need to deliver. And we deliver by arranging those features into an order that gets the most important stuff done first, putting off things that may not matter until later. That’s still a feature breakdown, only a much simpler version. We don’t have to deliver “order a car to pick me up” right away, but we might have to deliver “list the drivers nearby that could pick me up”
This is not functional decomposition. We are not taking one big function and breaking into smaller ones. Much pain if you do it this way.
Instead, we keep the high-level flow of “order a car to pick me up” and split that up into “strings” which flow from beginning to end. The person picks up their phone, pushes a button, and there’s a list of drivers. They click one.
It’s the same goal as before, just with a drastically-reduced complexity. This is story-splitting, and it works at the program/enterprise level the same as it works at the team level.
After becoming experts in folks and what they care about, we want our people who make things to become experts in making those people happy. That’s really tough to do. Should our tech people become experts in certain areas? Should they develop components? Should they make estimates, provide financial feedback, optimize deployment, and so on?
Absolutely — as required. But that’s not what they’re there for. That’s not why they exist. That may be part of how they work, and part of what they have to know. But it’s not the reason for the work.
Do we go down another level, come up with a fourth-level of org structure? Who comes next?
We do not. Market-feature should get you to the program management level, even in huge organizations, and the rest of that is program management.
What about finance? Planning? Operations? Management? Company experts in various detailed areas? All the other things that have to be done so that we survive and grow?
They’re services to the rest of the org.
I don’t mean that in a bad way. Let’s look at what we have so far: marketing, sales, and development.
Each of those is engaged in testable behavior that creates the business opportunity. Are people interested or not? You can check. Are we having lots of conversations with customers? Are we making the things they’d like? Are they using them?
These are all things you can check, and they have yes or no answers. But are our cost centers set up correctly? That’s an accounting opinion. People get paid money to give opinions on these things — because there are no easy answers to them. Same goes for management, planning, and operations. They can be done very poorly and everything will suck, but I can’t look at structures around these areas and tell you whether they’re any good or not without looking at our top three items and seeing how well they support them.
You can certainly set up measurable metrics in these areas, and sometimes these metrics are critically important. But they’re only as important as they contribute to the other areas.
Everything else hangs off of those guys. We judge their work by how well they accelerate our top three areas. Nobody cares if you have five-nines uptime if nobody is using your product.
And here we get to the crux of things.
All structure is derivative. This is one of these things that once you grok it, you keep telling other people until the light goes on. It’s such a simple yet powerful principle. Sometimes you may be tempted to beat them with a clue bat.
Whenever you stick things together or group them, whenever you create a structure, whether it’s a program, a website, or an org structure, it’s always based on two (and only two) things: desired behavior and values. What’s it supposed to do? What rules are we following? Between those two things, the structure is determined.
Many times this relationship is invisible. It can be made explicit or not. Many times people do not make it explicit, they just assume that everybody knows what behavior the structure is supposed to support and what values it has to abide by. Org structure is not a place where you want to do this.
Sure, you can organize in lots of other different ways. But at the end of the day, no matter what you’ve done, you still get judged by these three areas: marketing, sales, and development. You still have to support those primary testable behaviors using the values that are important to you. So why would you want to make it more painful on yourself by grouping in a different way?
Now you know.
Interested in optimizing how you deliver value, whether you’re in a startup, tech team, or large org? You should read Info-Ops. I talk about taking a small team and making things for a customer, then we take the lessons we’ve learned and scale them up. By looking at everything from the standpoint of information flow, we end up understanding both how things work and why some things work better than others.
(There is a longer discussion about how these “service areas” should be organized, but if we start with the basics and agree on the values involved, the other parts work themselves out. Maybe we can do that in a future essay. This essay is also about scaling into the hundreds of people. Once you get into the thousands, while the same principles hold true, different patterns emerge to support them.)
July 26, 2018