Everything feels new and exciting in your early twenties.
Many of us prioritized new experiences:
- Partying
- Backpacking for a few years
- Staying up late working on passion projects
- Or pushing yourself in your career and other endeavors
In other words, you probably wanted to explore, learn, and try as many things as possible. And you should at that age:
- You have the energy of youth on your side
- You won’t immediately feel the consequences of less sleep or irregular diet and exercise
- And you’re able to bounce back quickly
But then you get into your late 20s or 30s and realize you have to make lifestyle changes to stay in good shape by your 40s. If you eat, sleep, or grind like you used to, it will have major consequences for your life and health later on.
You can’t do everything you used to.
Technical debt is no different. If you work for a young company, you’re likely not going to think about it much, and that’s okay. If you overengineer things right away, hoping to make everything perfect, you’re not going to be as flexible and agile as you need to be in those early years.
But, if your company survives long enough, there will come a time when you have to change your workflow to address the technical debt you’ve accumulated over time. As the engineering manager (EM), it’s your job to think about what this means for your team.
What it is
For those who don’t know, technical debt (or “tech debt”) is what we call imperfections that accumulate in code and lead to problems over time. It builds up for a number of reasons:
- Shortcuts taken while coding, often due to rushed development cycles
- Insufficient documentation
- Outdated legacy systems
- Unclear or changed project requirements
- And more
The “interest” generated by this debt is the extra time your team spends to navigate these issues or the extra resources you’ll use to address them. Over time, performance decreases, and maintaining old systems becomes increasingly costly.
You “pay” this debt by having your team refactor the code so these problems get ironed out. Some companies have dedicated teams for this, while others rotate engineers in and out of the role to spread the work out evenly.
All of this requires coordination on a management level to make sure your debt doesn’t get out of control.
Don’t stress out over the fact you have it
With all the issues associated with technical debt, it’s easy to fall into the mindset that any technical debt is a sign of failure on your or your team’s part.
But let me ask you a question: is it a driver’s fault that they have to service their car over time?
Sure, there are things a driver can do that will cause extra problems for the mechanic:
- They can drive irresponsibly over badly paved roads
- They can switch gears too fast, too often
- And they might carry heavier loads than the vehicle was made for
But even the most conscientious driver is going to visit the mechanic every once in a while. The only ones who avoid it are the people who drive so carefully that it takes them forever to get from point A or B. Or their car is in perfect condition because it never leaves home.
As a tech company, you’re in the business of making stuff. And, as the saying goes, that often means breaking a thing or two along the way. Having technical debt is a sign you’re doing your job and are making decisions that move you forward.
So, never stress out that you’ve accumulated technical debt. It’s ultimately a sign of success: you’re still around and building products that people actually use.
But you still need to prioritize addressing it
What you need to think about instead is how to make sure your technical debt doesn’t spin out of control.
This requires allocating resources to address it on a regular basis. If you don’t, existing issues get worse. Problems that were once small and manageable compound with other problems into a many-headed monster.
Your code will get harder to navigate, which means you’ll spend extra time working with it. This is especially true for new hires unfamiliar with your system. And you’ll have less time overall to make new features.
What’s more, long-lasting problems create issues in other parts of the system. Things slow down or create bugs, which makes your team unattractive to potential new talent. New hires, after working with your system for a few months, might jump ship to work for a company with code that’s easier to manage.
In short, dedicate resources to addressing technical debt on a regular basis so it doesn’t create more headaches than you can handle.
Managing technical debt means understanding the different phases involved
Imagine you’re an artist on the hunt for an interesting space to exhibit works and host events. You get word of an empty space in an up-and-coming part of town and head over to check it out. You love the:
- Location
- Atmosphere
- And size
You sign the dotted line immediately.
As soon as it’s yours, you start thinking about what you need to do and realize it’s going to take a lot of work to make it usable. You need to:
- Clean out the whole place
- Varnish the floors
- And build extra walls to display your work
It feels overwhelming and you find it hard to think of what to do first.
It’s easy to feel this way as an EM when you consider technical debt. But you can break every big problem down into a series of stages. Once you understand the steps for each, you can manage with the proper time and attention needed.
Build a clear system that allows your team to build good habits
Making sure the work is done effectively on a regular basis becomes easier if you have a system to help your team build the right habits.
The main tasks are:
- Standardizing procedures
- Communicating them to everyone involved
- And helping team members put them into practice
This requires time invested upfront, but it saves it in the long run. You’ll need to have different systems and supports for different teams, though.
Engineers, for example, need to know what counts as technical debt and what doesn’t. This eliminates confusion when they come across something ambiguous. This needs to be communicated regularly, especially to new hires.
Sometimes, technical debt will even affect the design team. So, you’ll need to educate them about the debt and what they need to do to help.
The same goes for you. Set aside time to figure out what resources need to be procured for tech debt over the coming weeks or quarters. Then, secure them proactively. Regularly inform your PMs about the state of affairs so they keep in mind the need to allocate engineers to refactoring.
Build trust in your system with proper logging
Sometimes, engineers go out of their way to address technical debt as soon as they see it. This might not seem like a problem in theory, but it means they’re not spending as much time on the tasks assigned to them. And if they miss a deadline, it affects the other teams that need to work with the code.
In my experience, this happens because of a lack of trust. Many engineers think that if they don’t address a piece of technical debt right now, it'll get lost in the system. Having a good logging practice can prevent this.
Building a culture of effective logging comes down to a few different factors. Engineers should:
- Notice and feel responsible for logging technical debt
- Understand and comprehensively apply the different tags available
- Be aware of what counts as severe and flag critical errors appropriately
- And respond to changes in logging procedures and apply them promptly
This way, your team will know what to do when they see tech debt. They can be confident that things will be addressed at the proper time. This builds trust in the system and keeps the team’s priorities and timeline in alignment.
Prepare for resistance
You may experience some resistance from the business side of the company when you ask for more resources to fix up old code – this is normal.
Colleagues who work on the business end often don’t have a technical background. Their resistance mostly comes from not being aware of the consequences of not promptly dealing with the debt. Their focus is on making sure your team produces and sells features and products on a regular basis.
To them, addressing technical debt sounds like improving something that already works. So, it often comes down to you making the case for tech debt since you’re the main manager with technical experience.
To do so, you have to:
- Put your business cap on
- Learn to think how they do
- Answer their arguments
- And speak in a way that makes sense to them
The main skill you should build is offering cost-benefit analyses. You have to have a good understanding of how much your company is going to save by addressing technical debt, or how much it will cost if you don’t.
Do this by becoming fluent in different metrics. These include how long it takes to produce features, how many bugs you produce, and how many people are hired or leave your company. When you understand how technical debt impacts these, you’ll be better able to make a case for addressing it.
Be ready for debate
I’ve been in this business for a while, and I see the same arguments made again and again against allocating the necessary resources to technical debt. To better prepare yourself for these conversations, you need to know what those arguments are and how to deal with them.
Three classic ones I hear often are:
- Technical debt isn’t our problem
- We won’t meet our goals if we address it
- And we have to think about survival first
There are effective counterarguments for each, but counterarguments aren’t enough. You need to get into the right mindset first to have a productive discussion.
The first thing you have to understand is that people don’t make these arguments out of malice. They have genuine concerns that need to be taken into account. So, don’t go in with guns blazing without properly understanding just what feels at stake for the other side.
At all times, speak in a spirit of collaboration. Don’t talk down to them by playing to your technical experience. This feels condescending and invites more resistance. Instead, communicate how reducing tech debt helps them meet their goals over the long term.
Sometimes, this means you’re going to have to compromise, especially when they make good points or convincingly argue for their priorities. Asking them to be open to persuasion means you have to be ready for the same yourself.
Balance addressing tech debt with other priorities
Once you’ve secured your resources, you have to figure out how to balance working on technical debt with other tasks.
Think about this like maintaining a balanced diet. If you eat lots of protein but neglect your vegetables, you’re going to get nowhere fast if you’re training to run a marathon.
Whether or not a piece of technical debt is prioritized will depend on three factors:
- Cost: how many resources it’s going to consume
- Scope: what doing the task actually entails, and whether you expect the scope to change during the process
- Time: how much time you need to (or can) dedicate to it
When the cost, scope, and time required are high, you have to ask yourself hard questions about whether the task really needs to happen right now.
If you know how many resources you’ll have over a period of time, say the next quarter, you’ll be able to plan what tasks can happen at what time. But if you know funds will be low for a while, or that your engineers will be busy with a sprint, plan ahead to make sure you don’t need to address a thorny piece of technical debt at the same time.
Code gets old – take care of it
In the end, addressing technical debt is just one way to maintain your code. You also need to encourage practices that help team members treat your code with care. That way, you won’t accrue as much debt over time.
For example, when adding a large new feature, think about whether integrating it fully into your main backend or building it as a separate microservice is going to improve performance and make maintenance easier or cause more problems down the road.
Another thing that can easily cause problems is when people who are unfamiliar with a legacy system work on it without understanding its quirks. Something a new engineer might do with a piece of fresh code could accidentally make your code malfunction. Having proper documentation and onboarding procedures helps people understand what a program can and cannot do.
The short version: don’t let your technical debt get away from you
Technical debt is as inevitable as death and taxes. You and your engineers have to address it on a regular basis, and managing this process is one of your responsibilities as an EM.
Doing so requires:
- Acceptance: Technical debt is not a sign that your team did a bad job. Rather, it’s a sign that your company has found its niche and survived.
- Prioritization: You need to understand why technical debt has to be resolved on a timely basis, and what happens if you don’t.
- Management: Keeping technical debt under control is a multi-step process that requires your oversight.
- Building a system: It becomes easier to manage technical debt if you build a system that’s understood and used consistently by all team members.
- Proper logging: Make sure all instances of tech debt are properly logged and categorized.
- Expecting resistance: Understand and respond to resistance from the business side when requesting resources for refactoring.
- Making counterarguments: Make effective counterarguments towards this resistance, but always do so with respect and understanding for the other side’s concerns.
- Balancing priorities: Once you have secured resources, properly balance technical debt with other team priorities.
- Looking after your system: Some instances of tech debt can be prevented simply by treating your system with care.
Just like someone entering their 30s starts reducing the strain they put on their body, projects that last long enough must address issues that have cropped up along the way. By keeping on top of your code’s technical debt, you ensure the longevity of your product and a smooth working experience for your engineers.
Ready to take back control of your engineering career?
Join my newsletter and get a copy of my Daily Priorities Tracker for free!
Originally published on Medium.com
