# Reframing Tech Debt - Leemay Nassery Synced: [[2023_11_30]] 6:03 AM Last Highlighted: [[2023_11_06]]  ## Highlights [[2023_11_06]] [View Highlight](https://read.readwise.io/read/01hehsgaby4jtrpx2bpw5y5rnn) > Building tech wealth means getting more value out of the software we’re creating, as well as our efforts to develop and maintain it. [[2023_11_06]] [View Highlight](https://read.readwise.io/read/01hehshh0ndyp9azgkx1q0ns4g) > 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). [[2023_11_06]] [View Highlight](https://read.readwise.io/read/01hehsm2h8aerynpms778477rt) > 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. [[2023_11_06]] [View Highlight](https://read.readwise.io/read/01hehsqggygb5vg0z1q9h8692h) > 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. [[2023_11_06]] [View Highlight](https://read.readwise.io/read/01hehsr0xyx1j0p329p0rpyekj) > 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. [[2023_11_06]] [View Highlight](https://read.readwise.io/read/01hehssjvath05kekjfwvawzfm) > 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. Y