Organizations often migrate monolithic architectures to microservices based on ad hoc data, expert opinions, or industry trends without assessing their specific context and needs. Such transitions tend to coincide with increased architectural complexity and technical debt (TD), making it crucial to understand how TD evolves over time in industrial settings to manage it effectively. This observational study explores the evolution of technical debt density (TDD) in a single software product consisting of both monolithic and microservice architectures at a Swedish fintech company, without aiming to establish causality between architectural styles and TDD trends. We further investigate TDD trends across various microservice size categories, team types, and the relationship between size and TDD. We analyzed SonarQube TD data collected from one monolith and 78 microservices from August 2022 to December 2024, and conducted semi-structured interviews with practitioners (a development manager, a product owner, and a lead developer) to validate and contextualize the quantitative findings. Our results show that, in this case, the monolithic system exhibits a decreasing TDD trend over time despite continued growth in size, while a gradual increase in TDD is observed across microservices. Furthermore, TDD trends appear inconsistent among small microservices, more consistently growing in medium-sized microservices, and comparatively stable in larger services. Differences in TDD trends are observed across services owned by platform teams and product teams. Overall, the findings from this specific case suggest that TDD evolves differently in monolith and microservices, highlighting the importance of continuous monitoring and context-aware interpretation of TDD trends in practice.

Background: Software companies must balance fast delivery and quality, a trade-off that often introduces technical debt and wastes developer's time. Technical debt tends to increase as software evolves, which is assumed to slow down development and maintenance activities. However, the potential relationship between technical debt and lead time lacks empirical evidence. Objective: This paper reports an empirical study to explore the potential relationship between technical debt and lead time in resolving Jira tickets. We further aim to measure the extent to which technical debt can explain the variation in lead time. Method: We conducted an industrial case study to explore this relationship in six components, each of which was analyzed individually. Technical debt was measured using SonarQube and normalized with the component's size. Lead times to resolve Jira tickets were collected from Jira and averaged monthly. Results: The study found little to no correlation between technical debt and lead time to resolve Jira tickets in five components, with technical debt explaining a variation in lead time ranging from 0% to 41%. However, it is less than 30% in most of the components. Conclusion: Technical debt alone does not fully explain the variation in lead time. There should be some other confounding variables (e.g., size and complexity of the changes, number of teams involved, priorities, component ownership) affecting lead time or a residual effect, i.e., interest, that might manifest later. Further investigation into those confounding variables is essential.