Tackling The Technical Debt in Five Steps

Recognizing that you have technical debt is easy. And if you don’t recognize it already, one of your engineers will likely tell you:)

The hard part is deciding how to tackle it and what fixes will provide the most impact. The simple truth is that fixing all of your bugs with the waving of a magic wand won’t necessarily drive business value.

In today’s world, there are hoards of tools for software development and Dev. Ops. These tools help. They are fast. Easy to install and the barrier to entry are a YouTube video and ‘git clone’ away from engineers making something happen.

Which… is what creates technical debt in the first place.

However, I know a few things that can help disambiguate technical debt. In this article, I cover what to look for, things to avoid, how to choose the most impactful thing to do, and my top recommendations.

But first, a tiny bit of history.

Know our goals and desired outcomes

Technical debt is the cost of reworks or taking short cuts.

Every business is different, as is technical debt and its effect on your customers.

Bugs experienced by customers often create chaos. One customer wants ‘Defect 123’, now! Yet another wants and added feature. And, of course, if you don’t fix ‘Defect 123’, you can’t add Feature XYZ.

My guess is, you have a sales guy somewhere telling the world he can’t make his quota because he doesn’t have a fix for the debug or the feature.

With all this chaos, you are part of a business. There is a right answer. While there are no silver bullets, there are high-impact fixes that move the needle.

And, guess what? That fix may not be ‘Defect 123’ or Feature XYZ.

5 things you can do to make dealing with technical debt — easy’er

1. Understand where revenue is coming from, right now

Not everyone in your organization will understand the ebbs and flows of revenue.

Different people are incentivized in different ways. Everyone’s passion for moving the business forward can create additional strains and stressors.

What engineers need to do often does not coincide with what sales want to do. Part of the cost you pay for being the boss is you are a parttime translator.

You must decide what actually gets done and understanding where your organization is in the value chain helps. Revenue is often king and most likely how your company continues to exist.

Tip: Work backward from revenue. If you have near-term revenue goals, pick the defects that help drive value, now. If you are building long-term value and your business has prospects, living with a few workarounds may be the right thing to do.

If you think you are both serving short-term goals and long-term value, you aren’t.

2. Respect engineers and draw a picture

A picture is worth a thousand words. Finding a way to show your team what’s happening with a picture can be super impactful.

Ask yourself this, what do engineers do when they want to understand something important? I am betting they use the whiteboard and someone draws.

I often use the design team to make a quick diagram. “What kind,” do you ask? Could be a magic quadrant showing where your company sits relative to the competition.

Maybe feature XYZ gets you feature parity.

Most times, JIRA doesn’t tell the truth!

Understanding the business from a ticket is one of the worst ways for your highly skilled team to understand what’s going on. And more importantly, how they can help.

Tip: Engineers are part of the business and not just hands on the keyboard with nice monitors and unlimited coke in the refrigerator. There is someone on your team who knows how to fix ‘Defect 123’ and build feature XYZ.

Or, perhaps she has a better idea. Just ask.

3. Make a list

Seriously, make a list.

While the sort function in JIRA is cool and you can project for all to see, it’s a poor substitute for pointing out what’s important.

Think of it this way. All coaches have playbooks, yet they still use a whiteboard to point out keys to the game or an approach at halftime.

Maybe you use an Apple TV, as we do. And perhaps your product leads want to project the glory of their spreadsheet.

Chances are 10 people in the room are looking at different things. And what’s worse, they are likely drawing different conclusions about what is important.

I tend to break things down in 3’s. If you have a mountain of technical debt like everyone else, all of them are not equally important.

Tip: Pick three. Break them down. Then, pick three again.

4. Be practical

Your architects, if given a choice, will reconstruct every bridge with new materials. Your Dev. Ops. team will find a way by hook or crook to run infrastructure as code and invariably restart start what’s broken, in perpetuity.

Your sales team is already pre-selling the next feature.

What do you do?

Think impact. Think of revenue. Think of long-term value.

Ask yourself what’s the ven diagram of impact, revenue, and value? Is there one? If not, pick the most important.

At the beginning of my career, I would always think of engineering impact in terms of the best “engineering” decision. I’d always look for elegant solutions.

I would crack open my data structures book, while customers where screaming desperate to find the “right solution.”

The bottom line is, the most elegant solutions are sometimes the wrong decision.

If a temporary fix gets a contract signed and cash flow is an issue. Well..?

Tip: The trick is to socialize architectural changes that are long-term as features when convenient. Doing so will make sales a believer and they will help you sell to your internal organization.

Trust me, you need them.

Look to improve the architecture over time and not in one big bang.

If you are a CTO ultimately you have a responsibility to the business as well as your engineering team.

5. Don’t be victimized by your own process

Most organizations are running some form of agile. And, well, we all need some sort of process.

Process for process sake gets in the way. Robotically following a process from a manifesto is a sure way to show that your team isn’t in lockstep with the business.

Sure, most of the time, you need a well-structured process. The team needs a cadence. A tempo. A playbook.

But…

Your perfect process cannot be the enemy of a good or reasonable solution.

No battle plan survives contact with the enemy. Further, relying solely on plans leads to failure.

Growing companies have real-world problems. Complex technical stacks grow. The demands of business change.

A short-term workaround is often necessary for real business. If you need convincing, follow a successful salesperson around. Try it yourself.

Tip: Expect chaos. Plan for it. Embrace that you will sometimes abort planning poker and the Fibonacci sequence.

I often created a rotating team of fixers. These people knew the platform and had the green light when things went really wrong. After they were done, we’d assess then get back to our normal process.

Every project, big or small, deserves attention. However, the right decision can often feel overwhelming.

It’s no surprise that thousands of companies buckled under the weight of their own self-created technical debt.

But now you have a recipe, what to avoid, and how to prepare your team. Try the tips we talked about next time you are faced with angry customers and 10 number #1 bugs to fix.