A Guide to Technical Debt for Startup Engineering Teams
While technical debt has a negative connotation, there are valid reasons for taking it on. In fact, it can be a smart business strategy especially for early-stage startups as they test out a new product or feature.
The important thing is to be aware of why you’re taking that debt on and to develop a strategy to pay it off.
In this article, you’ll hear advice from startup engineering leaders as they share:
- Why engineering teams take on technical debt
- The disadvantages of too much tech debt
- 7 tips for managing tech debt
- How to build a healthy culture around tech debt
Why Engineering Teams Take on Technical Debt
As an early stage engineering team, taking on technical debt is often a requirement to push code out the door and meet client deadlines.
It’s also helpful when your team wants to test an MVP. In this case, you don’t have time to ship perfect code but you end up with an MVP which will allow you to quickly go to market.
Leo Hentschker, CTO of public benefit startup Column, explains, “Your customers don’t care about your CI pipeline or your integration tests. They care that you have a product that improves their lives.”
However, not having those items will eventually hinder your ability to improve your product.
Hentschker continues, “Once your product is in market, you quickly get to a point where when one of the best ways to deliver value is by improving your engineering team’s internal tooling. Application stability is one of the most important features that you can offer. But on day one, the focus is to build something that solves real problems for your customers.”
In fact, Hentschker sees technical debt as a necessary part of a team’s development, not an inconvenience or something to be ashamed of:
“If you look back at your old work and realize there’s technical debt, then that means you’re getting better at your job. Finding flaws in the code you wrote six months ago is a natural part of working at an organization that is improving.”
The Disadvantages of Too Much Technical Debt
While tech debt isn’t bad on its own, it can slow the engineering team down as it accumulates and potentially cause the project to halt.
Emmanuel Apau, CTO of Mechanicode.io, explains, “Usually the business case wins the argument when it comes to quickly building an application because the startup needs to make money and get users. The application’s integrity takes a back seat. Eventually it gets to the point where you’re unable to push out features as fast because there’s a mountain of debt that’s slowing things down. It can eventually impact the business side of the application because you can’t push out new features as quickly, or it makes features more complicated to build. If you don’t keep managing the tech debt regularly, you’ll end up having a team that’s not working on any new features at all. They’re spending the next two weeks just trying to fix things.”
Another concern of tech debt is that it can decrease team morale and hinder hiring and retention. Most engineers don’t want to spend all their time cleaning up a bad system. Team members might quit if that becomes their primary focus.
7 Tips for Managing Tech Debt
1. Set realistic goals.
Kara Chapman, Associate VP of Engineering at Morning Consult, observed, “Technical debt tends to creep up when engineering teams are rushed to meet hard deadlines. Encourage engineers to push back on the scope of the work or the deadline rather than taking shortcuts to deliver on time.”
If you get a release out as fast as possible, but have code that’s a mess, you could end up having more work just to manage that poorly written code. If you start with a stable foundation, each consecutive release will be easier.
2. Choose your tech stack wisely.
Emmanuel Iroanya, founder of Theta, recommends that startup engineering teams choose well-understood technologies that they’re familiar with versus picking the latest trend.
“It may not be the shiniest toy in the toybox, but the more experience and comfort you have with your choice of technology, the more side effects and unintended consequences will be avoided.”
3. Weigh the cost of building vs buying.
“There’s often a bias towards buying something when your team could build it, so I like to consider how long it would take to both build the feature and fix it when we recognize that the implementation is not ideal.” — Leo Hentschker, Column
When deciding to build vs buy, consider how long it would take to build the core feature as well as the time to maintain and improve it. You could measure this by looking at the number of days your development team would need to spend at a later point reducing the tech debt, by performing activities such as refactoring or replacing the application.
Hentschker explains further that one of the benefits of external vendors is it forces you to fully decouple something from your own internal system. Not only do you get the self-service software as a benefit, but it forces you into design patterns that will decouple a system from your own internal code base. As a result, it’s a bit harder to accrue the same level of tech debt that you would have if you rolled out something yourself.
4. Keep pieces of code self-contained.
If you know the required inputs and expected outputs, it’s much easier to replace small amounts of lousy code than fixing large pieces of wrong code.
Chas DeVeas, Director of Engineering at Storyblocks, explains, “If you have existing tech debt, then I’d recommend taking a quarantine approach, the same way that you would a micro service if you can. If your tech debt is with one particular area, you can quarantine it in code by making very clear interfaces and boxing it off.”
5. Regularly work on your tech debt backlog.
Lokesh Kumar, Cofounder at roadside assistance startup Urgently, explains that early-stage startups should not prioritize paying down tech debt because that’s the time to move fast and because there are resource limitations.
With that said, the team should always be mindful of their debt. If it starts slowing your operations as you grow your product, then you must start paying it down. He stated, “If you’re spending more than 50% of your time on paying down debt, you’re not moving fast enough, but if you’re spending 10% of your time paying down debt, then you’re probably in good shape.”
You could also create a framework of service level agreements between the infrastructure team and development team. Apau explains that his team determined that they only had the bandwidth to deal with a certain percentage of backlog tickets. He said, “If we get over that threshold ratio between backlog tickets and new feature tickets, then we’ll prioritize working on the backlog.”
Bonus Tip: If your team operates in sprints, then be sure to document and label all tech debt at the end of every sprint. One way to manage the backlog is to take care of at least one critical item every sprint. This pace allows you to keep building new features while also slowly working on the backlog.
6. Prioritize the most critical tech debt.
Determining the highest priority debt is typically up to the team leads or the architect. In general, anything that’s going to impact the availability of an application or a product should be prioritized.
Instead of trying to hide tech debt in the corner, regularly bring it out in the open to discuss. Bring up how many bugs and issues everyone has encountered in the past week so you know what the problem areas are. By keeping everyone aware of these issues, you’ll be able to identify the critical items before they become a major problem or start slowing down the functionality of your product.
7. Create a culture of knowledge-sharing.
This approach of knowledge-sharing allows the engineering team to be more stable.
DeVeas says that when an engineer leaves a company, they take the context of the tech debt with them. If they’re the only one with knowledge about that debt, then the team will eventually end up finding a surprise in the application (which is never a good thing). If the information is shared and documented, the team can be confident they’ll operate smoothly even when someone takes time off or leaves the company.
Knowledge sharing also allows the team to be aware of the most urgent tech debt, allowing them to prioritize what’s most important.
How to Build a Healthy Culture Around Tech Debt
“I view technical debt as something that happens when an organization is getting better. The code you write today is better than the code you wrote 6 months ago.” — Leo Hentschker, Column
A healthy mentality around tech debt comes from the top down. Engineering leaders should let their teams know that it’s okay to recognize tech debt and not immediately act on it. The important thing is to document it well and tell the rest of the team about it. Remind engineers that there’s a business case for why the debt exists, so there shouldn’t be any pressure to hide it.
Most tech debt is due to something not being built in the most optimized way, so working through it gives a younger developer a deep understanding of how the application works. It can become a valuable learning opportunity for new developers.
A lot of developers don’t enjoy working on tech debt because it feels like they’re working on the company’s baggage instead of something new and exciting. However, Apau views working on tech debt as a valuable opportunity. He explained, “As a site reliability engineer, I want the application to be stable so we can scale properly. By resolving tech debt, I’m paying forward by ensuring that the application is reliable.”
Keep in mind that there are beneficial outcomes to managing tech debt well.
Conclusion
It’s important that everyone at the company (especially the engineering team) understands the pros and cons of having technical debt. By educating leadership and other departments, you’ll be able to set more realistic timelines and goals for the engineering team. You’ll also be able to create a strategy to pay off tech debt on a regular basis, instead of feeling pressured to always focus on new features.
Originally published at https://www.myhatchpad.com.
