Technology teams can be the biggest asset or worst bottleneck for a growing company. You can see the ‘hidden frustration” in Bezos words below.
I have asked engineers to be fast acting cowboys, instead of calm clear-headed computer scientists
Jeff Bezos, Founder & CEO, Amazon
Future Paranoia – Rampant Problem in Industry: When the task is to build a bike, the product and technology teams would plan for a product, which can later run on a motor, seat four people, sail in the sea and even fly in the future. This hypothetical building of the castle in the air diverts focus from the real problem. This is what Bezos is asking us to refrain from, as it wastes resources and agonizingly 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 which plagued product companies. It encouraged building the minimum required at a certain point of time and then iterating and improving it based on user feedback. MVP approach enables much needed fast experimentation, fail fast and invest where needed strategy.
No such philosophy evolved for Technology. Therefore, the decades-old defensive and paranoid philosophy still prevails (which was much needed 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 most engineers blindly try to copy strategies of large companies. Corporations and startups differ widely on their needs of scale, brand, speed, an impact of a feature, loss by a bug, etc. Startups enjoy more freedom to make mistakes and that they should make the most of it.
Strategies used in big companies are 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 a.s.a.p. and then iterate and improve it based on feedback from real users. Every company is in a different stage of evolution. 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.
Startups experiment a lot and only a few of them sustain the test of time. As per 80–20 rule, only those 20% successful ones should get deeper technology investments.
Principles of Minimum Viable Technology (MVT):
- MVP + MVT + Agile is the complete package.
MVP is for product scope minimisation. MVT is for technology scope minimisation. Agile is for iterative technology execution.
- Most decisions can be reversed or fixed easily. Choose wisely by bucketing the decision accurately into reversible or non-reversible. And judiciously decide how much to prepare for that case. (Read Jeff Bezos’ two types of decisions).
It’s important to internalise how irreversible, fatal, or non-fatal a decision may be. Very few can’t be undone. — Dave Girouard
- Build MVT — Fast & cost effective. Build the Minimum Technology that makes the product and their foreseeable iterations Viable. Prefer operational familiarity while choosing technology. Don’t fall for the latest buzzword.
- Refactoring is part of success plan: Getting to refactor is a sign of success. Only components which are used and evolve fast; become complex over time and need to be refactored. Be ready to re-factor or throw away and rebuild where justified.
The best code you can write now is the code you will discard in a couple of years time.
- Think long term, act short term: It’s a fine line between under-engineering and MVT approach. Don’t rush into execution without sufficient analysis, otherwise, it will lead to more resource waste later. Deliberate choices must be there to cut scope. The rule of thumb is to discuss the ideal solution on board and then decide what to take out of scope to make it MVT.
- Speed and Quality must go hand in hand: Never justify the bad quality of your work by using the speed of execution as an excuse.
MVT is for scope reduction, not for quality reduction.
- MVP/MVT is applicable for every iteration/release: People relate MVP to the First release of the product only. In fact, it applies to every stage. MVP/MVT needs to be chosen from the remaining next tasks at every stage. At no stage, it is ok to waste time and resources.
Foundations for MVT execution:
- Deep understanding, conviction and confidence are needed for MVT. Both MVP and MVT approach are about taking bold calls like — “Out of these tasks, only this much is enough to win this stage of game”. While the defensive traditional approach is like — “we can’t win or sustain if we do not do most of the known tasks”.
- Alignment across departments is must for MVT execution. MVT reduces time to market in 80% of cases, by focusing on the core of what is needed. As per 80-20 rule, only 20% will need re-factoring and re-architecture later. Due to mistrust and friction between departments, they keep blaming each other for mistakes. This leads to engineering (and others) being defensive and therefore over prepare to avoid any mistakes. This is explained and solved in Solver Teams post. In ST approach, all parties are in hot sync and are aware of the trade offs taken while executing. So there is strong understanding and support for such efforts.
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 has been republished by leading technology/startup media like Tech-In-Asia, Your-Story, Inc-42, I-Am-Wire etc.
Engage your mind, Inspire your Creativity & Develop your career with Knowlarity.