TBM 347: "Why Don't Our Leaders Care About How We Work?"
I received this great question recently:
John, many of your posts are about taking a thoughtful and intentional approach when designing your company's operating system. I very much appreciated TBM 336: Product OS Design Tips and Principles. But at my company, no one thinks this way. It is all seen as a process, and everyone hates it unless they can benefit directly. Why is this the case? Is what you are talking about only possible in rare cases? How can I get my company, particularly the leaders, to take a more intentional approach? Or is my only hope going to work for a company that does this already?
I'm sharing a lightly edited version of my response below as I've been thinking a lot about these questions lately.
Two Camps, No Nuance
The dominant belief is that you have two camps: the process camp and the high accountability, integrity, and agency camp. So, the idea of somehow artfully designing an OS—thinking about behaviors, systems, and the environment—is hard even to discuss. It doesn't fit people's two defined buckets—process/management or leadership. Is this management? Leadership? Process design? Something else?
If you can't name it, you can barely discuss it.
It Is a Skill (And We Forget That)
You can have highly qualified people who can move mountains and provide immense value to an organization—with zero skills in designing an OS. It simply isn't something they are good at. Give them an opportunity to work 1:1 with people, build bridges, find consensus, drive action, and make things happen, and they are in their element. Ask them to design a system that helps other people do that; they are useless. Distance them from the details, and they are at a complete loss unless someone figures out how to get them back into the details again.
The idea that you can be so "good" at one thing but be so bad at something else that seems similar and overlapping sounds so crazy that people often don't believe it is possible. "That doesn't make sense! You can't be a good leader and have that happen!" But it is true. It happens all the time. When people are self-aware, that's OK. They realize this isn't their strength. But when they aren't, they'll invent all kinds of explanations for why they've figured something out and why everyone else doesn't get it.
Don't Have Time
Suppose you are a nerd about this stuff. In that case, it is easy to imagine extended leadership meetings with healthy debates about ways of working, what to call things, behaviors, centralization vs. decentralization, etc. Unfortunately, those discussions are very rare unless a founder or executive who cares is present. I have a friend who is a chief of staff at one of the world's top 6 big tech companies. She had a great quote recently.
You imagine that when you get into the room with these people, you'll suddenly be exposed to super thoughtful discussions about how we want to work, how we want to show up, and how we can improve. But it isn't like that at all.
There are various reasons for this—many of which we discuss in this post—but the practical thing for you to remember is that there's a good chance that very few people are thinking about this as deeply as you are. Some people might enjoy thinking about these topics, but their day-to-day jobs are filled with other, more pressing concerns. The constraints of an operating system are hoops you have to jump through vs. anything intentional.
Again, the rare leader will transcend all this to do something special, but most leadership teams don't have a moment to worry about it. You see the blast radius of these decisions; they see their reports, their bosses (or their board), and their goals—that's it.
Founders Are OS Nerds (Or Not)
Some founders are big nerds when it comes to ways of working and operating system design. Some aren't. Both types of founders can be exceptionally effective, and both can fail miserably depending on how things play out. Company founders have a lot of sway and influence. If they care, great! But if your company's founder doesn't care—or they care but aren't good at organizational design and ways of working—then you'll have an uphill battle. You're not doomed, however. You might have a shot if they are self-aware and willing to empower and support someone in this work.
General Management Doesn't Translate
Being a great front-line manager doesn't automatically qualify you as a skilled operating system designer for large groups of people, especially when you've enjoyed a reasonable amount of independence and autonomy. A team is a contained unit. Front-line managers are expected to dial in meetings, comms, rituals, artifacts, enabling constraints, etc., but the scope of those efforts is mostly local. You don't need to deal with questions like, "What is the minimal amount of consistency required to help 2,000 people align on goals?"
This is important because managers who get promoted quickly into upper manager and leader positions often try to apply what worked locally to what might feasibly work globally. When that fails, their first instinct is to carve out the autonomy and boundaries they once enjoyed as managers of smaller teams, which works in the short term but can lead to problems when collaborating across messier boundaries.
Process Allergy
Many executives view anything that hints at "process" as below them. They didn't work this hard to get where they are to design meeting cadences, agendas, working agreements, etc. In their mind, they hire chiefs of staff, program managers, product operations, etc., for this! Their time is much better spent on relationships, "getting into the details" (but not these details), and keeping things moving at a high level. In ideal conditions, this can work. They know these things are important, but they empower others to own them and make them happen. That is the perfect case.
In reality, a bad dynamic emerges whereby instead of truly owning the OS, they blame other roles for things going wrong and only take the credit when things work smoothly. If things feel "too processy," it is the fault of the support functions. If things are chaotic, they ALSO blame the supporting functions.
Leaders love to cart out the five simple slides with pyramids and loops, and words like “empowered” or “product operating model”. The details…not so much (in many cases).
Middle-Out Push Fails
Often, you see a push from inside the organization to refine ways of working and establish some global guidelines. This push might come top down in the midst of a crisis. However, it frequently emerges from groups with an end-to-end view of the organization, which can see gaps emerging where shared understanding and models might help. The problem is that this view is a direct affront and threat to the teams working more independently and doing their thing. So you'll see proposals like "OK, let's call all of the efforts that look like this X," and then a resulting pushback from the groups that aren't affected and don't care.
The pushback is often justified. There's no inherent value in consistency if the goal is to work independently and align through lightweight interfaces. So this starts an ongoing debate between those impacted by dependencies or needing to deal with the whole org and those operating independently. Senior leadership likes to distance themselves from this debate because it feels too theoretical and processy (again). So you end up with the middle layers battling it out over global vs. local approaches and senior leaders just getting frustrated by the commotion. Rinse and repeat.
Just Have the CoS Do It
Realistically, some chiefs of staff, program managers, and product operations managers aren't great at OS design. The key issue is that many people in these roles haven't actually done IC work up through middle to middle-upper management work. They are organized, they get things done, and they can see the "big picture," but they aren't as savvy when it comes to human behavior, the physics of building products, organizational design, and thinking about emergence and change over the long haul.
So when a leader says "Fix this!" they get it done but don't necessarily think holistically about the problem. It is incredible how much sway chiefs of staff have when dictating how companies work (and, in particular, the direct reports of the leader they support). Leaders give them a week to figure out a whole new goal-setting approach. Even the savviest OS designer out there will falter with such short notice, especially if leaders want to offload the nitty gritty details to someone else. It is a lose-lose situation. So much of how companies work is decided on short notice by a closed group with little insight into how things work on the front lines. This is why Zombie Process is a big deal: that thing was decided in an hour three years ago and somehow "stuck."
Here are some tips:
Remember, a team can be intentional without being explicit, and they can be explicit about ways of working and not deliberate. Keep this in mind as you advocate for change. It could be that leaders in your company are very intentional but prefer not to be very explicit. Test the waters first, but they may need your help.
Start with relatable stories about what it is like to make decisions, get work done, etc. Most people don't respond to theory or generalities. Be specific and use that as leverage to discuss the changes you might try to help.
If you have chiefs of staff trying to invent company operating systems in a day(or week), try to partner with them. They may appreciate your help and perspective.
Check yourself for your own bias. Are you the type of person who likes everything crystal clear? Or do you like things more organic? Let that guide your approach.
I've found actual behaviors to be a real unifying discussion piece. "What behaviors are we hoping to see more of? Less of?" Then consider the lightest weight nudges to spark more of that. Remember that most people in your company imagine that behavior is something individuals do in a vacuum; it isn't environmentally mediated, so work around that to the best of your ability.
You can go a long way in keeping your own private document of how things work. Build it to the point where you can share it and see what happens. Sometimes, the big blocker was someone taking the stubborn time to shine the mirror back on the company.
Always keep inertia in mind. You might believe in the power of a well-designed company operating system. However, most people are 1) inherently skeptical that it will make any difference and 2) so consumed with day-to-day care that they will need to see things get better before lifting a finger.