Frustrated that you don’t get time to work on tech debt and improving infra? Working at IBM was my career’s peak no-business-contact. I had a blast working on internal tooling, and without any business demands, was left to do what I pleased. Naturally, as a young engineer, I filled the time with tech perfection and over-engineering.

I found innovative approaches, contributed to open source to make tooling work better for us, and more. I felt good about myself. Until one time that I witnessed an update to stakeholders about everything our department achieved and realized a year of my efforts had probably contributed nothing to it.

As an aside, now that I’m writing this, I realize that’s probably my business-impact obsession origin story.

Teams doing important things never have weeks and months to make things “perfect.” You should never boast zero tech debt. If you do get it, you’re probably off to the side doing something meaningless, like Aviv of almost 20 years ago.

The Tech Debt Pressure

How often has your team lamented about its tech debt situation or scale issues, requesting time to refactor, rewrite, redo, and unscrew the mess on your hands? And how many times were those requests denied because of more urgent things?

Of course we sometimes need to slow down to ramp up. You cannot keep plowing forward without taking a moment to put things in order. Yet you have got to realize no one will give you weeks (or months!) to put everything on hold. Treat that as a given, and now move forward.

The Moving Target

Asking for months is a confession that you don’t know how to ship anything you can’t see the whole shape of first. No can do. The world will pass you by in the meantime. Like the story of the Berlin airport that opened nine(!) years(!!) late. They had all the time in the world to do things “right,” yet it was obsolete by the time it was shipped (and already filled with new “tech debt,” or the airport equivalent).

Even more so, now with AI, everyone’s expecting technical changes to happen faster. Yet we see teams that don’t realize it and still ask for weeks and months. Not only are you going against your CEO’s expectations, but you’re failing to bundle into it the huge opportunity cost: if the organization is using AI properly, it means that every week you’re taking away is worth that much more for the business.

Tactics

Precisely for that, you need to learn to work much more rapidly. Don’t complain about the CEO not understanding you. You are failing to understand what businesses need. Your path forward is to suggest things that make business sense.

Piggyback: What can you get done along the way, “while you’re already there”? What extra 5% of clean up and refreshers can your people do as they’re working on things already on the backlog? This is the Boy Scout rule applied to your codebase. Don’t underestimate the compounding effect of many changes along the way, especially with the increased absolute number of changes shipped we’re seeing.

Batch it: 20 years ago, I had to write code that parsed Java to automatically migrate dozens of systems from one framework to the new one. I understood no one would give the organization the time to do it manually. Now? You don’t have to create your own lexers; you can whip up an agent with enough tests and let it go at it overnight or during the weekend. Why waste human time for these big changes that are mostly boring?

I actually called it 18 months ago, saying this will quickly become the norm. The tech is there, at least for many cases. Use it.

Slice it: Break this up into tiny pieces, even if that seems absurd. Don’t ask to work on things in chunks of uninterruptible weeks, but a day or less. These bite-sized iterations give you flexibility and make it easier to weave the work along the way while maintaining responsiveness to changing business needs.

When the changes in your mind are parked in your backlog as things that require three weeks to get started, you’ll never find the timing to do it. If, instead, it’s all broken down, you can make progress whenever there’s some time (and it becomes easier to perform as part of piggybacking).

Bundle the payoff: Find where the changes you want to do clearly line up with near-term business needs. The business wants you to add real-time dashboards? Explain how in the current architecture it will require two weeks and cost a lot in added cloud costs, whereas with the refactor you’ve been planning it will take just three weeks (so a week more), will be cheaper, and also gain long-term benefits. Talk about things that would be possible and currently aren’t, or would cost too much.

Don’t starve business: Rather than stopping the entire org, or even an entire team, break things up so that there’s always forward motion. Wouldn’t you get edgy if you were paying millions for something and seeing nothing change for weeks on end?

Yes, this relies heavily on having solid communication and trust in the CEO-CTO relationship.

Now, young-me at IBM? I didn’t need a year of clean code, it turns out. Just one line I could’ve said in that stakeholder meeting.

The R&D Leverage Audit is a two-week look at where your R&D budget stopped matching your R&D output. For details, reach out.