Day 5: Managing Technical Debt with Clarity and Strategy
Be Better Engineering Leader, a 30 Days Series
This is the first week of a series of daily lessons on how to Be a Better Engineering Leader. I recommend spending up to an hour on each lesson to gain insights into Product, Technology, and People—areas critical for every Engineering Manager.
Technical debt represents inefficiencies in your tech stack that hinder your ability to achieve business goals.
This can include issues like outdated code, lack of test coverage, or manual deployment processes. It's crucial to communicate the impact of technical debt in business terms. Instead of saying, "We need to fix our technical debt," explain it as, "Our current system setup causes delays in feature releases, impacting our time-to-market and customer satisfaction."
Context Matters: Is a Monolithic System Technical Debt?
The answer depends on your context:
Yes: If the monolith hinders multiple teams due to strong coupling, a single repository, or fixed release cycles, making collaboration and deployment difficult.
No: If a small team can manage it efficiently, benefiting from simplified infrastructure, monitoring, and maintenance.
Always evaluate the impact on your team’s ability to deliver value when assessing technical debt.
Two Approaches to Managing Technical Debt
Continuous Improvement:
Implement the Boy Scout Rule: leave the codebase better than you found it.
Integrate small improvements, such as refactoring code, updating dependencies, or improving test coverage, into your daily work.
Your role as a leader is to set expectations, establish clear metrics, and celebrate progress.
Large-scale Projects:
For more complex issues, treat them as standalone projects with clear business goals.
Example: Migrating from a monolithic to a microservices architecture might require months of effort and significant resources. Secure stakeholder buy-in by using frameworks like Amazon’s Working Backward/PR Release to align with business objectives.
Identifying Technical Debt
Qualitative Feedback:
Gather insights through 1:1s or feedback surveys. Ask your team about their biggest pain points and suggestions for improvement.
Example: Conduct a workshop to list all technical debt items affecting the team.
Quantitative Feedback:
Use metrics like deployment frequency, incident counts, system stability, or the duration of CI/CD steps.
Example: If deployment frequency is low due to a complicated release process, it signals technical debt in your deployment pipeline.
Action Points
Document Your Technical Debt:
Create a living document listing all known technical debt.
Use either the Google or ThoughtWorks classification frameworks.
Classify and Prioritize:
Conduct a workshop with your team to classify each item based on impact and effort required.
Use a value/effort matrix to prioritize items with the product organization and business.
Create a Roadmap:
Integrate high-priority technical debt items into your product roadmap. This ensures alignment with business objectives and secures resources.
Resources for Further Reading
Cheatsheets:
Take Action Today!
Start by creating a document and listing your known technical debt. Classify each item and decide on the best approach to tackle it. This simple step will provide clarity and help you communicate technical debt effectively within your organization.
Share Your Feedback
How valuable was this lesson for you? Please share your reaction, write the feedback in the comment, as a response to the email or talk to me directly on chat. I would be thrilled to get to know you better so I can adjust my content accordingly.
Has your friend forwarded you this lesson? Consider joining the “Better Engineering Leader” course. More details here.
Do you know anyone who can benefit from the content I share? If so, please forward this email to them.