Velocity Wins
“Ideas are cheap. Execution is everything.” We’ve all heard this quote more than once: in seminars, board rooms, even on television. This is in part, I surmise, because it is particularly relevant to the fast-moving, dynamic world of entrepreneurs, ie.. Silicon Valley. We regularly read about several startups with virtually the same idea getting funded within a 3-month time span. Some of us may have even experienced that awful “Hey, they have the same idea as we do … we’d better beat them to the market“. Only one company will win: the one that executes the best. Having an innovative, or even disruptive, idea is a necessary condition for success, but it is far from sufficient. Success requires at least one more ingredient (besides luck): velocity, i.e. speed of execution.
Being the first with a particular idea doesn’t guarantee market leadership. A successful company needs velocity-what we call “Silicon Valley Speed”- that perfect blend of vision and execution that brings success.
In the new world, it is not the big fish which eats the small fish, it’s the fast fish which eats the slow fish
– Klaus Schwab, Founder and Executive Chairman – World Economic Forum
Let’s explore five ways to achieve Silicon Valley Speed.
1. Adapt Technology and Methodology to Product Maturity
Company founders often refer to their companies, or their products, as their “baby.” In the way that one parents a child differently at different stages of development, technology and methodology must evolve as the company/product grows from its early stages, to market launch, to hyper-growth mode.
A common error in product development is to attempt to solve for scale and performance too early. This is akin to teaching a 1-year old complex Calculus. In the same way, Hadoop-like technologies that are designed to handle millions of requests per second, or analyze petabytes of data are complex and unwieldy. Unless it is an intrinsic part of the value proposition, burdening an early-stage product with this kind of complexity limits its flexibility, and thus the speed at which the product can be adapted to new market information, and so puts it at risk of losing to a quicker, nimbler competitor.
Similarly, we need to evolve how we grow and nurture our methodology as the product matures. The product’s maturity impacts the engineers we hire, the processes we apply, the tools we use, and how we organize ourselves.
For example, automation may not be critical with 5 engineers building the first version of the product. But as the team grows to 50, and eventually to 500, it becomes inconceivable not to have an automated test suite, continuous integration, and an automated build-deploy tool chain. Regression testing is an important use case: I have seen many many companies, typically enterprise software, that are plagued with weeks of manual regression testing for each release, rather than days if they had an automated regression test suite. As soon as a new product has reached feature stability, but not earlier, it is critical to develop an automated regression test suite. Failing to do so early on creates technical debt, which grows inexorably at each release. The trick is to develop the automated test suite while its cost is still commensurate with one round of manual testing.
So, just as in parenting a human child, the finesse lies in knowing when to evolve and bring new levels of sophistication to the maturing product.
Whether they apply to technology, methodology, tools or organization, decisions must be relevant to the product’s maturity.
2. Pick Well-Known Technology
It is easy to be tempted into utilizing the latest and greatest languages and tools available to build software. Who doesn’t want to raise eyebrows at tech conferences, and impress fellow engineers with bleeding edge jargon? However, using these new technologies may end up costing valuable time; time in which competitors using the ‘tried and true’ are pushing faster towards market-readiness.
This desire for the new and untested should be contrasted with some harsh realities: new tech is often buggy, and can be difficult to be made to do more than the basic “Hello World” demo.
It is also very important to factor in the pool of talent available for your technology stack. Hiring and on-boarding new developers quickly will make a difference in the rate at which the company grows. In particular, selecting a new, yet stable, technology will attract developers, who are typically eager to learn new technologies, and want to keep their knowledge current.
One of the startups I advised had selected Cassandra as its core database because we were building a large scale consumer messaging app (think “Twitter with voice”). Cassandra would have made a good choice once our traffic reached a million messages per day, but as we initially had to pivot a couple of times in search of a product-market fit, it made implementing these changes extremely difficult and slow. Furthermore, since we were running release 0.8 (i.e. not even 1.0) we had to fight frequent bugs. The net result was painfully slow progress, and ultimately no success.
Dealing with these bugs and inconveniences may cost the product the precious time needed to be first to market and beat competitors. Therefore, a large part of achieving Silicon Valley Speed is recognizing the limitations with the new, and embracing what may be best for your product: reliably familiar technology (see “How To Choose Your Tech Stack”).
To develop at Silicon Valley Speed, we must select technologies that allow us to hire talented developers quickly.
3. The Product Team is a Lot Broader than Software Developers
Successfully launching a product-generating meaningful revenues from it and/or high traffic-requires more than writing code. What is needed is a good understanding of the target market and end users, good user experience and interface design, and solid testing. It also requires tools that make it easy, and safe, to deploy software to the data center, as well as tools that monitor the systems in production to ensure high availability and performance. Finally, in order to increase adoption, and ultimately generate sales, we need to increase the awareness about our new products with our existing and prospective users.
As a consequence, our concept of the product team needs to include more than just developers. The product team is the collection of product managers, UX/UI designers, developers, QA and DevOps engineers, system administrators and product marketers. We need high-performing talent at each of these positions – as well as – collaboration at every level and every role. Building and coaching the product team are critical steps towards achieving Silicon Valley Speed.
For example, with the advent of cloud service providers, micro-services and containers, to name a few, software architecture and data center infrastructure have become closely intertwined. Consequently, software architects, devops engineers and system architects need to commence their collaboration in the early stages of each project, in contrast with a few years ago when release notes were the main means of communication between developers and system administrators.
Another scenario that I have seen repeated multiple times is the velocity of the Engineering team being hampered by a shortage of product managers. To the CEO, Engineering looks inefficient, but the root cause is that at the start of each sprint 2-3 days are eaten up building up complete specifications because of the shortage of product managers.
4. Methodology and Tools are As Important As Talent and Technology
Assuming that you’ve recruited a complete product team, the next step is to put into place the organization, tools, and methodologies that foster efficient collaboration throughout the product team. The members of the product team, from product manager to system administrator, each have their own way of working, their own methodologies and their own tools. To operate at Silicon Valley Speed, we need to ensure that both people and tools know how and when to talk to one another.
For example, imagine that your company just closed its A-round of funding, and adds 10 developers and QA engineers in Eastern Europe to the original team of 4 developers in San Francisco. The impact goes beyond changing the standup from being in person to Skype, it affects how every step in the process is orchestrated: requirements need to be documented rather than explained face to face, code reviews are done asynchronously, tests and deployments need to be automated, etc.
Similarly, reaching a new threshold in traffic volume or number of customers will require higher quality and predictability in the product. Developing at Silicon Valley Speed thus requires adapting tools and methodology, i.e. the way the whole product team works, to the maturity of the product and the business environment of the company.
5. Methodology is Useful – Outcomes are Paramount
A surprisingly large number of my engagements entailed teams where the Engineering team was applying Agile Software Development methodology “the right way,” but the business team did not see any improvements in productivity, quality or predictability from the methodology they used earlier.
I’ve found the common denominator in this problem to be that teams apply Agile blindly, focus on the artifacts without an appreciation for the reasons that underlie each practice, nor whether the intent of these practices are realized – i.e. Are we moving the needle? Consequently, they have no means to evaluate whether the practice is applied correctly, or if it is even needed at all.
For example, I have seen too many teams religiously stand-up at 9am every morning. Yet, a daily standup is not so critical if all five of the team members are sitting in the same room. Alternately, if we have a distributed team across different time zones, we have to adapt (e.g. post our daily updates on Slack). The goals of the standup are to ensure efficient intra-team communications , and prompt escalation of any “blockers.” This can be accomplished standing up or sitting down, at precisely 9am every morning or over Slack. However, the only thing that matters is whether the team communicates effectively.
I have also seen too many teams set two-week sprints, but fail to produce “almost shippable” code at the end of each sprint. Rather, they use every other Friday as a mere increment to the sprint counter. It’s only when code has been accepted by the product owner – and – passed QA that we can declare a sprint complete, and take on new work.
Silicon Valley Speed is reached through knowing not just the “how,” but also the “why”, so that we actually improve outcomes. We must delve deeper than rogue implementation of the Agile textbooks. Instead we must develop an in-depth understanding of their purpose, in order to tailor our processes and tools to meaningful outcomes.
Once we understand the drivers behind each precept of Agile software development, we can optimize them in order to make them relevant to our team/project.
The key to achieving high growth is to select the correct business objectives on which to focus, and-equally important-those to ignore. Similarly, developing products at Silicon Valley Speed requires the selection, understanding, and application of the right technologies, methodologies, and tools at the right time, with a degree of emphasis that is optimal for the stage of maturity of the product. Juggling these different facets may seem like a daunting task, but I have helped many companies maneuver them successfully, and those that do achieve Silicon Valley Speed, and ultimately, success.