Disruption and Its Discontents

I don’t think I have stage fright—rather, a simmering sense of light dread, which I usually quell by replaying my presentation over and over in my head as the day approaches. Considering this ritual, it would probably make sense to reuse some of my presentations instead of rewriting them from scratch each time, as is my habit. Not very practical, I guess.

But what I do find practical is a method I use during presentations. When speaking to larger crowds, I select a few friendly faces—one or two from the edges, a few in the middle. Making eye contact in turn with this newly formed posse lets me sweep the audience while keeping my energy high. Of course, this sweep also gives me glimpses of those yet to be converted: the ones who didn’t want to be there in the first place, the ones drifting off mid-sentence.

Winning over the majority, even if only for a few minutes at a time, is an invigorating feeling. When it comes to the digital twin, which forms the bulk of my presentations lately, there are two primary topics that seem to unify the crowd. The first is real-world applications: not theory or narrowly focused academic cases, but examples where the twin became part of an actual system—a facility, a hospital, and so forth.

I believe this is because the audience knows, just as I do, that we are dealing with a disruptive technology in the digital twin. In a way, we are kindred spirits, united by a shared hope that this disruption of the status quo can bring about real improvements, open up new processes, redefine spaces, and more. But that only happens if the initial shock of disruption gives way to the steady rhythm of acceptance and integration.

Just as we bask in the source of excitement, we also huddle together in apprehension. The transition to acceptance by the final users (even when we ourselves are the users) is never guaranteed. In fact, over the past few years, I’ve noticed that funding in Europe increasingly emphasizes the acceptance criteria. Agencies seem to be saying, “We believe you’ll deliver the technology, but will anyone use it?”

Let’s get back to our audience and the sudden uptick in concentration when I start talking about real-world applications. Their palpable focus and follow-up questions suggest a desire to know what the digital twin’s users actually requested, whether the system was embraced, and perhaps most importantly, what prompted them to make the investment in the first place. Excitement isn’t too hard to generate, especially given the visual flair of the digital twin—but how do we overcome the hurdle of transforming that hype into solid action?

A quick disclaimer before I offer any answers or observations from a recently completed project. Each case brings its own unique blend of challenges, and one size definitely does not fit all when it comes to disruptive transformations. If you’re serious about disruption, be ready to embrace failure at any moment. It will come in many forms: hardware breakdowns, rejection, network issues, sabotage, red tape, apathy, and more. But they all share one fundamental trait — they impart useful lessons.

With that out of the way, let’s continue.

The digital twin was requested by a cafe chain (roughly 30 locations at the time the project was signed), to be implemented at their production facility as well as a couple of the cafe locations. The requirement at the production site was to use IoT for tracking coffee storage conditions (temperature and humidity) and monitoring gas pressure during the roasting process. The initial request for the cafe locations, on the other hand, was to analyze personnel occupancy across select areas such as the bar, seating zones, storage, and so forth.

It may seem like this set of requirements is enough to explain how the project came to be. In hindsight, though, I believe the main drivers were not the obvious ones.

When thinking about users and potential customers, there’s a tendency to focus on costs—specifically financial costs. That’s reasonable: if the user doesn’t invest in the system, then it’s likely to remain a research topic or a showcase. But we should be careful not to develop tunnel vision around this point, because there’s more to it than meets the eye.

For quite a few years, myself and those around me were textbook examples of this tunnel-vision approach. We presented our technology through a list of powerful features, the benefits they would bring to the user, and why the financial investment was justified. All of this is vital—but it’s hardly the full picture.

Cost goes far beyond financial resources. Each time a disruptive technology is introduced into a functioning ecosystem, it demands other resources: the time needed for learning, the chaos of initial setup, the challenge of integrating with different stakeholders, and the effort required to form new routines around the technology.

This is a critical point. Many industries—and, in fact, many aspects of our personal lives—run on a set of habits, routines, and rituals that fall somewhere along a spectrum: from lifesaving to beneficial to inefficient to downright detrimental. We’ll let the coffee brew for a bit and make a quick visit to a hospital to illustrate some quirky management routines.

Unhealthy Habits in the Hospital

Several years ago, I conducted an analysis at a modern hospital equipped with a solid IT backend, a comprehensive management system, and a surgery department handling a high volume of operations each day. The optimist in me (still very much the engineer) wanted to learn more about how such a complex system managed to hum along. But that optimism quickly took a back seat, and the critical analyst took the wheel as I began to notice some odd quirks in the surgery preparation routines.

Prior to each surgery, a list of consumables (sponges, blood units, towels, etc.) and tools (scalpels, ultrasound probes, etc.) was provided by a system through a digital spreadsheet, which was then printed out as a set of barcoded stickers. The large number of items guaranteed that the stickers—tiny as they were—completely filled up a clipboard.

As each item was added to the surgery cart, the corresponding barcode would be scanned. So far, I could partially see the logic, as this fast-paced theatre might not be favorable to handheld digital devices. But then the weirdness began. Once the setup was complete, one of the nurses took the clipboard back to another station, where a different operator began scanning each barcode into a separate digital system.

Well-developed digital systems should make life easier, faster, and more robust. I’m sure the systems at both ends were capable of detecting errors, linking surgery data with the patient and procedure, and feeding hospital administration workflows. But instead of preserving these advantages by connecting the two digital systems, the hospital had introduced a risky, time-consuming, and redundant bridge—made out of printed stickers.

I could list many more examples across various domains I’ve worked in over the years, but the common question is always the same: “Why? Why would such wasteful routines be used to glue together parts that are actually quite efficient and robust?” I think there are a couple of important reasons.

In some cases, there’s a sense of ownership, as these methods—perhaps developed under the pressure of looming deadlines—were created internally to keep the boat afloat. Even if they only partially worked, having a voice in the system and the agency to make changes (themes I return to often) is a powerful incentive. It’s a classic “devil you know” situation. In this case, it may be more accurate to call it “the devil you create.”

The second factor, equally powerful, is habit formation. Repeating a task over and over, while receiving occasional positive feedback, creates neural grooves (imagine train tracks) in our brains that make the task easier. As inefficient as these stopgap solutions may be, they often aren’t as cumbersome as they appear to an outside viewer.

Could both of these criteria be satisfied by objectively better solutions? No doubt. And that’s why a flexible, comprehensive system that invites co-creation is so important. We all know what I’m referring to at this point, right?

But if these stop-gap solutions appear to be juicy leverage points for conducting business, I would advise caution. As paradoxical as it may seem, I’ve noticed that these band-aid fixes are sometimes defended with more vigor than the robust elements of a system. The resistance that develops around them becomes a surprise cost in setting up any new solution.

Let’s get back on track with a short summary. The cost is more than money—it’s the need to break deeply embedded habits and routines, the very ones that keep the engine running, albeit inefficiently and always at risk of falling apart.

This hidden cost gives way to a pain point when certain individuals in the organization (usually in upper management) start to notice cracks forming in the functional system. These people feel uneasy, sensing a weakening in the chain of operations, but they’re unable to determine exactly which link is at fault. Poring over reports and holding regular meetings is usually not enough to cut through the fog of daily operations or to uncover the finer details that might hold the key to a solution.

It was therefore not too surprising that the foremost request from the administrators at the cafe locations was to create a movement heat map of the personnel. In essence, digital cards carried by the cafe staff would indicate their approximate location—basically at the room level, not exact coordinates—in real time. This information would be stored in a database and used to analyze the occupancy of various zones within the cafe.

The request had two purposes. First, to ensure that the bar area always had at least one friendly face available to greet patrons. Second, to make sure the restrooms and the deck area were visited regularly by staff in order to keep them clean.

A quick note about privacy, as the topic almost always comes up when I present this project. The scope and purpose of the work were clearly explained, and personnel consent was obtained prior to any data collection. In fact, all position data was anonymized, with no reference on our part to any personal identifiers—no names, IDs, or anything of the sort.

Let’s continue with the first wall we hit after setting up the system. In one of the locations, data was flowing in perfectly—clearly veering into “too good to be true” territory. The bathrooms were getting cleaned so often it might have been safe to use them as operating theatres. This was likely the result of behavior changes triggered by the presence of sensors, and we were confident that routines would soon settle into something more realistic.

Eventually, more meaningful numbers began showing up on our graphs, but engagement remained strong regardless. I believe the primary driver of this successful implementation was the manager, someone who not only believed in the project, but also had the leadership presence to carry that belief over to a team that respected her. A great stroke of luck for us.

The other location, however, was a different story. There seemed to be a hardware issue almost daily—whether with the gateways, the internet connection, the use of the digital cards—you name it. In fact, I had selected this location specifically. I had visited multiple times over the years, even before this project was an idea, and during each visit I felt like I was intruding on a grumpy person’s living room. My inference that the staff would be resilient turned out to be true.

After spending some time as a short-sighted engineer—focusing on tweaks to the hardware setup and other minor adjustments—I eventually realized that having direct conversations with the cafe staff made much more sense. It didn’t take long for the mistrust and resistance to rise to the surface. Some members of the staff were clearly upset by the fact that their positions were being tracked, regardless of our assurances that the data was anonymous. Some even thought the devices recorded audio, which was clearly not the case.

Actually, it was only clear to me and my team. We understood the hardware, the communication protocols, and the application layer. We knew the journey of a BLE signal from the electronic realm to the code. But why on earth hadn’t I thought it important to walk through those steps with the cafe staff?

But I felt there was something more to be unearthed here.

Bigger Audience for a Bigger Picture

There’s an unspoken viewpoint that seeps through the cracks during conversations with higher management. A higher position in the hierarchy tends to bring with it a sense of the bigger picture, even if parts of that picture remain fuzzy. Managers who want to make real changes often try to combine the best of both worlds by also studying specific operational details. There’s merit in this approach, and perhaps it’s one of the key reasons why administrators are drawn to the digital twin—it allows them to quickly shift between levels of detail. Up to this point, I’m fully on board.

But as an extension of this perspective, most administrators don’t seem inclined to share either the big picture or the detailed view of specific processes with the personnel involved in those very processes. To them, improvement often means tweaking procedures, guiding the workers, or providing new resources. Sometimes it even goes further, taking on an antagonistic edge—as if their role is to safeguard the greater good of the institution, while the on-site personnel require a different kind of motivation or supervision.

I’m not on board with this approach. At nearly every level of a complex operation there are foggy, unclear parts. If we return to the cafe example, when a regional manager wants to see how often one of the upper floors was visited by a cafe “runner” (similar to a busboy at a restaurant), he might assume the staff already have this knowledge but aren’t utilizing it properly.

In fact, they usually don’t. During the rush of a lunch break or an evening crowd, the possibility that a specific area could be neglected may cross their minds, but it often gets pushed aside in the heat of service. A system that shows them, in real time, that the floor is clean (giving them peace of mind to continue other tasks), or that provides simple, actionable feedback to facilitate responses—and perhaps even automates task scheduling for optimal service quality—would do wonders for the staff as well.

I believe that a majority of us wish to have an impact, even as certain tendencies pull us toward comfort and unaccountability. To have a sense of agency in a system teaches us to do important tasks. It makes us a vital part of our social fabric, whether in the workplace, family, or other places. Agency requires that we are exposed to the systems—such as our workplace—with greater scope and detail, so that we learn where we can have impact.

If you’ve ever worked with administrators who have a good sense of their domain and the ability to change conditions, you’ve likely noticed their strong drive to utilize that agency often. I think it’s a positive kind of passion, one that promotes a cyclic growth between the individual and their domain. But where I usually differ from most is in the belief that this element should not be reserved for a few. We should make an effort to increase visibility and understanding of the system across the hierarchy, so that those (even I know this will not be everyone) with an inclination toward this mutual growth are given a chance to become a part of it.

This final point, and the cafe project, are both areas I would like to revisit, as they still have more to offer. Until our next meeting, take care.