You've launched or released a major new feature. But there's still all of the code that’s hard to work with because it needs rearchitecting.
"Tech debt is unique to start-ups in that if you're worrying more about tech debt than the growth of the business, it probably means you’ve made it… to a certain degree." said Sonia Yang, CTO and co-founder of Treet, which helps brands with resale services.
Congrats. You've got tech debt. You probably also have a list of bugs and tests (which your engineers have told you about once…or a dozen times) on your to-do list.
Now, there's another feature to be shipped. A customer base with a slight uptick in churn. So, how do you know when to shift gears from product to proactive maintenance?
We talked with the teams at Treet, Edify (Slack-native technical onboarding and training to enable your software engineering team at scale), and Linear (issue tracking tool for high performance teams) to understand more about how they’re approaching tech debt, tests, and bugs as a startup. And we came away with 4 clear lessons on accessibility, decision-making, prioritization, and story-telling.
Keep reading to discover why maintenance tasks and tech debt don’t have to sidetrack your product roadmap.
1. Level up your code quality to help usher in new teammates.
When you think about tech debt, you probably (and understandably) focus on all of the things you haven’t done. But if you want to develop a sustainable system for high code quality, you need to think about the engineers who haven’t yet joined your team.
"We realized that if we want to grow, we have to make it easy for people to enter the culture," said Treet CTO and co-founder Sonia Yang.
Much like when you clean up your house because guests are coming over, Treet found the right moment to solve lingering bugs was in the weeks before onboarding a new pair of engineers. Yang scheduled a sprint session with her team centered on a checklist of issues that was discussed, edited, and then assigned.
While the pause to clean up code was effective – Yang estimated they tackled 70% of their issues during the time dedicated to fixing code – it was what happened afterwards that could yield significant benefits.
The company put in place monitoring to measure the effectiveness of the work. They’re also re-examining how they document changes.
Treet and other startups could look to Linear for a blueprint on how to advance projects while fixing bugs. Linear CEO and co-founder Karri Saarinen has developed a culture that encourages engineers to fix problems when they’re noticed; but also know they’ve got a backstop.
"We have one engineer in “goalie,” rotation, which is basically the person to help support and fix bugs and issues that get reported," said Saarinen.
Treet is weighing a rotation or dedicated percentage of bandwidth to ensure there’s always someone chipping away at the tasks that need to get done.
"One sprint session will never clean our entire plate off," said Yang. "Now, it’s top of mind when we’re building something to think about how sensible it will be for another engineer to come after."
2. Find the right decision making framework to balance maintenance and features.
Small teams are nimble by design. Decisions need to be made quickly to account for user feedback and product pivots.
Yet, how do you hold on to flexibility – to defuse potential tension between the need for maintenance and the desire for better performance – as your team is growing?
For Jayme Rabenberg, Director of Product for Edify, the answer is simple. You need to adopt a clear decision making framework to decide when and how you’ll tackle testing, code quality, and tech debt.
"You have to start with a framework because you can't develop one in the heat of the moment," said Rabenberg.
Since decisions may be difficult, it’s imperative the decision-making process be simplified. Rabenberg is partial to The Eisenhower Matrix, a time management system developed by former President Dwight D. Eisenhower. Here, potential problems are addressed, delegated or deleted according to their urgency (x-axis) and importance (y-axis). If something is both urgent and important, it takes priority.
At Edify, there’s a decision maker for each project. The rest of the team then slots in as advisors, offering context (what customers want or what results might follow) to allow the decider to understand the urgency and importance of a given issue.
Tech debt and tests are unlikely to be deemed urgent; but they can take priority when long-standing issues are slowing or stopping new feature development. Conversely, functional bugs and performance issues often seem urgent, yet may only be important to solve if they’re detracting from the user experience.
A decision-making framework provides the consistency you need to weigh different courses of action and determine how resources will be allocated. It also creates transparency. The voices of team members are heard. Decisions are then holistic accounting for the needs of different departments and feedback from users.
What about the small fixes, what Rabenberg terms "microdecisions," the ones that might fall through the cracks?
Rabenberg empowers her team to make their own choices to efficiently solve discrete problems. For those decisions deemed too small for the formal process, Edify has outlined design standards and establishable, measurable outcomes to help offer guidance that still allows for autonomy.
3. Consider costs and benefits to know when to tackle tech debt.
Once you acknowledge that you can’t – and might not even want – to address all of your tech debt, the work isn’t done. You still have to decide when to prioritize maintenance.
At Treet, Yang honed in on the errors that interrupt an engineer's ability to engage in deep work.
"If an error is happening multiple times a day, and that error needs a manual fix each time, that’s time away from doing core work," said Yang.
Treet often prioritizes bugs that need to be solved immediately because the cost of that debt – the lost time and focus of an engineer – is too great. Another way to assess the value of a maintenance task is to consider the ultimate benefit to your end users or team.
At Stashpad, we're hyper-focused on performance. Developers can't get value from our product unless it's fast.
"Performance standards are part of the acceptance criteria of all new features and we prioritize tech debt when it’s starting to get in our way and slow us down," said Stashpad CEO and co-founder Cara Borenstein.
By keeping our core feature set small, we make it possible to keep our standards for performance high. This provides common ground and a shared language for our product and engineering teams, ensuring decisions are based on how they ultimately affect performance - even if that means fewer features are shipped.
"Narrowing scope is empowering," said Borenstein, "The less surface area we are trying to cover, the better job we can do at the one thing we’re trying to do well. The best products are very simple and work very well."
4. Don't forget to tell the story of each decision.
Once you’ve actually made a decision to prioritize tech debt, bugs, or new feature development, it’s important everyone on your team understands why the decision was made.
"I had to learn to articulate why I made decisions," said Rabenberg. "I don’t think that's particularly innate even to those of us that are good at making decisions."
Acknowledge that individual emotions are part of the process, even if the decisions are based on a clear set of metrics or the demands of the market. By holding space for people to share what they're feeling, it eliminates the possibility a pivot may leave one of your team feeling left behind. It also can help you gain clarity on what you need to prioritize next.
"As a leader, I think my job is to facilitate an environment that feels safe," Rabenberg said. "How we show up as humans and interact as humans is the thing that makes us successful."
Remember, you're not only taking care of the emotional needs of your team, you're also aligning team members, customers, and your leadership. The story of a decision is part of the story of your company as each decision is a step in a new direction.
"When we're clear on the why, it's much easier to prioritize and find the right path forward," said Borenstein.
Photo by ThisisEngineering RAEng on Unsplash.
