Tech Debt: Technical debt is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.
Does tech debt only apply to software development?
At Goat, we use the term 'tech debt' to describe any technology state that is negatively impacting an organization as a result of a lack of evolution or quick fixes piling up.
While the technical definition of tech debt applies to software development, it’s not hard to see how the same issues can flare up in many areas of an organization: marketing stacks, CMS (content management systems), website UX (user experience), internal communications, coffee makers hanging on by a thread.
It can be a Google Analytics build. It can be the way your CRM (customer relations management) is pulling in data. It can be aging design principles. It’s kind of like how I think about space: I try not to put too much thought into it, because if I think about space too long I get anxiety.
It happens to every organization. The organizations that are the most ahead of the curve aren’t even the ones that are perfect - they’re the organizations that understand the problem and have a plan.
We’ve dealt with a lot of tech debt at Goat - in the traditional development sense, and in all of the broader senses that I’m co-opting the phrase for. We’ve helped clients overhaul UX that was designed for the wrong generation, we’ve helped migrate clients from a broken, custom-built CMS to Craft or WordPress, and we’ve upgraded to a coffee maker with really cool blue lights and a timer.
Addressing aging technical infrastructure isn’t simple. I’ve learned that the hard way. So here are 5 hard-learned lessons from the Goat team and some other smart people to help you plan better when moving into the future.
Technology and Program Dependencies
Established systems will have many intertwined dependencies. One program or process affects another, meaning you need to consider the impact of a singular change on every point of human or inter-program contact.
You decide it’s time to switch from a Shopify site to a Craft CMS site in order to have a more robust user experience that goes beyond a shop and a blog.
- Facebook + Twitter pull pixel data from Shopify
- Google ads send users to specific URLs
- Analytics inside Google Tag Manager pulls traffic data from Shopify site
- Shopify feeds customer emails to Drip
- Shopify feeds order information to a fulfillment service
- Your internal team writes blogs in Shopify’s site builder tool
If you don’t plan ahead for dependencies, any or all of these connections could fail. And, if you were so quick to switch you actually deleted the Shopify site, you’ll have a hard time retracing steps to put the tech puzzle back together.
Mapping Tech Stack Dependencies
If you’re struggling to map out all of your dependencies while planning, here are some ways to get insights quickly:
- Ask your IT department, if you have one, to put some time into listing the interdependencies of the apps affected by your proposed changes. They’re the experts who will have the highest-level overview, and possibly documentation on connected tools.
- Check the ‘API (application programming interface) permissions’, ‘plugins’, or ‘integrations’-type sections inside the programs you use. Many programs need explicit permissions to connect with other apps as part of your workflow, and checking those lists will give you some insights. This is applicable to CMS backends, programs like Slack and Zapier, or your marketing stack. This is a good way of seeing how others on your team may have built dependencies you should know about.
- Look inside Google Tag Manager or the header code on your website. The header section of your website is where most tracking and marketing integrations are installed, and Google Tag Manager is a tool that replaces those multiple code snippets with a single snippet. Both options will give insights into dependencies.
- Understand the extensions being used in Chrome or other browsers. Extensions can point you in the direction of technologies you’re leveraging elsewhere in your tech ecosystem. For example, the Toggl extension in my Chrome browser is a quick access spot for Goat’s Toggl time tracking system, which relies on Asana to pull in task-specific data for hourly billing.
This App Partner Program graphic courtesy of HubSpot shows how limitless and complex integrations can get.
Consider The Humans Inside an Organization
Since Goat is a smaller organization, I interviewed the team at Lumen5, a larger Software as a Service (SaaS) company that builds video making software for social media. If a growing company is building software itself, you know they have some insights. Their team is always looking ahead in order to keep their marketing, development, and sales machines running smoothly.
I expected their answer to be super technical and involve the phrases “API” and “omnichannel”, but it was the opposite: think about your people.
Consider Technical Skills of Users
It doesn’t matter how great a tool could be if it can’t be used. It’s like putting a welder in the hands of someone like… me. I could maybe turn the gas on, but there’s no way I’m going to do any work worth paying for. Your technology is the same because technology is for humans.
Similarly, when we work with clients on larger-scale projects like upgrading CMS systems or building custom back-end platforms, we always need to consider the skill level of the lowest-skilled users, now and in the future. Building a course software platform for programmers is vastly different than building a course software platform for teachers.
There’s a caveat here: sometimes your users are skilled, but held back by really poor implementation. That’s why we suggest asking, always.
Additionally, a tool can’t be used to its potential if there’s nobody with the time to use it. This doesn’t even factor in onboarding or teaching time, which often requires setting aside specific hours that aren’t part of a normal workweek’s flow.
Managing The Human Element
The best way to factor in the human element of technology modernizing is to ask. That’s it. (As a strategist, I would like to note that ‘asking’ is the first step in solving about 90% of all business problems.) Ask your team what repeatable tasks they think could be offloaded to a third party or a software solution. Ask your team how comfortable they are with new technologies, and what bandwidth they have for taking on something new. Even if it’s going to make everyone’s life easier, we all only have 24 hours in a day.
At Goat, we do a lot of this work with stakeholders inside our clients’ organizations. The first step of nearly every project we take on is ‘familiarization’. We not only need to know a client’s goals, but we need to understand their stakeholders, organizational structure, and the capacity or skills of their internal teams. This helps us know what can and can’t be offloaded, and how much time we need to set aside for coaching and support.
Consider Scalability + Pricing
Any technology improvement should consider both a business’ current pain points and their future goals.
Many paid technologies start with a free trial or limited-feature, low-price option. Asana is a good example of this model. A free account with basic features can handle up to 15 users. Moving to the next tier adds around $13.50 per month per user. That’s a sharp increase. If you have 15 users that need to move from free to paid and you want to foot the bill monthly, it adds (before discounts) a whopping $2,430 to yearly operational costs. In US dollars.
When considering any new technology or app, knowing how pricing and features scale is huge. Considering only a current state could cost you a lot of money, and a lot of time if you want to adopt a different solution as a result.
As noted in the dependencies section, integrations are a factor when implementing new tools. Goat uses several Slack integrations, as well as some Google integrations. Unless we want to change an entire workflow, we just don’t have the option to use a tool that won’t merge seamlessly. Of course, superstar developers Tim Lu or Carmen Shing could custom-build an API or find some other solution, but there’s probably no reason. Easy integrations are usually an out-of-the-box feature for most apps, though you may need a certain pricing tier or plan level to get access.
Factoring For The Long-Term
Here are some handy tips for planning ahead.
- Consider your growth trajectory. A small team now could become a huge team later. Ask yourself if your business is in a growth stage and needs to account for far more users in the future, or if it will stay relatively the same size.
- Ask providers about grandfather rates or other ways of locking in pricing as you grow. Finding out that a tool you depend on is going to jump in pricing without notice can do genuine damage to your margins and bottom line.
- Ask yourself what features you may need in the future. Instead of focusing on what the lowest tier of pricing offers, look at the others for insights into how your organization may want to upgrade a plan as you grow or adapt other elements of your tech stack.
- Phone a friend or ask others in your industry what they’re doing. I find that people are generally helpful. This could be because I’m usually asking other Canadians, so your mileage may vary.
There you have it. Having read this article, you should now be at least a little more confident in moving ahead with improving your tools, processes, and apps to avoid (what we broadly call) tech debt.
Questions? Comments? Need an agency partner that knows their way around complex digital product and website updates? We’re happy to talk. Just reach out.