Reading about Isolde and Emanuel led me to realize how often organizations try to force one “right way” of doing things, even when the situation clearly calls for nuance.
Isolde’s company, Siiquent, sells to hospitals and diagnostic labs which make money on selling the machine cheap and profiting on the consumables. It works because hospitals care about cost control and predictability, not customization. Emanuel’s Teomik, on the other hand, caters to research labs and universities. His unit makes profit on the machines themselves, since researchers are willing to pay for performance and flexibility.
So while both sell similar products, they’ve evolved totally different revenue logics that mirror their markets. It feels strange to ask the two to merge their revenue model together and abandon the other one.
Peter, their boss, thought a single model would simplify things. From a management standpoint, that makes sense since you have one clean strategy and not two conflicting ideas. But Isolde and Emanuel argued that this kind of uniformity kills responsiveness. Their teams succeed precisely because they adapt. As Isolde put it, “stuff or machines is a false dichotomy.” That line was pretty impactful to me since it’s easy to overvalue structure when you’re in a managing position at the top, but for people doing the work, rigid strategy is a constraint not a helpful guide.
At the same time, their “just be flexible” mindset has limits. It can lead to chaos and confuse salespeople and customers. So the real problem isn’t choosing one model over the other, it’s figuring out how to balance adaptability with alignment.
If I were mediating this merger, I’d start by helping both leaders map out their customer journeys and revenue logic so everyone can see the differences clearly. Then we’d identify what success looks like for both markets and brainstorm where overlap exists. Instead of enforcing a single model, we could test small hybrid experiments. Let one product line run on the consumables model while another focuses on the machine model and see what actually works.
What I took away from this case is that too much structure kills creativity, but too little structure leads to chaos/complexity. I feel like Peter didn’t need to choose between machines or stuff, but instead design a process that could handle both.
