The Context
Before you accuse me of clickbait – here me out. This is a very important lesson for people that want to grow into leadership roles.
- Technical leads and developers growing into product / company leadership (e.g., VP Technology, Directors, etc.)
- Gaining seniority and experience as Technical Architects
- Incorporating new roles in your teams such as Product Management
That last one is important because it’s the lens that I’m using to come up with such an attention grabbing title for this post. The world of Product Management and Technical Architecture is not as black-and-white, simple and controllable as we all wish it would be.
Technical Architecture specially is a world of trade-offs. As Technical Leads we should be comfortable in navigating conversations and decision making when technical foundations is not the only variable to consider. This is the world of product roadmapping, product evolution, Lean Startup, MVPs, test-driven approach, and yes, you guessed it… technical debt as a best-practice. You have to be comfortable with it.
As technical leads and sound-architecture people, we think of technical-debt as something to be reduced and removed from our codebase and solutions. And you are not wrong. But technical-debt can be a very powerful technical strategic tool that drives product development, client buy-in and feature prioritization. View this from the lens of Product Management, test-driven approach, or even simply when working with very aggressive, non-negotiable timelines.
Let’s talk about Feature A
Developing it the “right way” takes 1 month and lots of investment, but you have 2 main drivers for your approach:
- The feature needs to be client-facing in 2 weeks
- You don’t even know if the feature is valuable and is worth the effort… yet
What do you then? Do you push the product team and/or the client and argue that it’s not feasible? Or can you think of a win-win scenario where you deliver on the end-user feature, but at the same time you make room for creating it the right way?
Technical Debt as a Best-Practice
We can intentionally introduce technical debt as as solution. We can have a quick/dirty, yet perfectly usable feature in 2 weeks. Then once tested and validated, we can do the refactoring necessary to make things right.
A real example: a CMS-powered front-end component.
What matters is that end-users see the new content on your website. The backend and how that data is managed is hidden from the user. For the quick-dirty solution we can focus on the front-end and have its content powered by a JSON file, or even embedded to the HTML (hey, no judgements here). For the right approach we proceed to do the refactoring of the backend and move the JSON logic and content to properly modeled CMS content items with workflows, metadata, templates, etc.
It might not be the prettiest approach, but you would be surprised how many opportunities and doors open if you are flexible to think about your product as an evolution rather than a do once and forget.
Best Practices
What is key is that your intentionally introduced technical debt does NOT become real and permanent technical debt. Here are a few recommendations and best-practices that should help you navigate this approach.
Nothing more permanent than a temporary solution
If you personally know me, you know how strong I feel about this one. Am I contradicting myself, is this a paradox? It’s the nature of the real-world, and as pragmatic technical lead we are pushed to this world of trade-offs. My recommendation is to always have a long term plan of how and when (not a question of if) you’ll tackle the technical debt. Have this plan and roadmap very clear. Get sign-off from the client and product leads and hold them accountable that it’s a priority for the team.
Architecture purists/fundamentalists
Sometimes the push back comes from within your dev team. Don’t blame them – “the burn child dreads the fire”. How many times does tech, as the last link in the chain, have to suffer because of decisions made somewhere else – always rushing, the only team without an extended timeline, etc.
Work with them and be a good leader. The team gladly follows those they can trust. Give them the big picture and if you really have sign-off from the client and leads, guarantee them that you will get back to make things right. After a few iterations of this process, they’ll understand why decisions are being made, and that sometimes what looks like a bad direction actually works for the best in the long-run.
Create rapport with Account and Client
Create a trustworthy relationship with your non-tech peers. Work with them so they understand that what to them seems like an unworthy investment in a good technical foundation, it will benefit them in the near future.
Going back to the CMS-powered front-end component approach, the MVP version might look like enough, but every single content update will be a mess, prone to errors and highly inefficient if you have to do so with JSON files. On the other hand, if you refactor it to be CMS-driven, content authoring activities will be quick, painless and you can even use a better rate-card for non-dev resources.
Non-tech peers might not understand technology, but they do understand cost-savings, fast times-to-market and roadmaps.
Be transparent, be honest
If you know you are taking shortcuts and intentionally adding technical debt into your solution in favor of a faster release, make sure that everyone understands it, even your client (if you have one). A roadmap should allow you to demonstrate that you have a plan, and that you understand that what you are releasing is not best-in-class, but that you WILL come back to fix it.
Make sure everyone understands the pros and cons of the decisions being made. Be honest, don’t hide the ugliness from anyone.
MVP vs. Release v1.0
So far I have talked about intentional technical debt as being introduced to an official and release product feature, and how to use it as a strategic tool to balance timelines and sound architectures. Technical debt is even more important in the context of developing MVPs. Let’s talk MVPs.
The Minimum Viable Product (MVP) is defined as “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”. An MVP is an input to the product roadmap process, it is NOT the v1 release of a product.
In that sense, your technical debt is by nature short-lived. You would never invest any more than what’s strictly necessary to build a solid foundational architecture for something that is meant for short-lived testing and feedback gathering. The problem is IF the MVP is being used as your official version 1 of the product. Then your problems are of a different nature. If that’s the case, the prior best-practices might help navigate your specific scenario.
A good post on this: https://www.linkedin.com/pulse/boon-curse-minimum-viable-product-mvp-hemant-madan/
Final Thoughts
I could write a whole book about managing technical debt, but I hope that at least the presented practices help you navigate the product management and technical architectural decision making world, a world of pros/cons, a world of trade-offs.
