When Everything Changes, Look for What Remains the Same

When Everything Changes, Look for What Remains the Same

I grew up in Pistoia in the late 70s and 80s. It was a town where the sound of the evening was the clatter of shutters closing and the distant, rhythmic hum of Vespas on cobblestones. My first real encounter with the digital realm happened on a Commodore 64 when I was eight. I remember the specific, high-pitched whine of the cassette deck as it struggled to load a program, a sound that felt like a secret handshake between me and the machine. You didn't just click a button and wait for a progress bar; you sat there, listening to the tape hiss, hoping the data would resolve without a read error. It was raw, tactile, and entirely unforgiving.

That environment - the wild, naive phase of the early internet, the era of X.25, QSD, and IRC - shaped me. It taught me that curiosity is a more valuable currency than credentials. If something wasn't explicitly forbidden, it was either a design flaw or an invitation.

Today, I work as the Director of Data Experience at CCH Tagetik. My professional life is a constant navigation of analytics, finance, and business transformation. I’ve spent years helping organizations move from legacy systems to modern, data-driven architectures. I’ve seen the hype cycles come and go. I’ve seen "digital transformation" become a buzzword that often masks a lack of real strategy. And yet, through all the shifts in technology, the rise of AI, the cloud, and the endless parade of new frameworks, one truth remains constant: the most interesting systems are the ones that reveal themselves only after you push on them.

When everything changes - when the market shifts, when the regulatory landscape evolves, when the tools we use become obsolete overnight - we tend to panic. We look for the next shiny object, the next "disruptive" technology that promises to solve all our problems. But I’ve learned that the most effective way to navigate chaos is not to chase the change, but to look for what remains the same.

The Architecture of Stability

I’ve worked on everything from SAS-based marketing data warehouses to complex financial reporting automation. I’ve seen processes that took two weeks of manual labor reduced to a single day. The technology changed - the tools, the languages, the platforms - but the fundamental problem remained the same: how do we turn large, messy amounts of data into something useful, reliable, and decision-ready?

Article content

Whether you are coding on a C64 or architecting a global financial reporting system, the principles of structure, elegance, and utility are universal. We often focus on the "new" when we talk about innovation. But true innovation - the kind that creates real, tangible business value - is rarely about replacing everything. It’s about understanding the underlying structure of the system you’re working within and finding the elegant path through the noise.

The Trap of "Transformation Theater"

I have little patience for empty buzzwords or "transformation theater." We see it everywhere: companies claiming to be "data-driven" while their data remains siloed and inaccessible; organizations adopting ESG frameworks that look more like greenwashing than a genuine commitment to values.

Article content

When we lose sight of what remains the same - the need for clarity, for reliable data, for sound logic - we fall into the trap of complexity. We add layers of abstraction, we implement tools that require more maintenance than the systems they replaced, and we lose the ability to actually understand how our business works. As someone with a background in theoretical mathematics, I’ve always approached business problems the same way I approach a proof: by reducing complexity. If you can’t explain the logic of your system simply, you don’t understand it well enough.

Finding the Constant in the Chaos

How do we apply this in a world that is constantly shifting?

Article content

First, understand the stack. Don’t just use the tools; understand how they work. Whether it’s a financial reporting engine or a new AI model, if you don’t understand the underlying mechanics, you are at the mercy of the vendor.

Second, question assumptions. Just because a process has been done a certain way for years doesn’t mean it’s the right way. But don’t change it just for the sake of change. Change it because you’ve found a more elegant, more effective way to achieve the same goal.

Third, focus on utility. Technology is not separate from strategy. If your technical implementation doesn’t solve a real business problem, it’s just noise.

Finally, embrace the craft. Whether you’re ripping and muxing anime or building a financial data warehouse, the quality of your work matters. Patience, obsession with detail, and a commitment to doing things right are timeless virtues.

The Human Element

I am a geek, but I am also a father, a husband, and a human being. I’ve learned that even the most complex systems eventually meet biology. My own struggle with hypertension is a quiet, daily reminder of this. It’s not a dramatic failure of the system, but a necessary calibration. I manage it with medication, a small, unglamorous tax paid to keep the hardware running. It’s a humbling realization that we are not machines, no matter how much we might want to optimize our lives like code.

The reality of my career has been a series of migrations - not just of data, but of mindsets. When I was at HP, working on legacy systems migration, the challenge wasn't just the code. It was the institutional memory embedded in those systems. People had built their entire workflows around the quirks of a commission data warehouse. When we moved to a new architecture, we weren't just changing the database schema; we were changing the way people understood their own performance. That's the "stack" in a business context: it’s the intersection of technology, process, and the people who live inside it.

If you look at the history of finance, the tools have evolved from ledgers to spreadsheets to CPM platforms, but the core requirement - the need for a single, reliable version of the truth - has never changed. That is the constant. When I work with finance teams today, I see the same anxiety I felt when I was eight, waiting for that tape to load. They are waiting for the data to load, for the report to reconcile, for the system to tell them something they can trust. My job is to make that wait shorter, and the result more reliable.

Article content

The "8-bit" approach is about respecting that wait. It’s about acknowledging that you can’t just "disrupt" a financial close. You have to understand the mechanics, the dependencies, and the human cost of the process. It’s about finding the one bit that, when flipped, makes the whole system more efficient. It’s the difference between a massive, failed transformation project and a series of small, successful improvements.

My obsession with anime and Magic: The Gathering wasn't just a hobby. It was a training ground for systems thinking. In Magic, you have a set of rules, a limited resource pool, and an opponent who is trying to break your strategy. You have to anticipate, adapt, and optimize. In anime, especially the early days of ripping and muxing, you were dealing with technical limitations - bandwidth, file size, encoding quality - and trying to create something better than what was available. You were pushing the system. You were finding the elegant path.

These experiences taught me that you don't need the most powerful tool to create the most impact. You need the best understanding of the system. You need to know where the bottlenecks are, where the inefficiencies hide, and where the potential for improvement lies. That is the essence of innovation. It’s not about the latest AI model or the most expensive software. It’s about the clarity of thought you bring to the problem.

When we talk about "transformation theater," we are talking about people who are more interested in the appearance of innovation than the reality of it. They want the buzzwords, the dashboards, the shiny interfaces. They don't want to do the hard work of understanding the underlying data, the process, or the business. They want a magic wand. But there is no magic wand. There is only the stack, the data, and the people.

So, when you are faced with a new technology, a new framework, or a new mandate, ask yourself: what is the constant here? What is the problem I am actually trying to solve? And how can I apply the principles of structure, elegance, and utility to solve it? That is how you navigate the chaos. That is how you build something that lasts. That is how you innovate, one bit at a time.

The future of finance, and indeed the future of business, will be defined by those who can bridge the gap between the technical and the human. It will be defined by those who can look at a complex, messy system and see the simple, elegant structure underneath. It will be defined by those who are not afraid to take things apart, to push on the edges, and to build something that actually matters.

We are living in a time of unprecedented change. But we are also living in a time of unprecedented opportunity. If we can keep our heads, if we can focus on the constants, and if we can apply the lessons of the past to the challenges of the future, we can build something truly remarkable. We can build systems that are not just technically sound, but that empower people, drive value, and create a better way of working.

This is the promise of 8-bit innovation. It’s not about looking back. It’s about using the wisdom of the past to build a better future. It’s about recognizing that the most powerful tools are not the ones that promise to change everything, but the ones that help us understand what really matters. And that, in the end, is the most important lesson of all.

The Commodore-64 metaphor lands. Where I'd calibrate: the constants you list aren't the only ones — the switching cost of anything that touches the operating model is the quiet one. Most "transformation theater" I've seen survives precisely because that cost is invisible until you try to retire a system. The bit that actually matters is usually the one defining the org's coordination overhead, not the one in the keynote.

Like
Reply

To view or add a comment, sign in

More articles by Francesco Morini

Explore content categories