How we tackle technical debt
Sami Ur Rehman, software architect, shares our approach to managing technical debt and tips for getting buy-in across the board.
Like most engineers, I frequently face the challenge of tackling technical debt. Balancing incoming requests from stakeholders while keeping debt from piling up can be tricky. But as hard as it is to take precious time away from building features to address tech ‘housekeeping’, there’s just no way around it. Technology-driven companies need to have a debt management strategy that all stakeholders can get on board with.
When I took on the responsibility of Technical Program Manager for our domain separation project — check out scaling microservices architecture using monorepo & domain-driven design for more details — I faced this exact challenge. How to tackle a large scale technical debt project while still delivering on business needs?
Getting started
At Taxfix, we apply the 80/20 rule to split our efforts between feature delivery and technical debt. This means that our engineers spend 80% of their time working on cool new features for our internal and external customers. The remaining 20% of their time goes towards improving the processes around making those features possible. Quite often, tasks in the latter category don’t necessarily bring immediate benefit to the user. However, they do bring value in the long run because they allow us to get better at developing new features.
After an initial scoping of the domain separation project, we identified a list of action points. We then divided this up between the various product teams based on their focus areas and ownerships. However, we soon discovered that many teams involved in the project were not effectively using their 20% to address issues related to technical debt. It took us weeks before any team was up to speed and ready to contribute to the project. Even though we had good alignment on technical goals and had broken down all long-term objectives into low-level tasks, we were still competing with priorities that could bring immediate, visible value to the customer.
Challenges and learnings about 80/20 in practice
Lesson 1: find the right 80/20 model for each team
In retrospect, our first mistake was assuming that every team would contribute towards the project at a similar pace and style. Very soon, we realised this was not realistic. Every team was spending 80% of their time working on highly specialised tasks that came with a unique set of dynamics. It was only natural that they wanted to use the remaining 20% in a way that complimented their existing workflow.
Lesson 2: get stakeholder buy-in
The second challenge we faced was onboarding non-technical stakeholders to the project. It’s not always easy to explain technical debt. It accumulates in different forms and can be hard to quantify. Understandably, many stakeholders wanted to prioritise features that could deliver immediate benefits over the domain separation project. What helped most was to use a reference they could relate to — an analogy from the world of finance. Just like financial debt, a complex codebase incurs interest in the form of time. If we don’t work on “paying off” this debt today, it will not go away. In fact, eventually, it will hinder the delivery of high priority product features for the team in the long term.
Lesson 3: don’t forget about your tech debt
Of course, managing technical debt is far from straightforward. Some teams have genuine reasons for not going forward with the seemingly obvious approach. If the team is already working at capacity or lacks the required skills to stay on top of their technical debt, the only solution might be to wait until the situation evolves. In these cases, however, it’s essential not to forget about technical debt. It might sound counter-productive to continue discussing debt with teams that cannot currently contribute. But regularly re-evaluating tech debt helps us understand if we are outgrowing our capacity to pay it off at a later stage.
Finding the right approach for implementing the 80/20 rule
Despite the challenges shared above, we didn’t give up. Slowly and steadily, each team found their own way to contribute to the project. Similar to how we handle many decisions in the Product Organisation, each team was encouraged to choose the 80/20 method that made the most sense for them. Let’s take a deeper look at how some of our teams decided to contribute to the project:
One day per week
Our ‘TaxBoost’ Team in Madrid favoured this approach. As part of our Operations Services Group, the TaxBoost Team owns our country-agnostic tax submission pipeline. Through modern, event-driven architecture, they aim to reduce the manual workload of our internal teams. In their approach to supporting the domain separation project, the entire team dedicated one day per week to collectively tackling technical debt.
We recommend this approach — when possible — because it’s likely to benefit the team in the long run, even beyond the scope of a specific project. Since the whole team is working on similar tasks simultaneously, they are often in pair or mob programming mode. Over time, this approach will reinforce a culture of team building and knowledge sharing. And when team members are encouraged to learn from one another, the development opportunities are endless. This is an excellent method for technical debt management when not everybody in the team has the same skillset. It could also be the right approach when the debt challenge is too daunting for a single team member to handle by themselves.
One out of five team members
This model was adopted by our ‘Monks’ Team in Berlin, which specialises in bringing new features to our German customers. For this team, it made the most sense to allocate dedicated people to the domain separation project. Simply put, they used 20% of the team’s capacity by assigning one member out of five to lead the technical debt effort for a fixed period. This system does come with drawbacks, however, as one team member alone will typically get tired of working on similar tasks every day. Additionally, it could lead to a knowledge silo within the team. If only one team member has context around technical debt, there is a loss of context for the team. In these cases, it makes sense to frequently rotate the responsibility among all team members.
We find that this method makes the most sense for teams with packed product feature roadmaps. When one member is consistently working on similar tasks, they tend to become more efficient at it in the short term. If we can align such responsibilities with the personal growth plan of that team member, this could easily become a win-win situation.
Two out of ten sprints
Our ‘Benjamins’ Team — or Monetization Team — in Madrid decided this approach made the most sense for their unique use case. The team had just committed to changing their focus area, from reducing the contact rate of our customers to all things related to payments and monetisation. With such a drastic shift, they realised they could apply the 80/20 rule to sprint plannings of an entire quarter. Their initial focus was to wrap up any tasks related to their outgoing team objective. And before they started contributing to their new mission, they went all-in on their deliverables for the domain separation project. Ultimately, with this hyper-focused sprint approach, the team had incredible momentum and results.
While the ‘two out of ten’ sprints method has similar learning benefits to the ‘one day per week’ approach, I would not usually recommend it. Outside of exceptional cases, like a team changing objectives from one quarter to the next, it’s generally better to stick with the slow and steady approach rather than all-or-nothing. Considering the basic principles of agility, we like to embrace change and continuously evaluate and learn from ongoing efforts. So the ‘Benjamins’ are now transitioning to ‘one day per week’ as they complete their focus transition.
Moving forward with 80/20
The approaches shared above are by no means exhaustive. There may be countless methods for applying the classic 80/20 split between feature delivery and technical debt. But regardless of which approach you take, keep in mind these valuable tips:
- Educate your stakeholders.
- Continually re-evaluate your capacity to address technical debt.
- Let your teams decide for themselves how they want to allocate the 80/20 split.
Putting your team in the driver’s seat and enabling them to find solutions that work for them almost always leads to more beneficial results for everyone involved.
How are you handling tech debt in your daily work? Let us know in the comments.
Interested in joining one of our Product Teams? Explore our open roles.
