Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Tag: organizational design

Conway’s Law Teaches a Grim Lesson About AI in Product Development
When I first stumbled upon Conway’s Law, it was anything but intuitive to me.

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
Melvin E. Conway

Why would an organizational structure of a company have anything to do with software architecture? After all, there are whole bodies of knowledge covering high- and low-level concepts of software development. Aren’t these things properly planned and executed?

I mean, sure, in the details, there will always be a mess. However, in a grand scheme of things, the high-level design should be far more controllable than the law suggests.

In retrospect, Conway’s Law is one of those things that, once you’ve seen it, you can’t unsee it.

Conway’s Law and Spotify Model

Whenever Conway’s Law emerges in a discussion, my favorite example is Spotify. I’m a user since the beta. I know several people who worked there in leadership positions. Most of all, Spotify, at some point, was very vocal about their organizational approach, the so-called Spotify Model. It’s like I have enough data to connect the dots.

As popular as it was at the time, if you look at the Spotify Model, it’s hard not to see it as a glorified matrix organization. Yes, there’s more autonomy across the board, but the communication paths? They all scream “Matrix!”

What should we expect from their product design if Conway’s Law is true? My best guess is a set of features interconnected in non-obvious ways, with a common issue of lack of alignment, and a lot of local optimizations. And that’s precisely what we get.

Spotify UX

While Spotify’s codebase is not open, its UX is quite telling. By now, it’s a clutterball of misaligned ideas fighting for your attention.

Playlist sidebar, announcements, recently played, made for me, music video, related music videos, now playing… Welcome to the Spotify home screen.

From a user perspective, it’s fascinating, although not in a good way, how I struggle to find the same options that I use regularly (like, multiple times a week, for years). Managing playlists? Oh, boy. Search? Every other time, it’s in the wrong context. Inconsistencies between mobile and web? Don’t get me started.

But maybe it’s just grumpy me. Fine. I’ve just literally googled “who loves spotify ux?” and among the top results are:
Doesn’t sound like a love wave, really. It’s either one: Google reads my mind, or the UX is problematic.

All that comes from a product praised (and copied) for some product innovations, such as Discovery Weekly or Spotify Wrapped. Most definitely, not everything is wrong here. It’s just a matrix of somewhat misaligned ideas, good and bad. That isn’t really a recipe for customer delight.

By the way, did you know that Spotify has a custom seek bar for Star Wars songs that looks like a lightsaber? And you can change the looks of the specific lightsabers, no less. There could hardly be a better illustration of “a matrix of somewhat misaligned ideas, good and bad.”

Communication, Alignment, Autonomy

If you consider Conway’s Law, it’s hard not to see how Spotify UX is a precise map for the Spotify Model. Wherever communication between teams (squads, guilds, chapters, or whatever the hell they call them) was messy and faced multiple conflicting goals, so did the interconnections between features.

To make things harder, Spotify sprinkled high autonomy over their feature teams. So the matrix organization made alignment a challenge, yet decision-making was pushed down the hierarchy nonetheless.

A high-autonomy-limited-alignment setup is not a recipe for effective work. And I say that from experience. At Lunar, we walked that path. The lesson? As much as I’m a huge fan of distributed autonomy, I’d always consider alignment first.

In the late 2010s, Spotify had a few dozen relatively independent feature teams responsible for specific parts of the product. Small wonder that the “mobile playlist” team had different ideas from the “web playlist” team. Communication paths that might have fixed that were watered down by an overly complex organizational model.

By now, the engineering headcount is already in the thousands, and the team count is thus in the hundreds. Just imagine the product mess that the Spotify Model would create. No wonder they largely abandoned it.

OK, but what does it have to do with AI?

AI Product Management

Product people are encouraged almost as strongly as developers to use AI extensively. It comes as a mixed blessing. Early intensive prototyping is a viable path, and it opens up whole new avenues for validating product desirability.

LLMs make it just so easy to create extensive specifications. We can attach all the existing product descriptions as context, let AI do its own research, analyze the codebase, and more. It will produce a nice, detailed description, and the engineers will nail it.

Except we misinterpret the ease of creation for the value of the output.

A sidenote: It’s the same aspiration we had when we tried to model systems with UML diagrams, and it didn’t work either. It’s not about the tools. It’s about the iterative exploratory nature of designing software.

Still, AI can create the same illusion we followed many times before—that we can specify software upfront in detail from the outset. The output looks good. Better than ever, even. And we get it effortlessly. It’s the AI model that does the heavy lifting.

It takes some time to realize that product development doesn’t work like this. It never has. And it has nothing to do with the tools we use to create specs.

AI Kills Communication

In the past, product specifications were brief. Save maybe for some Business Analysts, no one fancied writing long forms describing all the feature details. We relied on just enough context and communication between engineers and product people.

However, now, generating detailed specifications with AI is easy and cheap. Initially, we might even verify whether the output is correct. Eventually, we’ll give up. One, often they’d be good enough. Two, LLMs are great at creating outputs that sound sensible. Three, honestly, read a 4-pager with a feature description and tell me you understood everything.

At some point, and sooner rather than later, a product manager will stop carefully verifying AI output. Soon, the developers will follow. That is, given they read the extensive specs at all in the first place. It quickly evolves into the “you give me the specs, I’ll get them built, no questions asked” kind of scenario.

The key part here is: “no questions asked.” It’s like going all the way back to the 90s, way before Agile happened. We build up to the specs, whether it makes sense or not. The only difference is that we deal with the development so much faster. Does it matter, though, when we build the wrong thing?

Conway’s Law Meets AI Product Management

The most important change happened in between the lines, though. A one-sentence-long feature description was, by definition, full of holes and required the team to discuss. A detailed specification creates the illusion that a feature has been thought through from all angles.

The former invites communication. The latter discourages it.

As we close down communication paths, Conway’s Law kicks in. We’re bound to design architectures that copy organizational communication structures.

Less peer-to-peer communication and less collaborative exploration mean a more fragmented and less coherent architecture. As each individual is treated more and more as an isolated island, so will be the code that individual develops.

The effect will affect both a technical level (think code architecture) and a product level (think UX). Give such a way of working a couple of years, and we’ll start praising Spotify for its exceptional product design in comparison.

AI Is on a Collision Course with Conway’s Law

Dev: The last feature is on staging.
PM [checks the feature out]: It doesn’t work as specified! Here’s what should be different.
Dev [checks the code, checks the specs, 2 hours have passed]: Well, actually, it works as specified. Here are the specific parts that prove my point.
PM: Oh, my Claude must have hallucinated that part.

That’s an actual conversation that I heard that inspired this article. When I consider the impact of AI on communication, the paths connecting product and engineering are most affected. Yet, similar effects emerge across the board.
- A single developer may produce more code with AI tools, so they are more independent and, even under time pressure, they don’t need to collaborate with other engineers as often. We reduce the need for communication.
- Coding agents running independently step on each other’s toes way more carelessly, creating merge conflicts and triggering rework (the worst kind of rework, actually). Operators of said agents are thus better off when they isolate their active work areas. Which means less coordination and less communication.
- The asynchronous nature of working with AI agents incentivizes the “throw over the fence” hand-offs. My agent’s output may be ready when I’m already off, but let that not stop you from doing whatever you need to do with it. Again, less human-to-human communication.
- The sheer amount of documentation we can generate on different levels automates away collaborative activities (or parts of them). Code review? Let an agent handle that. Even less communication, perchance?
If Conway’s Law holds, we may be up for a rude awakening. As an industry, we are hyped about all sorts of “my agent talks to your agent” scenarios. It’s easy to see the upside—automating away the mundane, tedious, and routine. It’s hard to see the long-term cost of deteriorating communication paths.

So, we either learn to navigate the new realities of collaboration better, or we accept that the products we use will increasingly be crap. Which one will it be?

These posts are not generated. 웃 https://okhuman.com/nf1GGg
April 29, 2026
Why Wouldn’t an Intern Fire a CEO?

The question seems completely wrong. Obviously, because they can’t. An intern could not possibly let go of a CEO.

But what if they could? Would they? And if not, why?

Right now, you may be thinking, “But Pawel, what do you mean by imagining an intern could fire a CEO? It’s a completely abstract problem.”

It is not. In fact, at Lunar it is possible.

Radical Autonomy

I wrote about our radical way of distributing autonomy many times before. In short, anyone can make any decision (in a structured way). So why don’t people abuse that power?

Why don’t I need to worry that an intern would launch a letting go process for me?

And yes, they totally can.

While this decision is somewhat more complicated than the vast majority of others, anyone has the authority to start this process. Including people who joined us yesterday.

The Dynamic of the Organizational Culture

Whenever we join a new group, we tend to be more withdrawn than whatever is our norm. That’s one of the basic social dynamics.

First, we observe and learn. Subconsciously (or consciously), we look for patterns to understand the group’s norms. What’s acceptable? What’s not acceptable? What’s rewarded? What’s punished?

We orient ourselves in a new environment.

That’s precisely what happens in an organization when a new person joins. Even when rules as written say something, we observe whether it’s really so. After all, if rules contradict the norms, it’s the latter which prevails.

No one will fire the big guns before they learn to navigate a new environment well.

Peer Pressure as Safety Mechanism

OK, but the same intern will still not fire a CEO 6 months later when they already learned the norms. Why?

In a system based on distributed autonomy (again, anyone can make any decision; that’s the ultimate distribution), we have very different power dynamics.

We don’t have a person in power entitled to make the call, that entitlement being the ultimate get out of jail free card. After all, there’s no one else to make that decision.

In this case, anyone can act. But then, such a decision will be judged, challenged, commented on. If it’s controversial, let alone outrageous, people will be very vocal when opposing it.

Through that, we introduced peer pressure as a safety mechanism that basically prevents the most extravagant decisions from being made.

Reputation as Currency

What follows is that whoever volunteers to make any decision makes a bet. A bet of their reputation. If the decision goes well, the bet is won.

The more obvious the decision, the smaller the bet.

After all, if everyone thinks something is a good idea, it’s unlikely that they’ll complain, even if it goes sideways.

It’s a different beast altogether when the call is controversial. If I go against a big group, I better end up right, or my reputation as a decision-maker gets slashed.

Before anyone’s ready to make such a bet, they must accumulate some of that reputation. Which means they will have been around long enough that we no longer talk about an intern firing a CEO.

In fact, when someone is around that long, and they still want to fire me, well, they probably have some damn good arguments.

By the way, if you’re interested, the most radical proposal coming from a fresh hire we’ve ever discussed was changing the salary system. Admittedly, a serious call, yet it didn’t even reach a stage where it was an actual proposed decision. The person gave up way sooner after receiving peer feedback.

April 9, 2025
Figuring Out Organizational Culture

Some time ago, I had a lengthy exchange about how we work at Lunar Logic, which behaviors are OK and which are not. At one point in the discussion, I realized that the source of the different stances in the dispute was a very different perception of what organizational culture is.

Organizational Culture

When I’m referring to organizational culture in my presentations and writing, I typically use quotes from Wikipedia.

“Organizational culture is the behavior of humans within an organization and the meaning that people attach to those behaviors.”

“Culture includes the organization’s vision, values, norms, systems, symbols, language, assumptions, beliefs, and habits.”

Interestingly enough, over the years the exact phrasing of Wikipedia article on organizational culture has evolved so you won’t find identical words there anymore. Either way, the original quotes stand the test of the time.

If you need a more concise definition, I could propose something like “a sum of behaviors of everyone in an organization, or a part of it, and the reasons behind these behaviors.”

Even shorter: “how everyone in a group behaves and why.”

Building Blocks

From the perspective of a person who wants to learn an organization or to influence the culture shift, not all the building blocks are equal. It is near impossible to change people’s fundamental beliefs or core values. It is neither easy nor fast to alter subconsciousness. Habits, assumptions, and perceived systems often reside in the subconscious part of our thoughts.

What’s more, all of the above, except for some habits, aren’t easy to spot. Ultimately no one has their core values tattoed on their forehead, and very rarely we are aware of these inner drivers of others’ behaviors. It’s no wonder. No one teaches us to pay attention to that.

The most visible aspects of culture, and thus, the easiest to work with, are rules and norms, respectively. Rules, by definition, should be written down, so they are accessible to anyone interested. Norms are a bit trickier since they’re defined by what people believe is, or is not, appropriate. Either way, if one pays attention, it is not hard to derive organizational norms by merely observing what people do and what they do not.

The Role of Observation

Let’s assume that you’ve just joined a new company. You enter our office cantina and see me having a beer with my lunch. You realize that there was nothing about that in the rule book you read during the onboarding. However, a societal norm is that we don’t drink alcohol during work hours. How do you react? Most likely, you look at other people to probe their reactions. If they ignore my behavior altogether, it appears that it is OK for me to have a beer during lunch.

Note: it’s too little to tell what the norm is yet. It’s a decent first step, though. You may still want to watch whether other people do the same thing or instead I am a special case, and I can do things others can’t. Oh, and it may be relevant whether a beer was a regular or non-alcoholic one.

Either way, eventually, you have a good sense of whether you (or anyone else) can safely have a beer for lunch. You will derive that knowledge by merely observing and absorbing the environment around you.

Observation is indispensable too in the context of rules. Something can be written down as a rule and still get ignored. We could tweak the story above so that there is a rule, e.g., in the employment contract, that explicitly states that drinking alcohol at work is forbidden. This way we’d have a situation when a norm (having a beer with lunch is fine) contradicts a rule (it is prohibited).

The outcome would be the same altogether. The norms trump the rules. Without observation, it is neither possible to figure out the norms nor to learn which rules are there in the name only and which are the law.

Figuring Out Organizational Culture

If one aims to understand the organizational culture of a company they just joined, there is no real shortcut that would be an equivalent of prolonged observation. Some tricks may hasten the process, of course. Not too much, however. You can’t learn the organizational culture in several weeks. At best you can familiarize some parts, but it would be far from a complete picture.

Again, let’s imagine that you’ve just got hired. You joined a team of five, which is a part of a division of 40-something, and the whole company is around 200 people. Figuring out how to safely operate and behave in the closest neighborhood — your atomic team — should be a straightforward process. You’ll get plenty of opportunities to observe, and feedback loops will be short. You’ll have validation paths readily available through the means of chatting with your team lead and your peers.

This way, you would explore, however, only one small area on a big map of organizational culture. Yes, it is by far the most important for your everyday work, but hardly enough for a complete understanding of how to act in all situations, including some that may get you fired.

There are interactions within your division, both cross-team and division-wide. There are all sorts of rules and norms that apply to a company as a whole, or specific ranks, or even particular people. Discovering all these uncharted areas takes time.

The Tricks

There are a few tricks that can speed the exploration a bit. By no means, they are a substitute for awareness and observation, but they help.

The higher up in the hierarchy someone is, the bigger their influence over the culture. To get a roughly accurate, even if a vastly incomplete and imprecise, image of the organizational culture, you could shadow the company’s CEO for some time. Since the behaviors of higher ranks often get copied at lower levels, a sneak peek at the very top of the hierarchy gives you a potentially most statistically significant representation of the culture.

Ignore officially expressed company values, its vision, or a mission statement. It is such a rare case that a company indeed follows an aspiration expressed in either of them that they most usually are a source of noise, not signal. Look at the actual behaviors, not aspirational statements.

Seek conflicts and watch how they get resolved. Controversial situations require parties to take a stand, and thus, they trigger action. On such occasions, it is easy to see who calls the shots and whose opinions count. The friction that is an integral part of any conflict is a natural fuel for shaping and reshaping norms, challenging rules, and expressing less visible drivers of the culture: values, beliefs, and assumptions.

Ultimately, though, there’s no better trick than patience and perceptiveness.

Crucial Role of Understanding Culture

OK, but why is understanding the organizational culture so important? Unless we have a good grasp of it, we are bound to either traveling only through well-beaten paths or risking frustration.

Well-beaten paths are safe. It’s easy to follow what everyone else is doing. It means, however, that our influence on the organization would be limited to the face value of our everyday contributions. We wouldn’t be challenging or changing our team and our company. Typically, that’s perfectly fine, even expected, during an initial period at any organization. Later on, not necessarily so. At least not in a firm that hopes to use the potential of its people.

The other scenario is quickly jumping to the acting mode, challenging rules, status quo, opinions, behaviors; it’s a departure from a beaten path. The problem is when such a departure happens in uncharted territory. There are things which are appropriate and those that are not. There are norms, beliefs, assumptions, and values. Blindly flailing around means that we would inevitably violate these informal constraints.

This way we will, of course, uncover the part of the uncharted territory, but the price is high. One part of it is frustration: “Oh, we don’t do such things here; I wasn’t aware.” The other part is reputation. Opposing or challenging things with little effort to understand them first doesn’t score much respect. There is a world of difference between being a contrarian who understands the culture and one who doesn’t.

If we aspire to influence organizational culture eventually, learning it first is a crucial and obligatory prerequisite.

June 10, 2019
Cultural Fit versus Cultural Fit

There is a remark on hiring I’ve heard quite a few times recently. It’s about sending a rejection message to a candidate. It goes along the lines: “Just don’t tell them that they’re not a good fit for the culture. That’s bullshit. That means nothing.”

A Bad Fit

I can’t say that such a remark lands well with me. I do, however, understand where it is coming from. As the industry, we started paying attention to the culture. It’s on our radars. We may have only a vague understanding of what organizational culture is but it is already a part of the discourse. This vagueness of understanding of the concept actually comes handy when there’s no tangible reason to reject a candidate but we still somehow didn’t like them.

They are a bad cultural fit.

Whatever that means.

See, the problem I have with many of these statements is that they’re used as a bludgeon without much thought invested to why “we didn’t like” a candidate. Because of that we often throw the baby out with the bathwater.

A Good Fit versus Likability

When hearing about lack of cultural fit I often follow up ask what it means that a candidate wasn’t a good cultural match. The answer, most often, is something like “that’s a person we wouldn’t get on well with”, or “that’s not a person I’d like to hang out with”, or “it’s not my kind of a person”. These boil down to how likable a candidate is for an assessing person.

The problem is that likability is a terrible way of assessing cultural fit. Not only is it not helpful, but it is also counterproductive.

If we chose likability as our guiding principle to judge cultural match we would end up with a group of people similar to each other. They’d have similar interests, many shared views and beliefs, etc. We would be building a very homogeneous culture. An echo chamber.

Sure, there wouldn’t be much conflict in such a group. There wouldn’t be much creative thinking either. There would be premature convergence of the ideas, little scrutiny, few alternative options would be explored.

If we consider knowledge workers such a team would have appalling performance. Thus my problem with such a shallow understanding of cultural fit.

Shared Values, Diverse Perspectives

So what is an alternative? How to define cultural fit in a way that would yield a high performing team? General guidance would be to optimize for representation of different, diverse points of view while creating an environment where people are encouraged to contribute.

These two ingredients—diversity and enabling environment—balance each other in a way.

We want diversity to have an option to learn about other, non-obvious ideas. Such ideas won’t come from people similar to ourselves. We thus want to have a range of different people in a team. And when I say “different”, I think of different walks of life, different experiences, different beliefs, different preferences, different characters, etc. This might be translated to maximizing diversity.

However, diversity for the diversity sake is not the way to go. This is exactly where the second part kicks in. We want to sustain an environment where people share their diverse opinions, and not simply have them. For that to happen we need to have a common base that encourages people to feel comfortable enough to contribute.

That common base is a set of shared values. I won’t give you a list as I don’t believe there’s the way. There are many ways to build such an enabling environment. There are, of course, usual suspects: respect for people, emotional safety, or autonomy, just to mention few. The important part is that such a set of shared values provides an informal, and typically implicit, contract that makes it safe to contribute.

Cultural Fit

With that founding principle, the definition of a cultural fit would be very different. A good match would mean that we share core values but beyond that, a candidate is as different from current team members as possible.

This means that friction will happen. Conflict too. Not everyone will feel comfortable all the time and not everyone will be getting on well with everyone else.

This means that when we decide there isn’t a good fit we may come up with a much more tangible explanation why. It is because we don’t share values—e.g. we perceive a candidate as disrespectful—or we don’t sense any aspect in which a candidate would stretch diversity of the team in one of the desired dimensions.

Note: not all dimensions of diversity are equal. There’s little, if any, value in my experience as a sailor in the context of product development. There’s more value in, say, cognitive studies that someone else went through. That’s why I add a quantifier “in the desired dimension” next to “diversity”.

Some time ago at Lunar Logic, we rejected a candidate for a software developer role whose focus was purely on their technical skills. There’s nothing wrong in that of course unless this is the only dimension a candidate uses to look at themselves and at others. There was some mismatch in shared values, e.g. little understanding and appreciation for teamwork and collaboration. We didn’t see much diversity that they would add to the mix either—we already have quite a bunch of excellent developers.

Interestingly, the decision was made despite the fact that we liked the candidate and were getting on well with them. That’s a complete opposite of what a naive approach to cultural fit would suggest us to do.

We believe that we are better off with that decision. More importantly, we believe that the candidate will be better off too. As long as they find a company where there’s a better overlap in shared values not will they contribute more but will also be appreciated better.

March 5, 2019
Teal is the New Black

On many occasions, I’ve shared how we operate at Lunar Logic. We exploit radical transparency—every single bit of information is available to everyone at the company. We exercise radical autonomy—everyone can make any decision on the company account. We entertain radical self-organization—there’s no enforced structure or hierarchy, there are no managers, and the CEO role is purely titular. While it sounds extreme when you hear about it, it feels even more so when you live it.

Given that we went through a transformation from a rather typical organizational structure, we very well understand how many mistakes one can make when introducing such an organizational model. After all, we made great deal of them ourselves.

We didn’t use any of the labeled models when approaching our evolution. We are, however, very frequently dubbed as a Teal organization, as described by Frederick Laloux in his book Reinventing Organizations. I don’t necessary fancy the label as I’m not overly fond of the model proposed by Laloux. Nonetheless, the label is somewhat useful to communicate how we are organized at Lunar.

The interesting thing is how people react to Lunar Logic story. Over time I get more and more reactions like “oh, we’re working exactly the same way” or “yeah, we are Teal too”. This often triggers some questions on my end. Do you have transparent salaries? How do you set salaries? Do people know the contract details? How much company money can people spend without getting a permission? Can people leave the project they’re on when they want to? How is the strategy decided? Which decisions can be made by high-ranks only?

Inevitably, most of the answers are as expected. “We can’t let people decide to spend company money at their whim, let alone set their own salaries. That would ruin the company! We can’t even let people know what everyone else earns as it would trigger huge frustration. And obviously strategy, and many other important decisions, are prerogative of senior managers.”

Other than that, you are perfectly Teal, aren’t you?

Progressive Organization is an umbrella term I use to describe different modern approaches to redefine how organizations are designed. Declaring that a company is one of flavors of Progressive Organization became a fashionable thing. People aspire to have flat-structure organizations, and to empower people (which is a completely flawed goal by the way). When it comes to labels, Teal organizations are getting most of the buzz these days. It’s a trendy thing to say that an organization is Teal or at least aspires to be so.

Teal is the new black.

The problem is that little comes afterwards. Transforming an organization from a traditional, hierarchy-based model toward radical self-organization and radical autonomy (both being crucial parts of becoming a Teal organization) requires lots of changes.

I don’t necessarily say that fully transparent salaries, salaries set by employees themselves, freedom over choosing what people work on, no permission expected to spend significant amount of company money, or all the authority distributed to everyone at the company are all required to dub a company a Progressive Organization. I do say that, in one way or another, the way all these decisions are made need to be reinvented to be more inclusive for everyone at the company.

In most cases the disputed companies have no will whatsoever to challenge the old operating system where managers make vast majority of the important decisions. I even heard people explicitly stating that they were “somewhat Teal” and had “no will to become more so”. Why would they even refer to the label then?

Because Teal is the new black.

If I counted companies whose representatives declared that they work in a similar way to Lunar or that they are Teal I should be over the top. After all, I’m somewhat pessimistic about the pace at which the organizations would evolve away from the old, entrenched, century-old, hierarchy-based management paradigm. The reports I keep hearing should be a proof that the situation is far better than I thought.

I stay skeptic, though. The reason is that most of the reports are about Progressive Organizations in the name only. Hearing the stories, I’m not comfortable with as little as saying that it’s their genuine aspiration to evolve into a new organizational design. I would rather describe it as a pretense, and the one introduced on the weak grounds of fashion.

The outcome will be two-fold. On one hand we already see inflation of the commonly used terms, like Teal. When someone says “Teal” it means less and less over time as it’s used to describe lots of different things. It wasn’t a precise term to start with and the more popular it is the faster the watering down process is. It is the fate that awaits any niche concept that hits the mainstream. The term Agile is a canonical example. These days it is used to label pretty much anything.

Personally, I don’t care overly much about this effect, though. After all, I don’t have any stakes in promoting Teal.

I do care about the other effect and I believe it will be positive in the long run. Given increasing popularity of the idea, even without implementing it the proper way, we can expect that more and more people would become aware of alternative organizational models. While in the short run I still see little action to truly transform companies, awareness is something that will provide leaders and managers with options in the long run.

At the beginning of our way at Lunar we were inventing lots of things ourselves. There was limited literature about alternative models and none of us was into what was available. There were few stories of progressive companies, even though they exist at least since fifties. We didn’t know much where we were headed or what the desired endgame looked like.

Awareness of what is possible, makes it easier to plan the change. With increasing number of available stories of different Progressive Organizations, there is plenty of inspiration to design own model and run own experiments. In the long run this fashion will, I believe, have a lasting effect on how humane our organizations are. In the even longer run it will hopefully affect whole industries.

That’s why on one hand I treat Teal as a label that often bears little value but I’m happy that it makes its way to common awareness. In a way I’m happy that Teal is the new black.

September 5, 2018