Organizational Design | Corporate Culture | New Work

The metaphor of an „Operating System“ for corporate sutrctures is a powerful metaphor for organizational design. It empowers employees, it encourages positive change for a better workplace and ultimately drives the notion of #FutureofWork / #NewWork. But it has its merits and may lead to misunderstandings.

A good metaphor is a fickle thing: it is powerful because it simplifies things and creates new ways of thinking. It can be equally dangerous because it intentionally omits certain aspects of reality which can lead to misunderstandings.

One of those powerful metaphors is the “operating system (OS)” used in the field of organization design. It compares the complexity of organizational structures to our general understanding around our IT devices, be it Apple Hardware or otherwise, and its operating system

[The operating system] is that invisible thing that runs on the background of all of our phones and laptops and makes them work. It dictates what can happen and what cannot. (Source)

So the OS is the backbone, the core of an organization, its structures, processes and so on. So we all know what are we are talking about when we use OS as a metaphor? I mean, are we?

Are we talking about structures like the organigram of organizations? Or are we talking about the culture in between? Or both? Or do we mean more focused topics like compensation schemes, work-life-balance programs, feedback systems, etc.?

Disclaimer: I am personally a big fan of this metaphor, but I see some big misunderstandings at the horizon which we should address before its too late and the metaphor is burned aka misinterpreted.

I recently stumbled upon two great articles that use this metaphor but in different ways.

1. Josh argues in this article that your organization’s OS = culture. If you design your OS, you design your culture.
2. Aaron and his company, The Ready, built this OS Canvas. It describes the elements of your OS. Notably, culture is not one of them.

Here is the dilemma: I do think both of them are right. How can that be? Let me re-frame culture and OS to make this clear:

Culture is the shadow of your organizational systems (aka OS). It is not the same thing. To change a shadow, you need to change the form.

Culture is the shadow of your OS

Culture and operating system are intertwined just like form and shadow. This has two important implications:

1. If you want to change your culture, you need to change your form (aka your OS). You cannot change your culture directly by putting up value posters in your employee restrooms (yes, not kidding, they are real). More on that later.
2. If you change the form (aka your OS), you will always change your shadow (aka your culture). So a statement like “we don’ want to change the culture around here, we just need to do some small structural adjustments” is like shadow boxing; you won’t have the upper hand. Ever. Culture eats strategy for breakfast.

Let’s stick with this assumption a little bit longer as it leads to some interesting questions (I think).

How to design culture?

As Josh noted, culture is complex, unreasonably complicated. I do not believe you can design culture directly. Like on a drawing board. “Here is the concept of our culture, let’s just implement it”. A to B. Not working. Restroom poster!

But if this approach is not working, shall we let culture just grow organically? If it becomes a destructive and negative shadow, not a good way forward either…

From experience, I do believe in a third option which we call “Culture Hacking” at Dark Horse. The underlying principle is very similar to the ones of behavioral therapy in the mental health space: in order to change your thoughts, you change your behavior. You try to replace it with “new behavior” and hence getting to “new thoughts”.

For culture, this translates to this process: to change your culture, you change your behavior. You model “new behavior” through cultural hacks & tangible artifacts in the hope of getting to new cultural characteristics.

For example: if you want to design your culture to become more experimental and accept failures as “fastest way of learning”, you could introduce a failure award and hand out considerable prizes for the best failure aka. learning. You change your form and you hope your shadow will change accordingly. If not, iterate on the form.

Where to start designing culture?

If this interdependency exists between the OS as the organizational structure and its shadow companion, culture, the ultimate question is: where to start? If changing the OS could be overwritten by culture (“culture eats strategy”) and if starting to change culture will be blocked by rigid structures, how do we break that vicious cycle?

At Dark Horse, we borrow the Lean StartUp terminology of “Minimum Viable Products (MVPs)” and reframed it to match our context here: a “minimum viable change (MVC)”. 

The idea of an MVC is simply that there are some tiny, white spaces of opportunity, in which a subset of people actually accept a change of sub-culture because they believe it will improve their way of working. That implicit need for change can be met with an MVC, a minimal change of structure with the goal of slightly changing the OS to aim for a slightly changed shadow.

For example: let’s assume we have a small team in the finance department and they have a common feeling that the standard feedback process is not really satisfying (the need), we could start experimenting with new ways of feedback systems (e.g. 6×10 feedback, 360° feedback,

Work out loud, etc.). Once the team starts experimenting with that feedback system (MVC), they observe that this system encourages its team culture to be more honest with each other and supportive (the shadow is changing).

That new culture intensifies their feeling of “psychological safety”, which in turn gives them new white space to experiment in other areas as well (e.g. salary, etc.). For instance, the Google Re:Work framework shows the positive effect of psychological safety on the overall team performance and how to improve team culture in other areas.

That can result in a snowball effect of changing culture, not only within that team but in adjacent teams as well. Finding the sweet spot of change and the appropriate minimalistic intervention called MVCs is a tricky thing, but it can yield enormous results.

Misunderstanding OS and apps

Another misunderstanding I usually observe when talking about the OS of organizations is the interpretation of apps. What is an app, when applying the metaphor to organizations? I heard two main directions so far:

1. Apps are the products & services of your organizations. Apps are how you make money. Apps are your customer’s touchpoints.
2. In contrast to the notion above, apps could also be the sub-elements of an OS. Just like in the OS canvas there could be a compensation app, a feedback app, a decision-making app, a hiring&firing app, etc. For example, Holacracy is building on that understanding. Consequently, the Holacracy community is offering an app store to improve your operating system to your own organization’s needs.

If we consider the analogy here (let’s say the iPhone), both interpretations are fitting: Apple and the iOS acting as the “operating system” is offering the reach and ability to drive revenues. However, Apple is also offering its own apps as extensions of their OS (Home App, Where to find App, iMessage, etc.).

My point here? The metaphor is just not super clear here and offers space for misunderstandings. A simple solution here is to quickly talk about the understanding of “apps” in the context of organizational design.

Who is programming the OS?

Apple’s iOS is developed by its employees with the focus on offering the best experience to its customers. The interesting design question here is: how knows better what the “best experience” really is? The designer? The user? Both?

A similar question emerges when talking about the organizational OS. Who is designing the OS? For whom? At Dark Horse we say:

The OS cares about its employees. The employees care about the customers. Or: Money follows happiness.

So, what’s missing here? I think this notion can have a rather paternalistic touch and can push the responsibility of a working OS to its developers only (which is basically true for Apple).

However, I do think employees have an important role to play as well. Through their individual skills, attitudes, the ability for self-reflection and the ability to see the greater good rather then the own ego, employees can actually lay the basis for more advanced OS designs.

So I don’t think it’s a binary effect of “great OS leads to happy employees”. I also believe “skilled employees lead to great OS”. This interdependence makes the design of OS so challenging because it’s always addressing a personal level of employees as well (german readers: we can highly recommend this book dealing exactly with this topic: New Work needs inner work)

Bias for self-organization?

I usually stumble upon the OS metaphor in the area of self-organized teams and decentralized organizations. I don’t believe that’s a coincidence as the metaphor uses the same design principles as self-organized organizations do:

• Decentralization through the design of interfaces: While Apple is designing interfaces (like the SDK) for developers so they can run their app business independently, this is often the case for decentralized organizations as well (like Haier, Buutzorg, etc.)
• Small teams focus on customer needs: For Apple, these are the developer teams or agencies. For organizations, these are the business units or agile teams. They have a highly designed space of autonomy in which they can operate independently. The goal here is to better react to ever-changing customer needs.

While these are great design principles in a volatile VUCA environment, they are not necessarily the best in a world of mass production, low customization needs and efficiency goals. However, the OS metaphor should still relate to those companies, they have their shadow of a culture as well, haven’t they?

Final thoughts

The OS metaphor is a powerful metaphor for organizational design. It empowers employees, it encourages positive change for a better workplace and ultimately drives the notion of #FutureofWork / #NewWork. But it has its merits and can lead to misunderstandings.

These misunderstandings can transform it into yet another blurry buzzwords, that nobody wants to work with. My wish here is, to not go down that road (again) and clear out those potential misunderstandings right from the start of any OS discussion 🙂

🐎 Yay, you came all the way to the end. If you have the feeling, this was not a complete waste of time — fabulous! Then you might like our newsletter as well (german only so far, truly sorry 😬):