So what is technical debt?

Technical debt is all the legacy code, processes, automations or assets that are sitting in your systems that are no longer used. It’s anything that requires managing due to poor processes, poor code or lack of time to sort, organise, repair or decommission. 

Technical debt typically comes about through age, taking the fastest (but less rigorous) route, poor management processes, or poor code. Whichever way you look at it, there’s a cost involved – either resource, time or money to resolve, hence why it’s called debt.

How does technical debt come about?

Let’s be honest, virtually all technology will form technical debt over time – it’s part of the natural cycle of technology, so technical debt is going to happen, there’s no avoiding it.

Most frequently, technical debt comes about due to changes of strategy, new messaging approaches, rebranding or technology feature changes that result in certain integrations or requirements that are no longer needed. 

Another key component of technical debt is user creation, where tests, or poor processes create additional assets that aren’t required. An example of this might be where you’ve working in a presentation deck and every few days a new version is created and named 2.0. The reality is that most presentation programmes have version history, so this behaviour is redundant, yet there are plenty of people that still do this. It’s the same with marketing technology – tests may have been created, lists may have been duplicated or forms created that were never used, yet they clutter up the system and take up space – as well as create risk of being reused when they should have been retired.  

As humans, we seem to have an ongoing fear of deleting and forgetting to clear up after ourselves – we finish one task and quickly move on to the next. 

Common areas of technical debt in marketing

I’ve tried to keep this broad, rather than specific to a particular platform since marketers use at least 5-10 marketing platforms on a daily basis – and technical debt will apply to pretty much all of them.

The most common ways technical debt can build up are:

• Automations within marketing automation platforms. These are often set up for specific things and rarely checked that they’re still in use, or performing the automation they should. Automations can apply to actions, workflows, processes or flows. If they’re left to run, they could be creating mischief in the system, so a regular check is always worth it. LIkewise, if they’re no longer used but left in the system, there’s a risk they may get reactivated in error
• Templates for forms, emails or landing pages. Over time, new templates get created, but how often do you take the time to remove old ones? A new brand, UX directive, code base, set of fields or personalisation requirements shape the need for new templates. The danger of leaving the old ones lying around means that they could get used inadvertently
• Updates on one platform not being applied to another. A classic example here is where field requirements have changed in the CRM for a lead or contact record, but not been updated in the MAP on the prospect record. This can apply to the data field type or mapping requirements
• Data builds up in systems and after several campaigns, you’ll likely have a bunch of email addresses that aren’t relevant. For example, how many test versions of yourself sit in the CRM? Likewise, what about all those system email addresses such as marketing@company.com that you’ve had as new prospects. Data cleansing practices really help here to manage data and lists
• Test programmes or old programmes that are no longer used frequently get left in the system. Consider a global marketing team with one instance of a martech platform, can you imagine how many end-users create campaigns and leave them hanging around years after they’re required?
• Discontinued assets. If you’ve rebranded, how many of your assets such as images, templates or documents need to be retired to prevent them being used in error? 
• Folders, tags and files that are used universally often need a tidy up and maybe redundant. Left standing and they contribute to technical debt

There are other types of technical debt that impacts marketers as well. These include:

• Poor code or scripts working inefficiently creating problems within the system
• Old code resulting in poor performance – either speed or functionality
• API connectors not functioning properly due to ineffective scripts 
• Old branding across the web that needs updating which requires time and resource to implement
• User management where people are given too much access with the ability to create additional elements that create further technical debt
• New tech releases from third parties which impacts what you’re doing. An example here is the introduction of Apple’s MMP which impacts the ability for email marketers to know if an email has been opened. If you have automations, actions or workflows based on ‘open’ it would now be unreliable. Keeping on top of third party updates that might impact your set-up is always worthwhile

So, like my messy house with kids that no longer need all their ‘stuff’ from childhood, it’s not a major issue, but if I left it, it would just get worse and at some point, the house wouldn’t function (not for me, anyway). I could choose to tidy up a bit, or I could get a cleaner in to work their magic, Either way, there’s an impact on my time, ability and wallet (if I chose the cleaner route). But if I left it, what’s the risk?

The risks of technical debt

As I explained above, the risk is low to moderate. If anything flagged as high risk, it would be dealt with quickly. The problem with a number of low risks is that they build up and cause bigger problems and bigger backlogs in the long run. There are other higher risks though, that are worth considering:

• Data management: Poor data management, particularly around privacy or opt-in, is a compliance issue and errors here are a big risk. These should be actively managed to limit technical debt in relation to any processes that impact personal data or retention policies
• Licence and platform costs: With most systems, the edition you’re on dictates how many automations, how much storage or how many contacts you can have. By not managing these and allowing them to mount up, there can be significant costs – both financial or in your ability to achieve what you want to do. See Salesforce Marketing Cloud Account Engagement Pricing
• Customer experience: The wrong templates, incorrect workflows, old messages or the wrong action assigned can all create havoc with customer experience, even more so if personalised experiences are involved
• Brand experience: Brand is all about consistency and trust, by having old brand assets floating around, brand perception is impacted causing damage
• Opportunities lost: Poor processes or automations may mean that follow-ups don’t happen at the right time as processes work against each other and impact the human tasks required in sales. The result – pipeline doesn’t build or opportunities are lost

Back to my analogy about my messy cupboards and tidying up… a tidy house is all about good management and rules. Together, these form the foundation of good governance.

Building technical debt into a governance structure

Any governance programme should include an element of technical debt monitoring including housekeeping rules to maintain integrity, efficiency and technology, and data and brand adherence. When running multiple systems or instances of a platform across global teams, this becomes even more important.  

When writing up governance documentation on processes and workflows, add in a review cycle with agreed review periods to ensure technical debt is assessed and limited. For some organisations this will be a compliance issue with agreed and known standards applied, along with a change log to record updates. 

Make sure you have a regular audit, ideally with an external partner that can provide a fresh pair of eyes and is used to seeing common technical debt issues across marketing technology. Pay particular attention to processes, workflows, automations, new data requirements and check if reports are still running as expected (by removing certain types of assets, some report metrics may change which could also impact the status of a prospect). 

For most people, they don’t like deleting things (or throwing things out in the case of my messy house). This is usually because holding onto things creates a sense of comfort and lowers the risk in case ‘it’s needed again’ or the fallout of throwing it out impacts something or someone else.  

To limit this, we’d advocate creating a method of reporting tech debt within your organisation, particularly if there is technology dispersed across marketing and sales – and a global user base. This can support the ongoing maintenance programme for marketing technology platforms in one centralised governance team with the appropriate martech admins involved. This puts the onus on the central team to check for issues in retiring assets or processes. They also have the knowledge of what to check from a multi-technology perspective and the likely impact of any change.

In a more simple setup with one instance of the tech running, an admin of the technology should be able to run a housekeeping programme of ongoing monitoring and maintenance. This along with good governance documentation, should limit technical debt. 

For now, I need to get back to my cupboards and drawers and sort out my own ‘stuff’ that I need to clear out. Thankfully, there’s a lot less complexity and risk (or so you would think…).