Recently I confronted the fact that I could not articulate technical debt and what it means in my product. I trust my team to tell me what technical debt is and what’s worth fixing. On a Kubernetes platform, what I would have considered technical debt before is less so. It still exists. Paying off zero technical debt is a massive risk. Before this week, I could not articulate technical debt on my own via my writing. I would realize that I don’t understand what it means concerning my product. Instead, I let it linger. Solved by my team or until we ran into a significant issue.
The reforge curriculum states there are four types of technical debt. I think this is reasonable to wrap one’s head around. Reforge defines technical debt as work that needs to be completed but is not a priority.
- Non-Roadmap Work
- Deprecating Tech
- Unplanned Work
You can prioritize technical debt via five factors. Confidence, time, impact to the user, sequence, and accumulated debt. These sit on a scale from low to high. They further categorize technical debt into three categories. Systemic debt, extinction event debt, and paper cut debt. I can pass this framework on to the team and ask them to prioritize based on this information.
Communicate to others how to fix a problem. If a problem arises, you need to solve it and not bother assigning any blame. You will become a bottleneck and burn out if you attempt to solve all problems and have all the answers. Empower those around you to leverage your clear thinking to solve their problems using your frameworks you’ve developed. If you do not have a framework for solving a problem, seek one out. There is little out there that is brand new. You can find someone that will help you that’s been through your situation. Stop giving answers. Ask clarifying coaching questions like, How would you solve it?
It feels nice to answer questions and be a resource for people. Some questions demand more than a few moments of thought before delivering an answer. Develop the habit of considering whether a question deserves more thought and deliberation. Providing a quippy response or agonizing over collecting your thoughts as you wade through your thought process does no one any good. Tell us this is a great question that I need to consider, let me get back to you. Use writing to gain clarity for yourself. Am I the right person to even answer this question? Am I credible to convey this message?
As a leader, you need to express new information to convince your team to change their behaviors. When I encounter strategies, tactics, and frameworks, I need to apply them to my situation and reshape/reconfigure the concepts in my understanding. As I do this, I internalize it as part of myself. Into my operating system. If you are not growing, changing, and transforming, why should you expect your team to do that?
- Use writing to reflect what you know and do not know about a topic.
- If you know something, continue to refine it, poke holes in your ideas, critique it, and approach it from many angles.
- Word vomit on a page, go for a walk, sleep on it, write it out again, write it out again, get feedback, then it might then be worth sharing.