If you’ve ever decided to work out seriously, you know the shift requires certain lifestyle changes.
First, there are financial considerations, such as potentially:
- Buying a gym membership (or a better one)
- Hiring a personal trainer
- And increasing your protein intake
So, you’ll need to ensure you can afford these and other costs in accordance with your new exercise regimen.
You may also confirm if you have support from your partner, other loved ones, or friends. For instance, are they willing to help you meet your diet goals, such as by not keeping certain foods in the house? Are they okay with you spending so much time at the gym in the foreseeable future?
These are all important steps. But once you have these external factors figured out, you need to sit down and decide how you’re going to harmonize your health and wellness goals with other important parts of your life.
For example, you’ll have to balance the increased protein with other essentials in your diet. And if you’re going to focus on weightlifting and bulking up, you still need to work on other parts of your body so you don’t hurt yourself.
This is ultimately a question of balance. And it’s a question you’re going to face as an engineering manager (EM) when you think about how to address technical debt while keeping in mind your team’s other priorities.
Why you can’t solely focus on technical debt
If you give engineers total freedom at work, most of them will want to build something perfect. And if they aren’t able to do so the first time around, they’ll want to address all technical debt as soon as possible.
This is normal (you probably even felt or still do feel this way!) – most engineers are passionate about making something cool. But this sometimes comes at the cost of more practical considerations.
In practice, what they want would mean spending large amounts of time making fixes that, unfortunately, don’t have a noticeable impact on user experience. This would drive up costs without producing value on the business end.
Focusing entirely on technical debt is like spending all your workout time bulking up. Just as a healthy body requires a balanced diet and exercise regime, a healthy team dedicates an appropriate amount of time to a variety of tasks.
This means deciding what the right balance of technical debt looks like for your team. You can’t have too much, otherwise it overwhelms your system. But if you have too little, it’s likely a sign you’re dedicating too much time to addressing it and not enough building new things.
Criteria for prioritization
There are different factors to think about when deciding how much technical debt you can take care of and in what order. Here are three that I pay particular attention to.
Scope and cost
When your team logs technical debt, have them tag each issue with a rough estimate of how long it will take to address and, thus, what costs it will incur.
As you probably well know, you’ll always have a mix of tasks:
- Some won't take long to fix
- Others are deeply embedded issues that affect other sections of the code and need regression testing
- Many are somewhere in between
Eventually, you’ll address everything – the trick is considering what resources you’ll have available at what time. And whether or not the business side will agree with your assessment and prioritization.
You might think that larger pieces of technical debt will be a harder sell. That said, if you know you’ll have more resources this quarter, you can ask to tackle them first.
Or, if you know things are going to be tight because of other business priorities, you can start with something small but ask to schedule larger tasks as soon as it becomes appropriate.
Criticality
You’re also going to have to think about how critical a piece of technical debt actually is. This can be obvious, like when there’s a major vulnerability that supersedes your other deadlines.
But as you may well know, there are less obvious ways technical debt impacts performance and projects. A large backlog can lead to software rot, for example, and outdated parts of your system create issues.
Determining if now is the time to act means:
- Paying attention to the signs this is happening or will happen
- Determining your tolerance to reduced quality
- And what phase your team is in
Startups move fast and don’t care so much about quality. But if you have a project that’s more than three or five years old and want to grow, this becomes much more of an issue.
If you want to scale your team, you need to make sure new engineers won’t be baffled by the code. If you want to add new functions, like AI tools, a large amount of technical debt will create obstacles.
Planning cycles
Factoring in your short-term goals is just as important as keeping in mind your long-term plan. It doesn’t matter if you think in:
- Cycles
- Sprints
- Or iterations
They’re all units of planning. Each one results in priorities, of which technical debt should be a part. So, when you’re in the part of the cycle where you’re leading up to a launch, you won’t prioritize technical debt as much, if at all.
But you’ll stress yourself out if you think you have to find the perfect balance for every cycle. Instead, think multiple cycles ahead so you can distribute tasks appropriately throughout.
Your idea of balance will change over time
I know a company that dedicated 60-70% of their backend team’s time one year to working on technical debt. This sounds like a lot, but it makes sense, given where they were in their project cycle.
During their early years, they focused on trying new things and finding their market niche – they were agile and pivoted as needed. They didn’t think much about technical debt because it would have been premature. This would’ve been like trying to find a job as a lawyer before applying for law school.
They survived that early stage and reached a point where they could start thinking about consolidating their successes. They looked at their code and found it was a mess in places, so their priorities changed.
They accumulated a lot of technical debt, and in the prior year, they only addressed about 30% of what needed fixing. That’s on top of the debt they accumulated over that year. Their EM decided this wasn’t fast enough, and suggested allocating even more resources to addressing it next year.
This is not abnormal, in case you haven’t experienced or managed this already. Cycles change, priorities change, and so on. Know they’re going to happen, prepare for what you can, and adapt as needed.
And keep in mind that nothing ever goes totally according to plan. This is just par for the course.
If technical debt slows down one team, make up for it with others
You’re going to have periods where one team slows down because of more work on technical debt than usual – this is inescapable. Especially for companies that have recently decided to address a large backlog.
But you can compensate for this by positioning other teams to work faster. For example, you might assign another team to more localized technical debt that only affects UX. This takes up less time, freeing them to produce at a much faster rate.
Depending on your company, you may even have teams working in entirely new areas. Our company has a team that exclusively works with AI projects and hasn’t had time to accumulate much technical debt yet. They can be consistently relied on to work fast and produce more.
The trick here is to stay aware not only of what different teams are doing but also what they’re due to work on soon. Find out if some are likely to move faster over the next quarter. If so, coordinate with your project manager to assign another team to handle a thorny cluster of technical debt.
You won’t always have the luxury of optimally positioning your teams. But by making a habit of strategically assigning technical debt, you’ll be able to maintain uninterrupted production.
The short version: find your balance
No team ever has a shortage of tasks. It’s easy to want to focus the majority of your time on producing new features and products. But this must be balanced with maintenance work, like addressing technical debt. As the EM, it’s your job to find a balance that works for your team.
Do this by:
- Acknowledging other priorities: just like you wouldn’t focus only on your arms at the gym, you must balance technical debt and production
- Determining your criteria for prioritization: focus on factors like scope, criticality, and planning cycles
- Being adaptive as situations change: a startup is going to have different priorities than a project with three, six, or ten years under its belt
- Balancing your teams optimally: if one team is bogged down by technical debt, compensate by positioning other teams to move more quickly
There’s always going to be a tug-of-war between spending more time building new things versus maintaining existing systems. It’s your job to navigate this tension and make sure that technical and business goals will be met both in the short- and long-term.
Coming up
On Friday, 28 February, I’ll share successful strategies you can easily implement to lead team meetings effectively. I’ll focus on tips that are particularly helpful for introverted managers. Be sure to subscribe below so you don’t miss out on this or any future updates.
See you then!
Want more tips on leading effective software engineering teams?
Join my newsletter if you’ve found this content useful
Originally published on Medium.com
Content in this blog post by Alex Ponomarev is licensed under CC BY 4.0.