The nuance of organizational operating systems

Why does it seem that so many organizations start out fast and lean and eventually devolve into a systematic morass of bureaucracy?

I’ve been asking myself this question a lot lately, because when companies are small, they don’t ever aspire to large amounts of bureaucracy, yet it happens over and over. Larger companies should seemingly have a lot of advantages over smaller companies (economies of scale, existing customers, well-understood value propositions), yet it’s the smaller companies that are growing exponentially and disrupting industries.

Maybe you’re the person working at the smaller company that’s growing fast. That’s great news! But there be dragons on the horizon.

Navigating the operating systems

We all live within an “operating system”, or a set of established rules that we believe will lead to good outcomes. For example, people might say, “If I work hard in school and go to college, I will be able to have a good career doing X and be successful.” We all live by these assumptions and count on them for our success, and this pursuit of happiness is an innate part of all of us.

When something comes along and threatens the operating system that we’re counting on, that is disruptive. Think of all of the factory workers that are saying, “I never missed a day of work and always worked hard, so why is my job moving overseas?” Those people were counting on a certain operating system and banked their success on it, which wasn’t a bad idea at the time, but then the rug got pulled out from under them. People generally don’t like that.

A major focus of the Agile movements of the last 15+ years has been around undoing the corporate culture of control and replacing it with empowered, cross-functional teams. In large organizations, the transformation efforts are typically at odds with the established system, which tends to fight back with such force that the Agile transformation efforts eventually get overpowered by the remaining establishment that doesn’t want to accept a new system.

Why do people oppose these transformation efforts so much? Because they’ve invested their career into that operating system. They staked their career on finding a way to work within an established operating system and advance in their career that way (and if your value is in your relationships and knowledge of internal systems, you can’t take those to another company). When you’re invested in an operating system, there is a temptation to believe things like, “I need to make sure I have control over more so that I don’t get cut if there are budget cuts.” That statement might give someone job security, but it doesn’t help the company create value.

I believe in organizations where as many as possible are directly involved in the creation of value, either as a doer or a leader. The doers are on the front lines doing the actual work to create things, and the leaders are thinking strategically, casting vision, finding new ways to create value, empowering teams, and distributing power and control as much as they can. As things grow, companies typically add the enablers in the middle to help coordinate it all.

This is not to say all middle managers are bad. After all, I am one (by title, at least). :) Here’s the crux of my point – the more people are confident in their ability to get another job at the same level, the more they will behave in the best interest of the company. There is a really good job market out there if you’re a developer or if you’re a good leader, but there’s not as much of a job market for the middle manager who only knows how to navigate the political landscape at Company X and knows Company X’s systems. All of us (myself included) are trying to figure out the operating systems in our world that will enable us achieve success.

So what does your organization’s operating system incentivize people to do? If you’re organization feels overly political and you feel like everyone is trying to grow their fiefdoms, think about who set up that operating system. Why are you surprised when people are trying to invest in your operating system to advance their career?

Blurring the lines

In many organizations, job roles and functions are very well-defined (implicitly or explicitly). Developers write code, QA testers test code, managers/directors/etc. are the leaders that drive the bus. This creates a pyramid structure with a few senior leaders at the top, the doers at the bottom, and several layers of enablers in the middle to execute the leaders’ vision and manage the doers at the bottom.

I think we need to blur the lines. I think that the goal of the leaders at the top should be to push as much context and leadership down to the people below them. Senior leaders got to their position for a reason, so they need to use their leadership talents to train and coach the next generation of leaders.

In addition, I believe we should pull problem solving up to the higher levels of the organization. This doesn’t mean that everyone in the organization is writing code, but if leaders are delegating and empowering others to lead, they now have time to focus on other things, including helping deliver value to the customer. So if an opportunity comes up, maybe a leader has time to dive down in the weeds and take advantage of it.

What this does is flatten out the pyramid and gets everyone closer to the creation of the value. This operating system incentivizes people to either be directly involved in the creation of the value or to empower others to be even more successful.

Multiplying your organization

I think most people would agree that smaller teams/divisions/organizations tend to offer more autonomy, while the large, bureaucratic organizations have more red tape, dependencies, processes, and other things that reduce autonomy. For example, you may decide to centralize a job function (read: make things more efficient), but the trade-off is that you are sacrificing autonomy to do it. I’m not saying that centralizing things is always bad, but I do think that people making those decisions are often undervaluing the autonomy that they are sacrificing.

The product-based mindset that more and more companies are adopting these days is awesome. What it creates is a world of autonomy where product teams can work with engineering teams to deliver value quickly with minimal dependencies. It gets even better when you change the budget process around to fund products in real time, so now the product organization is empowered to spend money as they see fit. On the engineering side, the cross-functional team has fewer dependencies that stop them from releasing to production, so value is delivered to customers faster.

The biggest reason that I think product-based organizations thrive is that things were made smaller. A product organization is essentially a mini-organization within a larger organization, with everyone working towards the same goal. But product teams won’t thrive if you don’t give the lower-level leaders of these organizations the autonomy to make a difference. This leads to exponential scaling, and the larger organizations will be able to support larger numbers of smaller product mini-orgs.

Exponential growth

In today’s world, every organization needs to find a way to achieve exponential growth or they risk becoming obsolete. Does your organization’s operating system encourage exponential behaviors (empowering, multiplying, innovating) or linear behaviors (risk aversion, amassing influence, building fiefdoms)? Depending on how you define your operating system, people will work within the parameters that have been defined, so we need to be proactive and make sure we’re encouraging behaviors that will allow an organization to grow and continue remain nimble over time.