https://increment.com/planning/reframing-tech-debt/ Increment NEW Buy the print edition * Issues * Topics * Store * About Reframing tech debt Leemay Nassery Reframing tech debt If we bake addressing tech debt into our plans, could it become an opportunity to build abundance into our systems? Part of Issue 19 November 2021 Planning Tech debt--the two words engineers loathe more than deploying a "quick fix" on a Friday and product owners fear more than missing an OKR deadline. New architectures don't magically diagram themselves on your whiteboard overnight. Often, tech debt results from taking too many technical shortcuts when building out features. You know the drill: The product team creates an ambitious roadmap that leaves little room for error, and engineers hack on top of an already archaic software infrastructure to enable those ambitions. The debt creeps in like a child tiptoeing into the kitchen to sneak cookies from the pantry, resulting in a gradual erosion of your system's efficiency--and a whole lot of crumbs to clean up. When quick and dirty hacks become an engineering organization's default mode, it can be tough to advocate for doing things the "right" way, dedicating time and effort to formulating detailed requirements, building robust solutions, or automating manual tasks. Paying down tech debt is frequently seen as the less glamorous, less exciting side of software engineering. Migrations aren't fun, and neither is replacing old dependencies with new ones. New architectures don't magically diagram themselves on your whiteboard overnight. But when left unexamined for too long, tech debt can go from a neglected nuisance to a catastrophic failure. In contrast, when addressed proactively, tech debt represents an opportunity to build resilience and robustness into our systems. That's why I propose we rebrand tech debt as tech wealth. Introducing tech wealth Carving out time to pay down tech debt requires buy-in from leadership. Getting that buy-in is hard, especially since end users may not directly feel the impact of many tech debt investments, such as improved tooling or automated processes. In fact, many development teams have a pervasive misconception that since tech debt doesn't impact the user, it's not worth prioritizing. But in reality, addressing tech debt enables us to devote more time to feature development later on. Dealing with the system's weaknesses up front means engineers will spend less time wrangling spaghetti code or solving neglected issues in the future. By framing tech debt as tech wealth, we can minimize the negative connotations associated with such debt and put these false impressions to bed. This rebranding can shift leadership's perception of these vital behind-the-curtain investments, increasing the likelihood they'll buy in on the work. In business, building wealth is something to be done as soon as possible, with great care and focus. Likewise, doing the fundamental work to make your systems stronger and more efficient should be viewed as worthy of up-front investment. Defining tech wealth What value do we get from spending time accomplishing a specific task? What gains do we acquire as a result of that work? Wealth, by definition, is an abundance of valuable possessions, goods, or resources. For an engineering team, building wealth could mean increasing productivity, engineer happiness, system stability, and so on. When we understand our technical overhead in this way, we can focus on communicating value: What value do we get from spending time accomplishing a specific task or initiative? What gains or resources do we acquire as a result of that work? Building tech wealth means getting more value out of the software we're creating, as well as our efforts to develop and maintain it. When reframing tech debt as tech wealth, we can ask ourselves the following questions to clarify the value-amplifying opportunities available to us: * What steps can we take to help our teams move faster and more efficiently? * What can we do to improve our systems' scalability or stability? * What work could improve engineers' experience maintaining those systems? Let's take deployment automation as a practical example. By dedicating engineering time to creating the infrastructure for automating production deployments, you might gain tech wealth in terms of increased speed to production (because users will receive new features or bug fixes more quickly), greater developer happiness (since engineers will spend less time manually deploying releases to production and can focus on more engaging work, like feature development), and reduced risk (by removing human error from the deployment process). This high-value investment improves the fortunes of your users, developers, and the system itself. Planning for tech wealth Once teams have allotted engineering capacity to new feature work, there's often little time left over for building tech wealth. Assuming you can't just pause feature work--although I'd love to see an engineering team try!--the following strategies can help teams start incorporating tech wealth into the planning process. Allocate time within each planning cycle Does your engineering team use a fancy formula to determine how much capacity you have for development work during each planning cycle? If so, consider allocating a small but meaningful portion of that capacity to building tech wealth. The appropriate amount of time will depend on your team's needs. For instance, if you want to increase integration or unit test coverage, assigning 80 percent of your engineering time to product development and the remaining 20 percent to building tech wealth might suffice. If your team needs to evolve the architecture or system to meet new requirements, you may want to set aside 60 percent of your time to build tech wealth and 40 percent for product development. The advantage of incorporating tech wealth into every planning cycle is that it becomes part of your team's regular cadence, which normalizes the practice. Your team can even begin to attribute success metrics to the wealth you accrue each cycle. For instance, you might track the number of bugs introduced before and after you invested in building out automated test coverage. If you don't use a fancy formula to determine engineering capacity, start simple. If your team is big enough--say, at least four engineers--one person can focus on building tech wealth each cycle. Consider establishing a rotation so each engineer has a chance to work on tech wealth projects while also getting to build the splashier stuff. Regardless of the approach you take, be sure to define and document the value your tech wealth tasks produce. This will help sustain buy-in on these investments. Dedicate the last few cycles in a quarter If you can't commit to a fixed amount of time each sprint, iteration, or planning cycle, you may want to carve out a certain period each quarter instead. For most teams, the end of the quarter is a suitable time to do this; once you've completed feature delivery or are in the process of A/B testing features, you'll likely have more engineering hands free. As for how long that period should be, it depends on the wealth you're trying to accrue. If you're not sure where to start, try a couple two-week iterations, which should be enough time to start filling your tech coffers. Unlike the first path I laid out, this quarterly strategy will require 100 percent of your team's capacity, albeit temporarily. I've found it particularly helpful in situations where the investment required multiple engineers' time and energy. This approach encourages focus and decreases context-switching, but it will take willpower--and some firm boundary-setting--to ensure business or product stakeholders don't slide into your engineers' DMs hoping for one last "quick change." Another benefit to this strategy: You can use the time to tidy up any hacks or workarounds implemented earlier in the quarter, when the team was striving to meet product goals. If you're building tech wealth on a quarterly basis, you might find it useful to maintain a backlog of tech wealth projects for your team to consult. For example, you could create a Jira project or Trello board dedicated to keeping track of the wealth you plan to build. This will help keep your upcoming plans clear and your tech wealth goals in sight. Create tech wealth, reduce tech debt By planning for tech wealth, you are, in fact, diminishing tech debt. By planning for tech wealth, you are, in fact, diminishing tech debt. This subtle shift in perspective can give engineering teams and leaders a fresh outlook on this essential--but perhaps less glitzy--aspect of our work as software developers. Where tech debt implies a lack, tech wealth suggests abundance: an abundance of security and stability for your systems, and an abundance of time and satisfaction for your engineers. Once you incorporate tech debt into your planning cycles, you can enjoy the benefits of this plenitude. You'll be able to streamline your systems, increase innovation, and, ultimately, build better products for your users--even if they don't necessarily behold all the gorgeous, glittering wealth you've built behind the scenes. About the author Leemay Nassery is an engineering manager at Dropbox. Previously, she led engineering efforts in the personalization domain at Spotify and Comcast. @leemaynassery Artwork by Steph Coathupe stephcoathupe.com Topics Essays & Opinion Guides & Best Practices Buy the print edition Visit the Increment Store to purchase print issues. Store Keep in touch Share your email so Stripe can send you occasional email updates about Increment. Thank you! We'll be in touch. [ ] You can unsubscribe at any time. Please see our Privacy Policy for more information. Continue Reading * 14 APIs Leemay Nassery How low (code) can you go? On low- and no-code solutions and streamlined possibilities for API integrations. * 19 Planning Romello Goodman Planning for pause As a companion to agile development practices, milestones offer a meditative--and productive--opportunity to decelerate. * 19 Planning Melissa Huang The great tightrope act By thoughtfully balancing ideas and inputs during the planning process, engineering managers can enrich team impacts and business outcomes. * 19 Planning James Stanier Planning for momentum On reimagining planning as a dynamic and generative process. * 19 Planning Upeka Bee Planning in the dark When planning product development before you have product-market fit, continual iteration and getting comfortable with discomfort can help light the way. * 19 Planning David Noel-Romas An IC's guide to roadmap planning How individual contributors can leverage their unique perspective to advance alignment and clarity of vision. * 19 Planning James Turnbull A primer on product management for engineers Breaking down the basics and benefits for engineers looking to manage product development with precision and verve. * 14 APIs Michelle Bu Eagerly discerning, discerningly eager Approaches to crafting delightful, effective APIs that offer developers both convenience and stability. * 19 Planning Pete Hodgson Road to somewhere By sharing both the route and the destination to our strategic objectives, we can set ourselves up for a smooth planning journey. Explore Topics * Learn Something New * Scaling & Growth * Ask an Expert * Interviews & Surveys * Guides & Best Practices * Essays & Opinion * Workplace & Culture All Issues * Issue 19 November 2021 Planning * Issue 18 August 2021 Mobile * Issue 17 May 2021 Containers * Issue 16 February 2021 Reliability * Issue 15 November 2020 Remote * Issue 14 August 2020 APIs * Issue 13 May 2020 Frontend * Issue 12 February 2020 Software Architecture * Issue 11 November 2019 Teams * Issue 10 August 2019 Testing * Issue 9 May 2019 Open Source * Issue 8 February 2019 Internationalization * Issue 7 October 2018 Security * Issue 6 August 2018 Documentation * Issue 5 April 2018 Programming Languages * Issue 4 February 2018 Energy & Environment * Issue 3 October 2017 Development * Issue 2 July 2017 Cloud * Issue 1 April 2017 On-Call @incrementmag incrementmag RSS Feed About Increment is a print and digital magazine about how teams build and operate software systems at scale. Learn more Work with us Interested in joining the team at Stripe? View job openings (c) 2021 Increment Published by Stripe Privacy policy