Gameplay - Dealing with Toxicity

gameplay
theory
#1

In ideal conditions, you should never discover toxic assets in your organisations, because you know how to anticipate things. In real life, however, there are some situations where you will find assets that belong to a past business model and which have become not only your legacy, but they are also slow down your adaptation efforts. And what is most problematic, you should write them off - they are not assets, they are liabilities. Such a move is a sign of great courage as it will be immediately visible in a company balance sheet, and you will be to blame.

There is a number of standard moves that you can use in such a situation. Their applicability depends on the value of the “assets” and on the attitude of the market.

Forceful shutdown

You ignore everyone and push the self-destruction button. I would expect this happen a lot on a team level - a team is fired on the spot. For products and business lines it is more complicated but still possible - and MSFT sunsetting past Windows versions is one such example. The risk is however that customers may get angry, so do not attempt that unless you are covered from legal , PR and financial perspective.

Refactoring

Whatever is your value chain, whatever are your assets, try to identify components, and reassign what you can to other duties, and what you can’t reassign - sell or forcefully shutdown. While this can sometimes reduce your losses, it should be an ongoing activity, in the same way as code refactoring is a part of software development.

A good example may be VW moving combustion engine production from Germany to Poland. Besides tax incentives, VW will be able to focus on electric cars, build know how, and when the market for combustion engines ends, it will probably forcefully shutdown it.

Sweat and dump

If you find yourself in a past business model, and you see your customers going away, chances are you are not alone. So you can repeatedly merge with your competitors (one at a time), instantly fire the management team and redundant people (increase efficiency) and continue operations until it will be necessary to find another acquisition target. In other words, it is a technique of minimising losses that relies on centralisation of customers.

IBM’s acquisition of Red Hat seems to fit into this category.

Also, this is a very long process. A complete merger can take about 2 years. Assuming everyone is playing the same game, a market of 8 competitors gives you 6 years of life (3 mergers expected).

It is a good way of returning money to investors and consulting companies (they appreciate that), but a kiss of death to employees of acquired companies. If Sweat & Dump is affecting a significant portion of the company, it is almost impossible to overturn because short-term issues drain cognitive capabilities.

Pig in a poke

If you are fast, you can use asymmetry of information, start a PR/marketing campaign and convince everyone that your product, slightly modified, is the future. Then you sell the company, or the part of it, to the first buyer that asks for it, possibly because his/her market niche is drying. The combination of hopes, a pressure to find a solution, and clever marketing makes rational thinking very difficult.

IBM’s acquisition of Red Hat seems to fit into this category. Yes, it is the same example, but from a different perspective. What is a bad deal for IBM, is an excellent deal for Red Hat shareholders.

Evil evilness.

Prevention

While it is useful to know all those gameplays, they can be prevented with appropriate learning mechanisms. Unless, of course, the niche is so attractive that you want to cash it out while you can, and then purposefully sell assets that you know will be toxic.

1 Like
Mapping Glossary