Tech debt? No, More like Process Debt

Everybody loves to blame “tech debt”. It’s thrown around so often in sales and marketing circles.

But what they usually saying is one of two things.?

1. “Our system gets in our way and we hate it”?
2. “We can’t move quick enough to change the system and we hate it”

From there the conversation turns to “how in the world can we avoid this tech debt?!”

And that’s the thing that makes me shake my head.?

Why??

It’s not even tech debt they’re talking about in most cases.?

Yes, the frustrations may be with some system or piece of tech. But if you dig far enough, the root cause is process debt?

This is a far deeper issue with the algorithms your company is operating by. Fixing the actual problem starts with understanding what problem you’re looking at in the first place.

Technical debt vs process debt

Technical debt comes from the programming world where it’s the bad code that sits around in the codebase update after release after update after release. It’s not laziness on the part of the developer to put out shoddy code. It’s the result of the whole “done is better than perfect mentality.”?

This is a serious problem in the development space but because I’m not a developer, I’m going to leave that up to the professionals to solve. ??

When it comes to your revenue tech stack, it’s possible that you’re dealing with the downstream effects of the developers of the platform you’re using. That is true technical debt.

What marketers and sales people are talking about on the other hand has nothing to do with the software itself. Instead, these are issues of process debt that are being mislabeled as tech debt.

Common types of “tech debt” for revenue teams

Pretty much every organization I’ve ever worked with has at some point struggled with tons and tons of duplicate fields, empty custom fields, and irrelevant data points in Salesforce, Hubspot, or whatever their CRM might be.?

These were likely created with some intention in mind (I hope) but were abandoned later. Here’s a few examples of types of issues I’ve come across in my career.?

• The company thought they wanted to track BANT/MEDDPPIC or CS case category but we changed our mind.
• We thought we wanted to track the onboarding progress but that effort has been abandoned.
• The business processes started with somewhat manual with partial automation until “we nail down details” or “we get volume” and was never revisited
• The initial process building wasn’t scoped for all the scenarios so the operators / system admins applied patch over patch to accommodate other scenarios.

These aren’t signs your technology is broken or dated. It means there is no culture in your organization focused on assessing the holistic process portfolio when introducing new things.

As RevOps has become more and more of a formal discipline I’ve noticed one thing: we’re really really good at building things but not great at getting rid of stuff.

And if you don’t believe me there’s an easy test. Try asking around if you can delete 10000 contacts in your database that haven’t engaged with your brand in two years. More often than not

So…what should you actually do about process debt?

Now that we’ve clarified what exactly it is we’re talking about when it comes to process debt, the next step is to figure out what you can actually do about it.

There’s one approach that’s worked really well for both my employers and clients alike:

A formalized end-of-year cleanup. Yearly, regular cleaning rituals are a big deal in many cultures. There’s Spring Cleaning for western cultures, the Hindu festival of Colors has cleaning out clutter associated with it as well. My background is Shintoism and we’ve got a similar sort of “seasonality” around cleaning.

Anytime you introduce a new process or enhance the existing process, clarify what can be retired and when. I like the approach of Start / Stop / Continue. “Start” is no brainer but can we also think about what we can stop at the same time. Having a timeline to sunset the legacy processes can be very helpful.

Sometimes we may not be able to retire something immediately for the legacy processes, but at least scope it out, and set a reminder (or create a Jira ticket, whatever) to sunset the process should you need to.?

Your list should be wide ranging. Include very small things like ensure the copyright year of the website is updated to some bigger items to archive/deactivate the obsolete automation.?

Based on the downtime seasons your business gets, I highly recommend carving out the time and cleaning up your instance.?

(So no more multiple ARR fields or notes fields!!)

Make sure this doesn’t get losto prioritize this work in the season! Get alignment from your stakeholders. Actually involve them because you’d probably need their input to retire certain things.?

Processes make for a solid organization

If you take one thing away from this, it’s this: process debt is an unavoidable reality.?

But with a proactive, strategic approach to monitoring and measuring workflows, you can make sure that it doesn’t drag your team down.?

This is not just a one-time thing either. You’re going to need to revisit your processes regularly and your review process itself might grow over time.

All you can do is just get started and cross off one thing at a time.