10 Types of Tech Debt That Have Broken My Creative Heart
10 Types of Tech Debt That Have Broken My Creative Heart
A lighthearted breakdown of scenarios I’ve experienced to help you prepare for situations you might encounter
If you design software there are 3 things you can be sure of: death, taxes, and tech debt.
I’ve been around the block enough times in my 11 years doing this creative technology thing that I can confidently say “I’ve seen some sh*t” and I'm a little bit wiser now because of it.
Today I want to pass along what I've seen to you.
There's no bigger bummer than designing something awesome and then having tech debt swoop in, crush your dreams, and break your creative heart. And while I still think you need first-hand experience to develop your judgment, let this be a heads-up for the kinds of scenarios you might encounter.
Just like financial debt, there are good and bad reasons to take on tech debt (though the bad reasons outnumber the good ones).
Good tech debt might look like increasing your line of credit to fund the expansion of your business. It's a transient debt whose risk you accept in order to return a big gain.
Bad tech debt might look like a payday loan, whose sky-high interest rate quickly catches you in an inescapable cycle of payments.
Taking on debt carries risk, but you can be smart about it if you approach it intentionally. And honestly, if you just avoid the common pitfalls you're doing better than 80% of companies.
I find it easiest to think about tech debt by considering where and how it's distributed across a system. So below I've broken my examples up into four categories:
All around problems
Operations problems
Front-of-house problems
Back-of-house problems
Oh, and I gave them all archetype names because... it's more fun that way!
All around problems
1. The Dumpster Fire
The Dumpster Fire is a debt situation where everything is hot garbage.
Once you realize this is the situation you're in… run. Run far, far away.
As a designer, your ability to ship meaningful work depends on the engineering org having its act together. I've been in situations where I've done good design work that collected dust because the organization as a whole wasn't stable enough to execute it. They were still too caught up putting out fires to be able to design and build improvements in a consistent manner.
It's not a fun place to be as a designer, and it's mostly a waste of your time and talent regardless of how much they're paying you.
2. The House Flipper
The House Flipper is acquisition debt. It's where your company acquired something and patched it together just enough for curb appeal.
All kinds of dodgy debt can roll up in here.
Forced, shared branding that doesn't really work.
Data systems connected with two pieces of string and some duct tape.
Really anything goes when constructing this Frankenstein because, in this scenario, the company's priority is conveying unity even though there's little. In theory, this can be done smartly, using the acquisition as a moment of leverage to amplify capabilities. But it gets messy. And I haven't personally seen a version of this scenario where I would be excited to work.
3. The "Crazy Ex-Girlfriend"
The Crazy Ex-Girlfriend is debt accumulated by building hyper-specific features for one dominant customer's use case.
Stuff gets built because the customer hangs dollar signs over your head, but it's mostly stuff that you'll eventually have to design your way out of. You’ll need to make the product more general in order to cover a wider percentage of your desired audience. While this can be done smartly, you walk a fine line between success and making a deal with the devil that you'll live to regret.
It's not the worst scenario to be in, but expect to make your fair share of bogus designs to get that customer off your back before you can move on to the good stuff.
Operations problems
4. The Conjoined Twin
The Conjoined Twin is debt where you're attached at the hip to an external vendor that’s now failing you.
Particularly at early-stage startups, you need to gain as much leverage as possible from external resources to boost the capacity of your small team.
This is smart debt.
But inevitably, what worked for you as a small team will someday start to fail at scale.
It's neither a terrible nor unexpected position to be in, but it can derail your capacity to ship meaningful designs during the time when you’re ripping and replacing that old infrastructure.
Be mindful of the systems a company is already committed to when you join. The odds are you'll be living with them for quite a while.
5. The “Damn, My Build is Slow”
The "Damn, My Build is Slow" is debt accumulated in the DevOps pipeline.
When the process of building, viewing, and revising code is slow and laborious it cripples a team's ability to iterate.
Every back and forth between a developer and designer becomes an ordeal and so at a certain point the developer taps out and ships something that's not fully refined.
If you need some extra ammo to make the case for better DevOps at your company, this is an underrated one; it's not just developer experience at stake, it's your ability to iterate effectively on mission-critical designs.
This kind of debt also leads directly to...
Front-of-house problems
6. The Death by a Thousand Cuts
Death by a Thousand Cuts is debt accumulated across many, small inconsistencies that struggle to get addressed because they aren't significant enough individually to get prioritized.
It's a milder form of debt, but that's what makes it so insidious; it flies under the radar until you have so much of it that it's hard to dig your way out.
From my perspective, it's a common and not-that-terrible scenario. As a designer, you can make direct contributions toward resolving it. The main thing you need is an ongoing open channel devoted to consistently chipping away. Github’s Project Paper Cuts is a good example.
7. The Speakeasy
The Speakeasy is a product that looks bad and has a lot of debt upfront but is actually awesome once you get past the front door.
This is an ideal scenario for a designer to step into and make a difference. There will be plenty of debt to resolve, but since it's concentrated on the surface, you can address it by improving areas that design can directly impact.
This has been the most approachable of all the tech debt scenarios for me. The one caveat is to make sure you have the UI engineering talent to pair with design to make progress a reality.
Back-of-house problems
8. The Set Piece
The Set Piece is the opposite of The Speakeasy: it's a product that looks great upfront but has fundamental backend debt issues.
This is a tough one.
Just because the UI is snazzy doesn't mean you have a good or stable product on your hands. And it doesn't mean that designing for it will be all rainbows and puppy dogs. Its good looks often distract people from dealing with the underlying problems, making this scenario a potential house of cards.
There are a couple of contexts where the "Set Piece" makes perfect sense though: hackathon projects, demos, or presentations. Just don't let that temporary debt evolve into our next type...
9. The Intern to CEO
The Intern to CEO is a specific instance of the Set Piece where a prototype gets promoted to production without due diligence.
It was a great demo, but it’s trash as a real-world implementation.
This is more common than you'd imagine and you'll probably end up dealing with it at some point in your career. The best way I’ve found to resolve this is to find the person who built the original prototype (if they’re still around) and redesign/rebuild it together.
10. The Performance Ponzi Scheme
The Performance Ponzi Scheme is a situation where the organization never fixes underlying performance issues and instead passes them along to the next shmuck any chance they get.
Like a Ponzi scheme, it can momentarily seem like a great deal and bring accolades to the person currently making the move. However, by robbing Peter to pay Paul, the team will eventually find themselves on the brink of an unhappy collapse.
This one's tricky as it’s equal parts organizational and technical issues. So in my opinion, it's best to steer clear as a designer as it's almost entirely out of your control.
Request for comments 🤓
What's been your experience with the debts I mentioned?
How have you handled them?
What tech debt scenarios have you encountered that I missed?
Let me know in the comments!
If you got a little value from this post, consider subscribing, sharing, or following me on Twitter. If you got a lot of value I’d appreciate it if you bought me a coffee 😎☕️.
