How to spot theater
A self-defense guide against buzzword bingo
Every now and then, leadership in big companies announces that “we want to fundamentally change how we work”. As employees, we hear a lot of concepts and approaches being mentioned: Agile, Scrum, DevOps, OKRs, Value Streams, Empowered Product Teams, the Product Operating Model... Experienced change agents know the risk of just using new labels for the same old ways - in other words, transformation theater. How can you tell the difference between "the real deal" and buzzword bingo, even if you are not an expert on the topic? And what can you do to improve the situation? That is the goal of this article. It will tackle:
What to watch out for (testing for the symptoms)
Getting to the sources (becoming knowledgeable)
Options for the next step towards (positively influencing the environment)
Work life is too short to be wasted. Let's make it count!
(This is an article version of a talk that I gave during the Techforum eXplore France in Seclin, 2024-06-18 - 2024-06-19. The talk has been published on YouTube since then.)
Safety instructions
During the Expert Community Summit in May 2022, Worldline’s then Deputy CEO Marc-Henri Deportes asked the experts "to disturb and disrupt". What follows is a contribution to this request - within healthy boundaries.
As IT Security expert Felix von Leitner (aka fefe) says: "A good consultant will not only tell you what you want to hear but also what you need to hear." This article features content that is largely of the latter category.
Any criticism that follows is about patterns, not people. It would not be fair to single out persons in public without them having a chance to disagree and present their arguments. It also does not help to frame a problem to be about specific individuals, as this would assume the "solution" to be on an individual level (instead of a systemic one). If any point presented here seems familiar, then it only shows that it is a fitting pattern for the specific situation.
And lastly, you could present all of this content in a very harsh, serious tone. But how attractive would that be? Would this inspire action or conversation? Therefore, I aim to do it with style and with a smile!
What is Theater?
I define theater as the difference between “what is said”, “what it means” and reality. This does not mean that it is done on purpose. Always assume good intentions! The important element is: We can do better than that!
Let's explore the concept using a historical example: The German Democratic Republic (GDR) which existed from 1949 to 1990.
Using a picture that James Birnie brought up in his talk "Agile Is A Dirty Word", imagine a consulting company performing a "democracy assessment" on GDR - just like they are done on companies these days. The results would have looked great:
“Democracy” is part of the name!
They have a parliament!
There are several political parties!
Regular elections are happening!
The country has great reviews (at least the internal ones…)
So was the GDR a state that was very mature on its "implementation of democracy"? Of course not!
The truth was very different. The serious reality was a country where protests were shut down violently (17th of June 1953) and over 140 persons died while trying to cross the Berlin Wall alone. People like the young woman Marienetta Jirkowsky, the baby Holger H. or the young man Chris Gueffroy - one of the last ones to die, in early 1989. I chose to name some of the victims to not talk about a bad political system in general but to make the consequences very clear. This is how theater looks like. At least we can learn from history:
We can spot theater because it only uses weak signals. Those are easy to show and easy to fake: Labels and specific use of language, artifacts, and showing only successes. When something is real, there are additional, strong signals that are harder to visualize and hard to fake: Leadership behavior, capabilities of those below, and trust.
In the case of GDR, you could easily see that its population was not able to change its government without bloodshed. Leadership isolated the country from the Federal Republic of Germany (FRG) and took away the freedom of people to leave if they wanted, thus showing it did not trust its own people. And in return, the people did not trust those above, some even risking their lives trying to escape.
You might say that in politics, there is always some level of theater in play. So why should we care? Theater is a huge waste on human potential. Emotions like fear and anger are normal and not negative in and by themselves. However, leaving people in a continued state of confusion, anxiety, paralysis, bitterness or demotivation is definitely bad and will eventually impact financials.
So what to do in times of theater? Don’t give up! (On a side node, this is also a great song by Chicane.)
There is always something you can do! If you see strange things going on, you are not alone. You might only be unaware of the others. Finding them and connecting is the first step out of it. Prepare yourself for the times that theater is over. When the opportunity for real change is there, you want to be ready. Therefore, do not shut down but keep looking for signals that something is on the horizon that is worth your time and energy.
Spotting theater, a classic case: Agility
Agile Theater is well known by now. It still happens. Leadership says things like:
"We have to become more agile."
"We want to go faster."
These statements might be made with the best of intentions, but they do not mean anything regarding the topic of agility. All too often, agility is misinterpreted as something that happens on the team level, while in reality, it needs to be measured at a higher level. It does not matter whether a team can turn a confirmed need into a piece of working product within a couple of weeks if upstream and downstream, there are approval gates and decision points that create waiting times of months.
As a striking example of this truth, watch Klaus Leopold's talk "Why Agile Teams Have Nothing To Do With Business Agility" from 2017. (If you want to ruin the surprise, skip to 18:30 to see the picture.)
One costly signal for agility is looking at customer outcomes. Which opportunities do we spot and explore? Do we iterate on our proposed solutions? How fast can we learn from and implement feedback? Another hint for the "real deal" is a culture of continuous learning with regular updates. This includes sharing what did not work as expected - which can be 80% of our experiments. Finally, managers becoming leaders is a significant signal. (More on the topic in my talk and article "Training Agile Leadership: lessons from the trenches".)
Spotting theater, still going strong: DevOps
While Agile Theater has been vastly spotted, DevOps Theater is still booming. Typical things that leadership says:
These statements do not mean a lot and can even lead to the opposite of what is intended. How does the theater play out?
The picture that is usually drawn to make the case for DevOps is one where within a company, people in different functional silos are busy throwing stuff over the wall: Business / Management / Product to Design and Development, from there to Operations, and finally to the Customer / User. Everyone in the middle is unhappy, the people at the end are sad, and the top is usually angry. That answers the question "Why DevOps?". Unfortunately, that is not what you might get. Instead, you end up with...
DevÓPS!!!
The "solution" to the situation before is: Instead of people just throwing stuff over the wall, now some of them are also involved in throwing stuff back over the wall. The situation now is:
Ops is always louder than Dev.
It is always disrupting.
After a short amount of time, it gets very annoying.
In other words, somebody decided that it must the developers' fault, so they get more stuff to do. As a result, they are even more unhappy now. For some functional silos, this is better than before: Information Security, Customer Support and Infrastructure are limited to throwing stuff at Development & Design, but at least they are in the picture now. Meanwhile, the software developers look like this:
They are always afraid that someone will interrupt them by throwing a signal, an alarm, a question, an incident or anything else at them. Nobody is happy. The silos are busy managing the same fragmented ticketing system, only getting more of them by adding monitoring and alerting. Nobody can grasp what is really going on.
This is not the only way it can go wrong. There is a whole collection of DevOps Anti-Types collected by the authors of Team Topologies.
Real DevOps would mean looking at the overall flow. (Think of the picture in the aforementioned Klaus Leopold talk.) What was missing in the antipattern was the feedback loop from Development saying "we have too many things to do at the same time" or "we need to improve the overall process" or "we would need another way of getting this done" if we want to get work done fast and with high quality.
Feedback loops that can be started by anybody is one of the most important concepts of DevOps - not speed per se. Another crucial element is looking at the whole system. In the bad picture, developers were made responsible, but not empowered to take decisions (that would have brought down some of the silos, for instance). This imbalance of power and responsibility is a good hint of what is going wrong.
How would you know that DevOps is meant for real? A very easy test is provided by Gene Kim's article "The Three Ways: The Principles Underpinning DevOps". The three DevOps principles are:
Flow/Systems Thinking
Amplify Feedback Loops
Culture of Continual Experimentation and Learning
You want to improve the overall system by improving overall flow. You want to close feedback loops earlier. Anything over a month is usually worthless because the cause-and-effect relationship is no longer clear and people forgot about the topic because too many others have come up in the meantime. The experimentation needs to happen on a small scale, at a low cost so that learning is safe. For all of this, you need a transparent, up-to-date overall look at how things are.
These topics are explored in more detail in the Accelerate book which summarizes empirical research on what influences what. In case you don't want to read a whole book (immediately), there is a 2-page PDF about the overall research program. I pull it out every time I am talking about DevOps with someone. It highlights some bigger truths that often gets lost in the discussions about tools and practices: On the very left side, you have Transformational Leadership. On the very right side, you have Organizational Performance (amongst others). The fancy technology terms are somewhere in the middle - playing a role but not being the deciding factor on its own. In other words, empirical science has proven that leadership style and behavior influence everything else, including how an organization performs. Leadership matters!
Can it get any better? It does! During the TechForum Iberia in May 2024, I asked Cyrena Ramdani from Google about her view on DevOps. For her, the most important things are:
Reflection
Continuous Improvement
DORA metrics
A tech person giving a 0% tech answer on a topic that is often confused with technology. DORA metrics are not about Dora, the Explorer, or Digital Operational Resilience Act, but the set of standard metrics used in DevOps. In case you are unfamiliar with them, watch this talk from 2023 by my colleague Carlos Da Silva!
Carlos Da Silva: DevOps metrics and why we should care as developers
Spotting theater, high potential candidate: Product Operating Model aka Product-Led Company
Compared to agility and DevOps, this was a more controversial example when I was giving the original talk that is article is based on. Back then, Marty Cagan's latest book was three month old and these terms were all the rage. The months that followed backed up my forecast with evidence that like every other popular new concept, these labels would be subject to theater. In November, I closed my year of blogging with an article of the Product Operating Theater Model, calling it "The Product Organization Model of the year".
The theater gets played out by people making statements like:
“A radically different, new approach!”
“We will work based on Value Streams.”
“Empowered Product Teams!”
This can come from people who really mean it and want to make a difference. Unfortunately, these phrases have no value on their own.
The first hint that something is off here is looking at the wording. Wasn't empowerment already a popular term in previous ways of working and communicated organizational values? Why would we need a new approach for doing what we already wanted to do? I admit that I am speculating in my explanation. Nobody will disagree with positive values like "empowerment". The trickiness comes in when you need to make a choice between two of them when they are conflicting with each other, as expressed in statements like: We value “empowerment over control”, “innovation over plans” or “trust over deadlines”. The moment company leadership chooses between one of the two is when their true colors are shown - regardless of the label under which this happens. Only in leadership behavior, values can become principles that guide the actions of others. What are we saying "no" to? What are we willing to sacrifice? These will be difficult decisions!
While Value Streams are not literally mentioned in the Product Operating Model, if you want to improve "time to money", you will need to inspect the overall flow. (Yes, the same picture in the aforementioned Klaus Leopold talk comes up again.) And while there might be many different definitions of what a Value Stream is, it comes down to visualizing, measuring and improving the overall flow of potential value. Taking this concept seriously means mayor organizational changes, both on structures and processes (especially budgeting, goal-setting and measuring success!). Keeping existing teams mostly intact and calling them "Value Streams", "Empowered Product Teams" or whatever is of little use if a lot of decisions and steps remains upstream and downstream. Yes, the overall flow will not be a single linear one, and you also want to have the customer or user in the picture, and draw feedback loops back. How fast can we act on an opportunity? How fast can we test an idea to see whether it has some merit? How fast can we adapt based on the feedback from a customer? "Time to incorporate feedback" would be a critical metric to measure and improve. Without this transparent view existing and creating follow-up action, anything labeled "Value Stream" can be safely filed under "theater".
The déjà-vu moments do not stop at the concept of Value Streams: Without them being stated in the exactly same way, there are many ideas expressed in the "principles" behind the model that sound familiar. They had been published earlier under different names, like shorter feedback loops, continuous improvement, a learning culture, or managers becoming leaders. As it turns out, under a new label we are getting old and well-known content from Lean, Agile and DevOps, a lot from the 2nd half of the 20th century, some of it as old as two generations! Sure, these ideas are radically different from how things are usually done in big companies and thus hard to implement and keep alive - but they are anything but new.
This might sound impolite toward Marty Cagan and his co-authors. It is not. They say it themselves! In Transformed, page 7, we find the explicit confirmation:
"something we emphasize in each of our books: Nothing you will read in this book was invented by us. (...) We are effectively playing the roles of curator and evangelist."
Nothing new, except if you happen to learn about these ideas for the first time now and via this source - which is totally ok!
Nevertheless, there is one surprise in these books. When you hear "Product Operating Model", you might think that it will have the biggest effect on Product people. And yes, the three books are full of Product stuff, as expected. However, the biggest change will not come for Product - but Tech!
Marty Cagan has a lot of appreciation for Tech people, while giving harsh lessons to leadership (and many Product people). Product Leaders need to change radically, while Tech people finally need to get the respect and treatment they deserve. As an example, take Empowered, page 390 (also available for free as the article The Most Important Thing):
"[A] strong tech-powered product company would no sooner outsource their engineers, than they would outsource their CEO.
The best tech companies [...] all have dual-track career ladders for a reason. Their top engineers are generally compensated at the level of a vice-president."
This can serve as a great test to see whether an alleged "move to the Product Operating Model" is meant for real: How are the Tech people doing? Are they equal conversation partners at the table? Or are they seen as "only a part of Product" (which is wrong, see Petra Wille's book "Strong Product People")? Can they bring in their curiosity and problem-solving skills? Or are they still considered "receivers of orders" to build what someone else has decided? Is outsourcing in the name of cost still a thing?
(In case you wonder why a company would do better financially without going cheap on its people: You need to distinguish between the “cost per person” (which will be higher) and the “overall costs per product (team)” (which will be lower) resp. “overall value” (which will be higher). A handful of enabled employees will outperform a large group of outsourced people.)
So if you are a Tech person and someone talks about "becoming product-led", ask when you will see all these good changes happening that I listed above. Also note how this Product talk is against hero worship: It is about ordinary people who achieve extraordinary products.
Now what?
All this talk about theater might leave you disheartened. What can you do?
As a start, how do you survive theater? If, after applying these tests, you come to the conclusion that you are going through a phase of theater at work, do not despair: Even if you cannot avoid it, you have options.
First and most important: Do not use weak signals yourself. Do not confuse other people by using weak language.
Become knowledgeable. Learn the real meaning behind the terms. It is always better to know for sure than just having a gut feeling. Plus, there are books, articles and videos specifically about improving antipattern situations.
Ask questions. Bigger meetings, whether online or not, usually provide an opportunity for reactions. Do not ask your questions in angry mode - calm and clear is a good tone! A challenging question asked with a smile in a polite way is hard to dismiss. Leadership can hardly say that people are not interested if they encounter a high level of intellect and engagement expressed in a sophisticated question. The Q&A is often the most interesting part of a long session. You can tell a lot by the way the questions are answered - and not only you. Think of the gallery - that is, all the people in the meeting who are watching and listening. A good question has an eye-opening and unifying effect. Other people who are wondering as well understand that they are not the only ones. And if you say your name, they can contact you later.
This naturally leads to the next piece of advice: Seek out others. Connect with like-minded colleagues to exchange impressions and emotions. If there is interest, form a Community of Practice. This overcomes the feeling of being alone, lost and helpless. Even if you cannot change everything over night or solve the bigger situation: You have always more options being knowledgeable and with other people.
Find creative and constructive ways. Throughout my life, I have seen many people who became sad, bitter or who gave up. I do not think that this is the best way. I would avoid becoming bitter or sarcastic, because that will only attract the same kind of person and start a downward spiral. Some people blog about their experience. Apart from having a therapeutic or cathartic effect, there is a chance that the writing resonates with others. Plus, it is creative and active. It is better to work on something than remaining passive.
Now, surviving theater is not the real deal, as this is only dealing with the symptoms. The ultimate goal is overcoming theater in the first place. This requires two things: Leadership - and people who are willing to look through the mist and signal that they are ready. In other words, it is important that employees are approachable partners for management when the time has come for "the real deal". How often I have heard leaders doubting that the employees would be willing to carry the weight of a real change.
My own work experience paints a clear picture: Most people are aware of the specific challenges that a company is facing, they want to solve problems, and they are willing to put in their time and energy to navigate through tricky situations. Sometimes on the leadership level it is about overcoming fear and the illusion of control. Sending strong signals can resolve the doubts that massive change is not only necessary but also possible.
P.S.: Thanks to my colleague Martin Leucht for suggesting to make a phrase about the GDR example clearer.
Books mentioned
Agility
DevOps
Product
Marty Cagan, Chris Jones: Empowered - Ordinary People, Extraordinary Products
Petra Wille: Strong Product People — A Complete Guide to Developing Great Product Managers
Blind Guardian: Theatre of Pain - Revisited