When Technical Debt gets in the way of Growth

On June 21st, we had a live talk called When Technical Debt gets in the way of Growth.

Guest speakers Tim Cochran and Carl Nygard, Technical Director and Technical Principal at Thoughtworks, joined our Codacy CEO Jaime Jorge in an intriguing talk about technical debt. 

During the live talk on technical debt, Jaime Jorge, Codacy CEO, moderated the conversation and asked interesting questions to our guest speakers. You can check their detailed answers on our video recording of the live talk — we even give you the specific time frames! But we’ve summarized the answers for you to read 🤓

What are signs that software quality is deteriorating that scaling companies should be looking for as they grow? (00:03:52)

There are some common signs and things you need to pay attention to:

• Different aspects of your organization are slowing down;
• Things are getting harder to accomplish;
• The lead time to deliver value and time to recover are increasing;
• The positive impact to your end-users is decreasing;
• You are not able to provide the same amount of value in the same amount of time as before;
• Developers’ satisfaction is going down;
• The time it takes to onboard a new developer and to accomplish a certain task is increasing; 

You need to be able to measure and spot trends. As such, try to understand your DORA metrics. Plus, if you listen to your teams, engineers will tell you where the pain is. Finally, don’t forget that technical debt is cumulative, so the more tech debt you build, the more impact you will see in the various parts of your business.

Is there some way to measure developers’ satisfaction? (00:09:18)

One way to know how your developers feel is to use surveys from time to time, allowing people to comment and have frequent conversations with their managers. The worst thing you can do is find out in the following interview, so you need to be proactive and pay attention to it from a leadership perspective. Make sure that talking with your developers is part of your technical and business strategy.

How does your advice regarding technical debt and code quality adapt to startups with a very tight timeline to launch products? (00:11:53)

You’ll always take on some technical debt, and you should. In the beginning, it is expected since you’re experimenting and pivoting. But, as you grow, your product starts to become more mature. So you know you’ll have technical debt from the beginning, but you’ll need to work on it at some point without slowing down the business too much.

Abstractions and decoupled architecture are a good way to go because, if you end up with a component or service designed for experimental features, it’s easier to rebuild them afterward. Plus, make sure there is a strong collaboration and communication between product and engineering, and guarantee that those trade-off conversations about quality actually happen.

The parts of tech debt that are important are the ones that are slowing you down from accomplishing your goals. As an engineering leader, communicating to the product organization the impact this particular tech debt will have will help the team prioritize it. But not all technical debt needs to be solved immediately; you just need to make sure your tools are sharp and that your team can move fast.

What is the importance of quality and coding standards? (00:16:39)

The attention you pay to standards varies as you grow. When you’re a small team, you communicate with each other and are generally on the same page. But, as you scale, you are rapidly expanding your technical scope, and you start having duplication of effort and cost across your organization. Sometimes, having that duplication is important because teams need to be independent to move quickly. But, at some point, that duplication no longer serves.

You’ll need to reduce the variety so that your organization can become more efficient in terms of cost and knowledge base. Enforcing the standards is tricky because you don’t want to impact the team’s velocity and introduce friction. You need to spend some time building consensus, decide what your standards should be, and then automate them. Have tradeoff conversations and make sure teams have a voice, or they’ll reject the standards.

What’s the role of leadership when it comes to technical debt and keeping great code quality? (00:23:03)

The culture has a great impact. And culture comes from the leaders and from what they talk about and what they value. If they speak about high-quality software, then the teams will understand what they are trying to build. When a team is over-engineering, the leader often hasn’t shared enough business or product context.

Is also important to also have a balance between leadership, product, and engineering. You need to make sure that everyone is aligned with the business context. Making decisions based on that context is the most important thing. You have more success when you have that transparency and balance within the organization, and when you lead by example. 

You must also highlight code quality in the roadmap and speak about high-quality code with your teams. Give them the entire context and explain why it is important. At the same time, create an operating model that allows tech debt to exist (because it’s inevitable) and balance product and engineering.

How do you explain to other departments of the business that you need to focus development time on stability, maintenance, and paying back some of that tech debt? (00:26:53)

There is a dysfunction in your organization when different departments have their own goals and incentives, and they have competing or incompatible incentives. That indicates a failure at the leadership level to make sure that everyone is aligned with the business goals.

You need to explain to all departments what is the cost of the inaction. You need to have the whole organization aligned on the business goals. So be transparent and make sure that everyone understands. Plus, when talking about the impact, quantify it, besides explaining what might happen. You need to quantify the friction, understand it, and have a continuous improvement process to reduce that friction. Then, you can better negotiate.

Which are the arguments for teams to keep quality and stability as a top concern in the roadmaps? (00:33:43)

Is stability tech debt? Sometimes, what we’re calling technical debt is not tech debt at all; they are things that have actual benefits and should be in your roadmap. But in terms of what you can do, make sure you have enough information about why your product is unstable. One of the useful sources is the call center making up for the technical debt or the stability problems. 

One of the exciting things about tech debt is that it is a tool you can use to move faster, whether because you’re trying to meet a deadline or trying to find that product-market fit. So there are times when it is a reasonable choice, and there are times when it’s not. But the option to make tech debt never goes away. So you also need to the conscious of how you’ll resolve that technical debt. And it goes back to balance. 

If I only produce tech debt, I will hit a point where my productivity suddenly drops, and I will fail as a business. Am I continuing to pay attention to tech debt at the same level I’m taking on tech debt? If you’re taking tech debt to meet business objectives, you should also consider resolving that technical debt as appropriate. If you have measurements and metrics, you can know when you surpass your limit and need to pay attention to it. So you need to identify trends and correlate those trends to behaviors in the system.

How do we decide on the point of no return? When do we see that we need to tackle technical debt? (00:39:00)

The question becomes: can you identify what is slowing you down and what’s holding you back? For that, you need to listen to your engineers more because they are the ones who know; they are the ones who are facing it and dealing with it every day. So trust your engineering people, and they should be able to map the pain and the friction back to the business objectives. 

If you never pay attention to tech debt, you’ll get to a point where it is so horrible that it would be easier and maybe faster to start from scratch, and that’s always a dangerous choice. So try not to get into that situation in the first place: look at your leading metrics, manage and look at your trends overall and pay attention to them. 

One of the ways to tackle is to ask yourself not only what is going to happen right now, but what’s going to happen 6 months from now? How bad is my pain going to be 6 months from now? Then, use that future pain as one of your decision criteria. If you’re not paying attention to the metrics that can help you navigate your tech debt, pay attention to your team and how bad they’re hurting.

Thank you to everyone who joined live and those who watched the recording later on! Let’s keep the conversation going in our community.