�������� Presents: A 30 Second Crash Course in Technical Debt

Let’s state the obvious: your company’s hardware and software age, just like any other product. 

Take a sports car, for example.

When a new Mazerati rolls off the lot, it’s loaded with all the latest bells and whistles. After all, it’s been built to compete with every other model on the market. 

But over time, those industry trends become staples that drivers depend on. We’ve seen this happen with Bluetooth, Blind Spot Sensors – and (most importantly) power windows.

More power to ya!

The same thing happens with all the other tech gadgets in your life – from Smart TVs to home security systems. The only catch is that digital technology ages much faster than your car’s mechanical engine. (Think about how many phones you’ve had in the past decade compared to Mazeratis.)

If you’re anything like the average U.S. consumer, you’ve upgraded your phone at least twice in the last 10 years. The average lifespan of a cell phone is 4.7 years – much shorter than the lifespan of the average modern automobile, which clocks in at 11.5 years. 

So what does this mean for tech companies?

In order to stay relevant, companies that develop technology must iterate much faster than their mechanical engineering counterparts. But that’s easier said than done. It takes significant resources to keep a company’s IT infrastructure up to date, and as a result, systems that sprawl across large companies often have much longer lifespans than they should. Instead of keeping us ahead of the curve, our technologies can become anchors of cost and maintenance. 

The gap between “where we are” and “where we should be” is exactly what we mean by “technical debt.”

Assess your debt level with targeted questions

It’s pretty obvious when it’s time to trade-in an old car. 

It’s fine. Everything’s fine.

But, there’s no “check engine” light for your company’s tech systems. That’s why it’s critical to proactively assess the state of your software, hardware, systems – and the larger processes that hold them all together. The most effective way to do this is to routinely ask your tech team targeted questions.

Here are a few of my favorites:

1. Which OS are our servers running? How far behind are we from the latest stable versions?
   
   
2. Which systems account for large portions of our revenue, but haven’t been reviewed in the last 6 months?
   
   
3. Which version of programming language are we using? Are these versions actively supported?
   
   
4. Is our technology readily available in the current job market? Or is the industry moving a new direction?
   
   
5. How long does it take us to release? Have we had to implement many manual processes and oversight boards to validate that we aren’t causing disruption?
   
   
6. How many of our systems are orphaned, yet still live in production?
   
   
7. How much visibility and testing is present in our software? 
   
   
8. Can we easily identify active vs. inactive software components? 
   
   
9. How easy is to identify whether new changes to a system will have undesired consequences downstream, impacting revenue elsewhere?
   

After you’ve run through this list, you should have a solid idea of the anchors weighing down your IT ecosystem. But be warned: this checklist isn’t just a “nice-to-have.” If you aren’t willing to invest this time up front, you’ll pay for it later when you’re scrambling to dedicate valuable time and talent to modernizing, pruning, and generally untangling the behemothic mess that your systems have become.

5 Steps to Get Out of Debt

Whether you’re a Silicon Valley startup or a Fortune 500 corporation, every company that uses technology has some degree of technical debt. (We’re humans, after all.) Here are five helpful tips to keep in mind as you move to close that gap.

1. Understand the value, risk, and cost of repair.

Analyze exactly what you’ll gain by updating or pivoting away from certain systems – and how much it’ll cost to get there. Solicit feedback from multiple parties outside of your tech team. Identify potential security risks or business risks that will arise as a result of any large-scale changes. Whatever you do, don’t roll out major changes without considering long-term ramifications that could undermine your progress.

2. Increase the visibility of your systems.

It’s not enough for you to know which systems are dragging you down – the whole organization needs to be in the loop. It’s critical to have buy-in from key stakeholders, so frame the fix as revenue protection rather than cost.

3. Make sure your new state is well-defined.

Formulate a detailed plan for where migrated components will live. Have a reliable CI/CD pipeline figured out from end to end. And consider exactly how/when new services will be built. Open your mind about what capabilities can be replaced by SaaS solutions on the market. 

Perhaps most importantly, make sure you’re adopting best practices in secure development and data storage – and that you’re leveraging frameworks and libraries that meet (or surpass) industry standards. Otherwise, you’ll find yourself back in the same spot sooner rather than later.

4. Build an empowered task force team.

Create a team dedicated to systematically upgrading and sunseting systems. Make sure you have the decision authority to sunset low-value components as needed. Otherwise, you’ll wind up with significant lag in your team’s lead time to deliver change. (This breeds all kinds of business risk issues and, of course, plunges you even deeper into tech debt.)

5. Don’t get behind the curve.

Online search engines impact more than we give them credit for. Not only do they catalog and index massive amounts of information, they determine how relevant content is based on how often that information is requested. 

Read: as the industry moves farther and farther away from specific technology, it becomes more difficult for your teams to find information, patches, and general support for older technology.

Dredge up your tech anchors

Our team recently did discovery on internal software that has been active for more than a decade and is touched by more than 200 different developers throughout the company. We found more than 11 Trillion lines of code in one repo. (Yikes!) Many of those pieces were critical to our revenue engine, so scrapping it wasn’t an option. Instead, we had to form a team dedicated to extracting value from the old software and modernizing the entire system.

Here’s what we learned: When it comes to resolving tech debt, the longer you weight... the heavier the lift.