My eight-year-old son was building a tower last Saturday morning. Not just any tower — he was determined to build the tallest Lego structure he’d ever made, one that would reach from the playroom floor to the ceiling.
I was half-watching from the couch, coffee in hand, mentally reviewing a client’s ERP implementation architecture that had been keeping me up at night. We were three months into a NetSuite rollout for a manufacturing company, and the technical debt was already piling up faster than we could address it.
Then I heard the crash.
Two feet of carefully stacked Legos scattered across the hardwood floor. My son stood there, frozen, staring at the ruins of twenty minutes of work.
“It fell,” he said, stating the obvious in that way kids do when they’re processing disappointment.
“What happened?” I asked, setting down my coffee.
“I don’t know. I was adding the cool spaceship piece to the top and it just… fell.”
I walked over and looked at the wreckage. The problem was immediately obvious to me, though he hadn’t seen it. He’d built his tower on a base of exactly four Lego bricks — 2x4 red blocks — and had been stacking narrower and narrower pieces as he went up, making the structure increasingly top-heavy.
“Want to know what I think happened?” I asked.
He nodded.
“Your foundation was too small for what you were trying to build on top of it.”
The Foundation Problem
It hit me right then, standing in a pile of plastic bricks: I was watching my client make exactly the same mistake.
For the past eighteen years, I’ve been implementing enterprise software systems. I’ve seen companies rush into cloud migrations, ERP implementations, and digital transformations with the urgency of a kid trying to build the tallest tower before lunch. And I’ve watched a shocking number of them collapse under their own weight.
The pattern is always the same. Leadership wants results fast. “Just get it working,” they say. “We’ll clean it up later.” So teams build on whatever foundation they have available — usually legacy systems, poorly documented processes, and hastily-written integration code.
Then they start adding features. New modules. Custom workflows. Third-party integrations. Each addition seems reasonable in isolation. Each one delivers value to some stakeholder. But collectively, they’re building a spaceship on top of four red Lego bricks.
We sat down on the floor together. “Want to try again?” I asked.
“Yeah, but this time I’m going to make it stronger.”
“Good plan. How?”
He thought for a moment. “Bigger bottom?”
“Exactly. Let me show you something.”
Rebuilding With Intention
We started over. This time, we created a base that was eight studs by eight studs — four times larger than the first attempt. But more importantly, we talked about why.
“The bigger the thing you want to build,” I explained, “the stronger the bottom needs to be. You can’t just start building and figure it out later.”
As we worked, I found myself thinking about the manufacturing client again. Their NetSuite instance was built on data migrated from a 15-year-old on-premise system. Nobody had cleaned the data. Nobody had validated the business rules. Nobody had questioned whether their old processes should be their new processes.
They’d just moved fast and started building.
Now, three months in, we were discovering that customer records had duplicates, inventory counts were unreliable, and their chart of accounts was a Frankensteinian mix of three different companies they’d acquired over the years. Every new feature we tried to add exposed another foundational crack.
The tower was growing steadily now, already taller than the first attempt. The difference? He was checking the base after every few additions. Reinforcing weak points. Making sure it was solid before going higher.
“See?” he said proudly. “It’s not wobbling.”
The Real Cost of Moving Fast
Here’s what nobody tells you about software architecture: the cost of a weak foundation isn’t just that things break. It’s that everything takes longer.
Want to add a new sales workflow? First you need to clean up the customer data.
Want to integrate with your warehouse management system? First you need to fix how inventory transactions are recorded.
Want to automate your financial close process? First you need to reconcile why your subledgers don’t match your GL.
Every feature request becomes an archaeological dig through layers of technical debt. Your best developers spend their time debugging instead of building. Your timelines balloon. Your budget hemorrhages. And worst of all, the business loses faith in technology as a competitive advantage.
The tower eventually reached the ceiling. Actually reached it — we had to stop because there was nowhere left to go. He stood back, hands on his hips, admiring his work with the satisfied grin of someone who’d learned something important.
“Dad, can you take a picture?”
I did. But I also took a picture of something else: the difference between his first base (four bricks) and his second base (sixty-four bricks). That photo is now pinned above my desk.
What I Tell Clients Now
When I’m in architecture meetings now, I think about that Saturday morning. When stakeholders push for faster delivery, when product owners want to skip “unnecessary” planning, when executives suggest we “just get something out there,” I think about the lego tower.
I’ve started asking different questions:
“What foundation do we need for where we want to be in three years, not just three months?”
“What will break when we scale this by 10x?”
“What assumptions are we making that we should validate now, not later?”
These questions slow things down. They’re uncomfortable. They feel like obstacles to people who want to see progress.
But here’s what I’ve learned: you can’t build a skyscraper on a garden shed foundation. You can’t run a global enterprise on data migration scripts and prayer. And you can’t achieve digital transformation by moving fast and breaking things when “things” include your core business operations.
The Lesson
My son taught me something that day that I’d somehow forgotten in eighteen years of software implementations: you can either build it right, or you can build it twice.
The companies that succeed in their technology transformations aren’t the ones that move fastest. They’re the ones that build foundations capable of supporting what they’re going to become, not just what they are today.
They’re the ones willing to spend time on the boring stuff — data governance, system architecture, process documentation, testing frameworks. The stuff that doesn’t demo well but determines whether your tower reaches the ceiling or crashes to the floor.
My son learned this lesson with Legos in about thirty minutes.
Most companies take years and millions of dollars.
Maybe we should all spend more time on the floor, building towers.
Top comments (0)