A technology team can be the biggest asset or the worst bottleneck for a growing company, based on their strategy. In the name of future proofing engineering, technology teams become a hurdle to a company’s goals. You can see the hidden frustration in Amazon chief Jeff Bezos' words below:
“Engineers should be fast acting cowboys instead of calm clear-headed computer scientists”
When the task is to build a bike, the product and technology teams would plan for a product that can later run on motor, seat four people, sail in sea and even fly in the future. This hypothetical building of castles in the air digresses the focus from the real problem to be fixed. This is what Bezos is suggesting to refrain from, as it wastes resources and agonisingly delays the time to market.
Being defensive, the product/technology teams usually build a cannon for killing a bird.
Minimum Viable Product (MVP) philosophy evolved, to avoid this ‘unnecessarily over-thinking and over-preparation’ problem that plagued products in all companies. It encouraged building the minimum required at a certain point of time and then iterating and improving it going forward. The MVP approach enables the much needed 'fast experimentation, fail fast and invest where needed' strategy.
But, no such philosophy evolved for technology. Therefore, the decades-old defensive and paranoid philosophy still prevails (which made sense during older 1–2 year-long waterfall releases). This becomes a competitive disadvantage for startups usually fighting for survival or growing fast.
The fundamental problem is that the engineers tend to ape the strategies followed by large companies, considering them to be the standard. But, corporates and startups differ widely on their needs of scale, brand, speed, impact of a feature, loss by a bug etc. Startups enjoy more freedom to make mistakes and they should exploit this to their benefit.
Strategies used in big companies are more often irrelevant and even detrimental to a small growing company’s interests.
Minimum Viable Technology: The solution to the above problems is to build the minimum technology that makes the product and its foreseeable further iterations viable. Make it live as soon as possible and then iterate and improve it based on real usage learnings. Every company is at a different stage of evolution. So something that is MVT for a big company can be over-engineering for startups.
If the task is to kill a bird, we should build a catapult/small gun to begin with. If that becomes successful and there is a need to kill more or bigger animals, then bigger guns/cannons should be built as required.
There is nothing so useless as doing efficiently that which should not be done at all, said management guru Peter Drucker.
Startups experiment a lot and only a few of them sustain the test of time. As per the 80–20 rule, only those 20 percent that are successful should get deeper technology investments.
Principles of Minimum Viable Technology (MVT):
MVP is for product scope minimisation. MVT is for technology scope minimisation. Agile is for iterative technology execution.
It’s important to internalise how irreversible, fatal, or non-fatal a decision may be. Very few can’t be undone. — Dave Girouard, Founder and CEO, Upstart
The best code you can write now is the code you will discard in a couple of years' time. - Martin Fowler, Software Development Consultant
MVT is for scope reduction, not for quality reduction.
Move fast. Keep shipping
* The term 'Minimum Viable Technology - MVT' is coined by the author.
* The article is based on engineering execution done in a startup from scratch.
This article was first published by the author on LinkedIn
(Disclaimer: The views and opinions expressed in this article are those of the author and do not necessarily reflect the views of YourStory.)