Technology teams can be the biggest asset or worst bottleneck for a growing company based on the strategy taken by them. In name of future proofing engineering, the technology teams become a hurdle to company’s goals. You can see the ‘hidden frustration” in Bezos words below …
Engineers should be fast acting cowboys instead of calm clear-headed computer scientists — Jeff Bezos, Founder & CEO, Amazon
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 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 which 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 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 one–two-year-long waterfall releases). This becomes a competitive disadvantage for startups usually fighting for survival or growing fast.
A fundamental problem is that the engineers blindly copy the large company’s strategies, considering them to be the standard. Corporate 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 that they should exploit 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 above problems is to build the minimum technology that makes the product and its foreseeable further iterations viable. Make it live ASAP and then iterate and improve it based on real usage learnings. 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. ~ Peter Drucker
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 properly 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 (sure sign of inexperience).
- 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. – Martin Fowler
- Think long term, act short term: It’s a fine line between under-engineering and with MVT approach that has to be tread properly. Don’t rush into execution without thinking completely, otherwise it will lead to more resource waste later. Thinking has to complete and 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 excuse.
Benefits of MVT
- MVP/MVT is applicable for every iteration/release: People relate MVP to the First release of 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.
- Deep understanding, conviction and confidence is needed for MVT: Both MVP and MVT approach is about taking bold calls like — “Out of these tasks, only this much is enough to win this stage of game”. While 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 a 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 looking for faults in others. 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 tradeoffs 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.
[This post by Ajay Srivastava first appeared on LinkedIn and has been reproduced with permission.]
