Cultural Technical Debt: When “We’ve Always Done It This Way” Costs You
☕ Today’s Coffee: Green Mountain Breakfast Blend — smooth, balanced, and reliable. The kind of coffee that doesn’t shock your system, but wakes you up gently. Modernizing culture should feel the same way: steady, intentional, and sustainable.
What Is Cultural Technical Debt?
Most IBM i leaders know about technical debt — legacy code,
outdated DDS files, tightly coupled programs, and that one nightly job no one
dares to touch.
But there’s a quieter kind of debt, and it’s often the one that costs the most:
cultural technical debt.
It’s the accumulation of habits, beliefs, and resistance that build up in
a development organization over years — even decades.
It’s what happens when “what works” becomes “what must never change.”
Technical debt slows your systems.
Cultural debt slows your people.
And when your people stop evolving, no modernization tool, no rewrite,
and no cloud migration can save you.
What It Looks Like in Real Teams
If you’ve spent any time in a long-standing IBM i shop, you’ve heard the
symptoms:
- “We’ve done it this way for 20
years.”
- “RPG works fine, why do we need
SQL?”
- “Our users won’t accept a new
UI.”
- “I can code faster in SEU than VS
Code.”
- “Learning RDi or Git will take
too long.”
- “We’ll modernize next quarter —
after this release.”
Individually, these are just comments. But collectively, they create cultural
drag — the invisible weight that makes innovation feel like pushing through
wet cement.
It’s not that these developers are wrong or lazy. They’ve been successful
doing things a certain way. But success can become the very thing that blocks
growth. The more you rely on “what worked,” the harder it becomes to try
something new.
The Real Cost of Cultural Debt
It’s easy to underestimate how much cultural debt costs your
organization.
Here’s how it quietly compounds over time:
1. Slower Delivery
When developers don’t adopt modern tools like Git, VS Code, or SQL-based
access, simple changes require massive manual effort.
Something that could be automated in hours becomes a multi-day, multi-person
task. Multiply that by every project in flight, and the “cost of comfort”
skyrockets.
If your critical systems depend on two developers who understand
30-year-old code and SEU-only workflows, that’s not expertise — that’s risk.
The day one of them retires or moves on, you’ve lost a business process encoded
in muscle memory.
New hires — especially younger developers — often feel alienated in
legacy environments. When their first assignment starts with “open SEU,” it
feels like stepping back in time.
And they don’t stay long. Cultural rigidity drives away the very talent that
could renew your system.
4. Missed Opportunities
IBM i has evolved dramatically — integrated SQL, APIs, containers, even
open-source tooling. But many teams never take advantage because “we don’t
have time to learn.”
That’s like owning a Ferrari and never taking it out of first gear.
Breaking the Cycle: From Fear to
Curiosity
Fixing cultural debt starts by addressing one truth: most resistance
to change is rooted in fear, not defiance.
Fear of failure.
Fear of embarrassment.
Fear of losing relevance.
As leaders and senior developers, our job isn’t to force change — it’s to
de-risk it. To create an environment where learning something new
doesn’t feel like failure.
Here’s how to begin.
1. Make Learning a Protected Priority
You can’t expect developers to modernize on their own time. Learning SQL,
Git, or VS Code takes focus — not leftover energy after a 10-hour day.
Give your team dedicated learning time. Even one hour a week is enough to start
shifting habits.
Celebrate that time as progress, not lost productivity.
Example:
A team I coached implemented “Modernization Mondays” — one hour each week for
developers to experiment with something new: SQL views, APIs, VS Code
extensions, or RDi shortcuts. Six months later, they were teaching each
other.
2. Redefine Success Metrics
Legacy culture often rewards “getting it done.” But modernization
requires rewarding how it gets done.
Start tracking things like:
- Reduction in manual steps.
- Code written in free-form RPG.
- New tools successfully adopted.
- Automation or documentation
improvements.
When you reward modern behaviors, people start repeating them.
3. Build Change Ambassadors
Change sticks best when it comes from peers, not management.
Identify early adopters — developers who like to experiment — and empower them
as internal advocates.
Let them run demos, share wins, and pair with those who are hesitant. Culture
spreads faster laterally than it does top-down.
4. Deconstruct “The Old Way” With
Respect
Nothing kills morale faster than implying the old system was “bad.” It
wasn’t bad — it was brilliant for its time.
The goal isn’t to erase it but to evolve it.
When developers see modernization as a continuation of their
craftsmanship rather than a rejection of it, the fear fades.
Call it legendary, not legacy.
5. Lead With Transparency
When deadlines loom, learning feels like a luxury. But good leadership
communicates why modernization matters and how it aligns with
business goals.
Don’t just say, “we’re moving to SQL.” Say:
“We’re moving to SQL because it simplifies maintenance, improves performance,
and allows us to integrate faster.”
When people understand the purpose, they engage with the process.
A Real-World Example: Shifting the
Mindset
One IBM i shop faced an enormous modernization challenge. They had a
25-year-old monolithic system with thousands of programs — and a team that
didn’t want to touch modernization with a ten-foot pole.
Instead of forcing change, leadership did something radical: they invited
curiosity.
They asked each developer to identify one thing that frustrated them
daily — a slow process, a repetitive task, a confusing section of code — and
find one modern tool or method that might improve it.
The results were modest but transformative:
- One developer wrote a simple SQL
view that replaced a 400-line data extraction subroutine.
- Another used VS Code to reformat
and document an old program — and loved it.
- Within months, the conversation
shifted from “why bother?” to “what else can we improve?”
That’s cultural debt turning into cultural equity.
The Leadership Layer
As a manager or tech lead, your influence matters most.
Cultural change starts with modeling the behavior you want to see.
- Use the tools yourself.
- Be open about what you’re
learning (and struggling with).
- Recognize incremental progress
publicly.
- Protect your team’s learning time
like it’s part of your roadmap — because it is.
The message you send isn’t “change or else.” It’s “we grow together.”
Cultural Debt Is Harder to See — But
More Dangerous to Ignore
You can’t grep for cultural debt. You won’t find it in QA reports. But
you’ll feel it — in every delayed project, every burned-out developer, and
every meeting where new ideas die quietly.
It’s the unseen backlog beneath your backlog.
But once you name it, you can change it.
Modernization isn’t a toolset. It’s a mindset — and that mindset starts with
curiosity, not fear.
Final Sips
Today’s coffee — Green Mountain Breakfast Blend — reminds me of
what good modernization feels like: light enough to start the day, strong
enough to build momentum.
Modernizing your IBM i culture doesn’t require revolution. It requires
rhythm — small, consistent changes that build trust, energy, and skill.
When you pay down cultural debt, you don’t just modernize systems.
You modernize people. And when your people evolve, the technology always
follows.
☕ Follow The RPG Blend for more insights on leadership,
modernization, and the human side of IBM i.
📖 Blog: The RPG Blend on Blogger
💻 GitHub: The RPG Blend Projects
👤 LinkedIn: George VanEaton
Comments
Post a Comment