At my first startup company, Silicon Spice, we were extremely disciplined in how we structured internal communications, identified and followed technology standards and incorporated automatic testing into all our technology development efforts. The company-wide discipline we established allowed for an unprecedented pace of product innovation in the rapidly evolving communications market of the late 90’s. Peaking at only 120 employees, we constructed a complex set of technology targeting telco equipment vendors including reference voice switching boxes, a 2.5 Watt 21-core DSP processor, companion ASIC devices, a vector compiler, a real-time OS, a fully-featured set of voice processing software and a complete suite of development tools for our platform. A few people in key roles were able to spot opportunities that spanned numerous product sub-teams and we were able to quickly implement coordinated design changes across our home-grown technology stack.
A lead engineer from Texas Instruments, our primary competitor, once commented to me that they couldn’t believe that we had build our product in only 3-4 years with 100 people; I didn’t have the heart to tell him the product they were evaluating for acquisition was built by an average of 50 people over 16 months! We seized 70% of the carrier-class market from them in the 18 months following our acquisition.
Some years later I served as an advisor to a company with some novel and creative ideas that gave them a significant market lead in a large and growing services market. However, unresolved differences of opinion on engineering strategy and tools led to a fractured technology base and culture that significantly impeded execution efficiency. The market caught up to them in less than a year and erased most of their early advantage, leaving them one player among many. Startups in crowded spaces that can’t execute as fast as the best of their competitors will eventually lose any advantage provided by a novel technology. In highly competitive markets, execution is the advantage. You have to be able to adopt the innovations of others as well as continually generate your own to compete.
You might ask whether patents protect you from this effect? I think not. There are too many ways to solve a given problem in most of the major technology markets today. In the software, internet and hardware worlds I’m familiar with, patents are primarily useful for negotiating a higher valuation from an acquirer that can take proper advantage of them. Of course no one will care to evaluate you (or value you) for an acquisition if you’ve been out-competed in the marketplace.
The key take away lesson for me is that innovation happens best when your organization is acting within a structured system of rules that standardizes common elements and actions and creates a shared language for the domain; the result is dramatically reduced friction in the communication and dissemination of new ideas within the organization that are composed from those common elements.
Aside on Software Methodology
Perhaps this “discipline effect” explains Allister Cockburn’s comments on the lack intrinsic advantage of any software methodology over another — as measured by the lack of meaningful correlation of successful software projects and methodology over 30 years. Successful software engineering organizations are those that agree on a methodology, are disciplined enough to stick to it, and have a culture that promotes the generation and dissemination of ideas within it.
Of course, a disciplined organization with good people can do great things with a poor methodology, while the best methodology can’t save a dysfunctional culture. Ideally, as argued by Graham in the essay I referenced above, you gain a multiplicitive advantage when you combine an appropriately-scaled, agile methodology with a disciplined, innovation-minded culture.