As an engineering leader, I’ve seen the following pattern play out multiple times, across multiple companies
- Executives complain about engineering velocity not being high enough. “I just want to show the user’s birthday on the settings page. Why does that take a whole year?”
- Engineers respond that tech debt is holding them back
- Executives tell managers to work on “Tech Debt Improvements” in order to improve velocity
- Managers go looking for big “Tech Debt Projects” to put on their roadmap
- Ambitious engineer pitches a big shiny project that is fun to work on, looks great on the resume, and/or will get them promoted. “Let’s migrate to an Event Driven Architecture. And this time, we’ll do it Right™”
- Manager loves it because it demonstrates impact, looks good on their resume, and shows that they are actively “Improving Eng Velocity”
- Executives have no idea how the current system works, much less how the proposed event driven architecture would work. But they like it because it promises a solution to their biggest problem. “In the future, I’ll get all the features I’m asking for in a fraction of the time!”
- Half the engineering team gets pulled in to work on the Big Tech Debt Project for the next few quarters. Minimal user-visible improvements are delivered in the meantime
- One year later, the project is wrapped up. Everyone celebrates. People get promoted
- Engineering velocity is now slightly better. But still bottle-necked by numerous other problems that have not been addressed
- More tech debt starts piling up on the new system, as soon as the first feature request comes in
The trap that people keep falling into over and over again: assuming that “Tech Debt” is a single technical problem. And the best way to solve it is by putting an item on your roadmap, where you tell a few people to “go work on Tech Debt™ for the next month”.
The reality is t
