Organize Vertically Not Horizontally
Give responsible people power, stop worrying about managing them
I have a tendency to be at ends with most traditional approaches (if you’ve read my other articles here, you probably know that already). There are some cultural peculiarities in organizations that I just do not get. I want to explore the traditional approach to organizational management: top-down horizontal hierarchical layers.
This typically means that there are C-level folks, and VP-level folks making decisions in a business context, that get passed down to an operational manager, who manages a lower level of group of people who complete the work.
This arrangement has huge side-effects:
- People observe and feel that the operational “middle-manager” layer offers little value add.
- The people closest to performing the actual work are furthest from most decisions about the work.
- Conclusion: the operational middle layer’s entire function is attempting to quantitatively track the bottom layer for the top layer, and communicate for the top layer to the bottom layer.
There are plenty of ways, particularly in Software Engineering organizations, to try and mitigate problems that arise from this structure. The most common one is that the “middle-manager” often becomes a trusted Lead/Senior/Principal title (who also gets the job of mentoring). In order to maintain their expertise over the system they are also members of the bottom layer who are completing work. This means they have two jobs in addition to the one their function truly is: middle management.
Upper management views this role and title decision as a success. But, once you’ve introduced a role, whose critical function is multi-tasking while trying to ship something, you’ve introduced a bottleneck. I’ve heard it said that: “A manager whose time is divided should not be critical path for anything that needs to get delivered” and I fundamentally believe that. If you want to manage people you cannot be on the critical path of shipping. Even when the person trusted by the top layer gets a “lead” or management title, they still feel compelled to jump onto the critical path in order to make sure nothing fails. Why? Because shipping product is what has brought them success in the past.
One of the biggest problems of this three-layered approach is that the people doing the work on the bottom layer come to resent the lack of autonomy. When they are sidelined in the decision process by everyone above them there is a serious lack of growth potential. They’ll have to get lucky to find an opening in the middle layer to move up. There are only so many spots. I have to believe this is a fundamental issue that causes developers to change jobs every 2–3 years.
When you ask in a vacuum everyone agrees that every quantitative attempt to either estimate or track “progress” is fraught with problems. Yet, everyone will defend doing both of these fateful tasks. A lot of effort is spent to make tickets, move tickets, track tickets, and create reports. How many tickets should we make? How fine-grained should they be? How are we defining “Done”? Are we going to value number of commits, lines of code added, deleted?! Each person, and each team, are going to do this differently, and management is trying to get them to operate uniformly. In my opinion, that is a silly thing to try and get a group of humans to do. What is more important, being able to track how close to done something is? Or just have it be done without the ceremony?
Organizations have these three problems because the people who defined the work, and are interested in its done-ness are furthest away from actually doing the work. Organizing horizontally like this creates massive problems. I contend that we should organize vertically.
I try to live by the phrase “If you want something done do it yourself”
There is a lot of evidence that cross-functional teams perform better. I don’t think we have pushed that concept far enough. I think a vertical organization would push that further. A single team should be responsible for a whole task, including the very definition of the task. A team should be given problem statements for priority issues, and then left alone to find a proper solution, build and iterate, and get it in users hands. The team building gets to define their own schedule, and deadlines. After all, if it is a real priority shouldn’t you do it no matter how long it takes? If you’re going to create value for your business and for your users by doing it—shouldn’t you do it no matter how long it takes?
Now, if your team was given the problem statement (to use a real-world Amazon example): “We know that every 100ms in a response time causes 1% less conversions, and our mean checkout page response time is ~300ms with a standard deviation of ~50ms. There are lots of statistical outliers.”
You’re going to need a cross-functional team to do that. And you’re going to need people with the authority to make changes themselves—not request other people or teams to make changes. When you request another team to make changes you cannot make yourself, what happens? You and your team have to litigate the reasoning and validity of your request to a team who is uninterested in optimizing for your outcome.
You’re going to need people familiar with ops and systems. You’re going to need backend developers to root out specific problems, and implement generalized solutions. You’re going to need frontend developers with the UX skills to “hide” any remaining milliseconds that can’t be trimmed away. You’re going to need Product people that can get the right information from users as you are building so you know you are on the right track. And they should all be working together without go-betweens or separation.
(Moreover, I believe one single person should be responsible for the outcome of the project. But you don’t even need that if you find it objectionable. You can decide the whole team is responsible for the outcome.)
How many horizontal layers did I describe above? Usually “Product people” are firmly embedded in their own organizational layer. If you have a single person responsible that person would have probably been someone with a title like; “Lead”, “Principal”, “Director”, or even “VP” if the project is big and important enough. Then there are three separate types of people who would typically be on the bottom layer, doing the work. In a horizontal arrangement it is typical that the frontend people only stick with other frontend people, and there is a manager for all the frontend people. And so on with backend, and ops.
So I have people from all three layers working together on one team. The team is self-contained and doesn’t need to go outside themselves for any authority or dependency. That VP on the team needs to be working directly with everyone, to be a real part of the team, and not remain horizontally detached. They have one project. This one. Not ten projects where they can practice “drive-by management” and leave the team in a lurch looking for an authority, or reassurance.
This is how you solve project communication problems. Because you’ve removed the game of telephone through management layers. You’ll have people with authority directly involved with the doing of the work. Your VP doesn’t need to spend hours creating a polished deck for the department meeting (which even they know is going to be wrong/incomplete about any number of things). Your Product people don’t need to write up a full polished report from their user experiments to give to Engineering. Because they’re all working together every day.
This is how you avoid trying to do the Very Hard Thing of objectively tracking from a distance “How close are we to done?” If you’re the VP who is actually involved in the project you will have an innate feeling of how it is going. It’s less important to know that you are exactly 62.9% done, instead of “Yesterday we cleared a big hurdle and we are probably half-done”. As the VP you get to meet with the C-Suite folks with an answer in hand. (If you’re iterating in any kind of agile or lean manner, you’re going to move the goalposts as you work, so that exact-percent-done is pretty useless anyway!)
When folks can directly learn from others in the context of their work they will better realize growth opportunities available to them. Moreover, they will find out about opportunities they never knew were possible before. People can know “I really would not like that job.” Or, “That would be a really interesting place to try and take my career.” People can know “I made the right choice for my career, and I have leaders who know me and mentor me.”
This is how people feel a sense of autonomy over their work. That, with their team, decide how to solve a problem—without the top layer furthest from the work, dictating how it is to be completed, and how quickly. This is how people take pride in their work. When it is truly theirs. Because they had a hand in defining it as well as completing it.
Some of us may program robots, but we’re not robots that just complete our checklist each day.
