I recently read a post - Why the way we look at technical debt is wrong.

I do agree that for a company it is important to reach to its users as soon as possible. However, in my opinion, a growing startup, which has got millions of active users, but is still struggling to find product-market fit, can not afford to take a lot of short-term calls very frequently.

Although a company can be structured such that small teams function as independent startups, but if team hasn’t invested in building frameworks, modules and services and writing good code in general, their iteration speed will be slow. And most unfortunate thing for a company with slow iteration speed would be it’s inability to cope with growing number of users and their requests. I think, each growing startup needs to understand the scale at which it operates and how to try out various things in a controlled manner.

Agility is important. And, however well one plans, after every x time, one will have to fix technical debt - because market behaves differently from assumptions made, and to calibrate with that, one will change code/feature to incur some technical debt.

The way to look at this is to build version 0 which can help to validate initial assumptions and then version 1 and so on - this should happen more from product perspective than code. Assuming that code which was written for version 0 will work with version 2 is not right and this is the most common problem which most non-technical product owners face. They should accept that it may so happen that one will have to go and rewrite whole code for version 2.

Companies need to choose - whether going to market early is important or later iterations are also as important. Twitter was built in two days (it was a matter of do or die for them), and you will also remember “fail whales” - it took them more than a year to fix just that. Similarly, Amit Singhal did a complete rewrite of Google’s search engine in 2001.

Another thing which works very well for smaller startups, but affects mid-sized growing startup in a negative manner is chaos in the company. Reducing chaos, so that every employee can focus is important. You loose a lot in context switch - at times, this is unavoidable, but accepting it as normal is a problem.

Such companies also need an environment where everybody is productive and people only worry about problems in hand. Employees use abstractions, work at higher level and also build abstractions for others. Startups mean chaos - true, but according to me, it should be imposed by market forces only. And even then, attempt should be made to reduce it.

It is said successful entrepreneurs take only calculated risks and work towards minimising them. I believe, they also work to allow only structured chaos in their companies. Look around, all successful entrepreneurs and companies have done the same.