The classical dilemma between product and engineering

Are you working with an organization that has been there for a few years? whether it's a 30, 10 or even 3 year old organization, I am quite sure you've faced or facing this now. There is technical debt somewhere, or everywhere, that needs to be paid, and paying that debt will hinder the value you're trying to add to your customer and stakeholders for a certain amount of time. Guess what? you're not alone! And being in the middle of this exercise right now at b_labs , I thought of sharing some thoughts about it.

So, how did this happen in the first place? I believe there are 2 major causes of technical debt:

• The organization did not know better at that time: this can vary from not having the technical knowledge or skills, to not knowing the possibilities or ambitions of value that can be delivered to customers in the future (aka vision)
• The organization chose to have that technical debt, either to go to market faster, or to reduce the software development needed by acquiring a software package; in both cases, it was about prioritizing the present over the future.

Based on the size of the decision, the impact can also be different; a small component here or there that created some technical debt, is different from choosing an ERP as an innovation layer, or build software for years on top of a monolithic architecture; the debt in the later two is very high.

However, even small decisions causing technical debt can be very pricy; technical debt is like cancer, once it starts somewhere, it keeps spreading, a small decision here, a small decision there, and suddenly, there is a sleeping dragon underneath that just waiting to be awaken.

And believe it or not, I have never seen an organization starting to pay their technical debt by choosing to; there was not once that someone said: "hey, we have a technical debt here, so let's rewrite this, or refactor that"; there is always that wake up call, a performance bottleneck somewhere, a new feature that will require a massive change because it was not catered for, a software package that is will not be supported anymore... yes, always one of those bloody wake up calls.

So... what can we do about it as product and engineering people?

Avoid it! but how?

1. Break your big decision into smaller ones; if you're asked to answer the question of how you're gonna build your entire logistics, don't! break that problem down to its smallest pieces, and answer every part separately first
2. Write down your vision, make sure everyone understands it, iterate over it, don't leave too many unanswered questions (there will be always some)
3. Prioritize the future over the present, and if you can't, make sure you have a committed plan to pay the technical debt you're building ASAP
4. Get every expertise you can, talk to similar businesses, learn from others' mistakes; there is no shame of saying "I don't know"

And guess what (again), it will still happen! How can we pay it then?

1. Make sure the organization understands the size of the technical debt you have, and that technical debt must be paid; it's a tumor that has to be chopped off
2. Know very well how long you can live with that technical debt, and don't let the cancer spread, stop adding to it.
3. Choose wisely, a big bang approach might be very pricy, and will make it extremely difficult to introduce any new value to your customers
4. Again, choose wisely, a rip and replace approach may take too long, and will require more effort while you're paying your debt
5. Again and again, choose wisely, replacing an incapable software package by another capable software package may not work, you might be just building another/bigger debt

Happy to hear your thoughts, how you paid your technical debt, what you're doing to avoid it.