The dark side of post startup innovation

Todd at the Napera blog has two great articles here and here about how most of the innovation in network security comes from startups.

Breakthrough products like security appliances and virtualization were not pioneered by established industry behemoths, but originated with smaller companies willing to pioneer new product ideas and disrupt the status quo.

Startups are clearly much more agile than “established industry behemoths” and most of their mid sized brethren. The passion, drive and commitment of the small team offsets the capital, expertise and experience of the larger, older outfits.

startups spend an order of magnitude more time talking to customers and thinking about the challenges customers face. Ideally, interacting with and thinking about customers should happen at every level of a company. To add to that focus, a product team in a startup has a lot more autonomy in making product decisions.

Having worked across the entire spectrum in my career as a software engineer – from a small “mom and pop” DoD contractor (literally: Mom was the Controller and Pop was the CTO) all the way to a Fortune 50 computer manufacturer (truly one of those “established industry behemoths”) – I have definitely seen this in action. In a small startup everyone is intimately familiar with the customers, whereas large corporations have to make concerted efforts to allow a design engineer to even have marginal contact with a customer – and that’s usually second hand through either a sales or marketing initiative.

So being a startup is swell and you can innovate the pants off the big boys. The force is strong with startups. But there is a dark side. You didn’t really expect anything else now did you?

The conundrum which is faced by all startups (who don’t get snatched up immediately post initial product release by one of those big fish) is how to get new customers and still keep existing customers happy by providing a stable value added upgrade path. It’s really hard to innovate out of this one. But you have to in order to make that next step from being a startup to being an established concern that is in it for the long haul. From some things I’ve witnessed on the engineering side where this innovation actually happens, I present this cautionary tale.

Startup creates first product – brilliant idea, incredibly fast time to market. The chief engineer is now the CTO, but spends a fair amount of time addressing customer concerns (i.e. putting out fires). As a result the CTO is well loved and well rewarded by customers and executive staff alike. So now it’s time for the next big release of the product. The CTO has very precise ideas about what new features are important and what failings must be addressed. In fact the CTO knows that the largest customer is poised for a huge purchase when that killer feature is added. Unfortunately the CTO is way too busy and valuable an asset to the business to focus on the mundane tasks of development any longer so developers are hired to get the next version and next product out to the breathlessly waiting customers and potential customers.

So lets pause here and take stock of the new developers’ situation. They have to update an existing code base which has been field patched (remember those firefighting drills) with a technical lead (our CTO) who doesn’t have time to spend mentoring anyone. And they have to do it quickly. The CEO recalls that the first release came after 6 months and the following 2 releases came on 3 month cycles. Now granted the CEO knows that the now-CTO is a bona fide savant, a true code ninja, but surely these new mere mortal programmers can get the next rev out in 6 months. 9 months tops. Besides they’ve promised customers and there are some big deals riding on this next release. So the show must go on.

Fast forward 9 months and the vaunted next release is dangerously close to slipping the release date. The executive staff is not too worried as they recall the 160 hour weeks that the now-CTO put in to get the product out. So the pep-talks begin to motivate the new programmers to “take one for the team” and get this release done on time no matter what.

We’ll stop this tale here. The aforementioned allegorical startup can still make a happy ending, but not without recognizing the realities of the dark side.

1. Brilliant innovative engineers are rare. The dark side of being brilliant is that they rarely value mundane necessities like documentation. They know the code inside and out, so from their point of view it’s self-documenting.
2. Competent engineers are not so rare. They are also not so expensive. Or fast. They need mundane stuff like documentation to accomplish their job.
3. The ramp up time it takes to come up to speed on a new product such that you can enhance and maintain it always takes at least twice as many engineering hours as it took to develop it in the first place. Don’t believe me? No problem, you can find out on your own.
4. All engineers come to the realization (usually sooner rather than later) that firefighters get rewarded. So they look for fires to put out rather than doing the critical but boring and largely unnoticed jobs like configuration management or refactoring for maintainability.
5. Executive management is always willing to oblige firefighters. They like it when the customer’s problem is solved quickly. That’s in the job description.
6. The original founding members of the startup usually have an equity position in the company. So they know that at least the potential is there to be very well rewarded if the company is successful. So they are willing to work insane hours and make huge sacrifices for the company because of the potential rewards. Later members are employees or contractors with no real equity stake in the company. When they work insane hours and make huge sacrifices they get to keep their jobs. And have a party. Until they burn out.
7. Customers who have your product expect to get new features before they are willing to pony up for the next version. They also expect a smooth and painless upgrade path – even when they decide to skip 3 or 4 releases. This is probably the most difficult part of software development. And one that most of us don’t consider until it steps up to brazenly bite our backsides.
8. Customers really want the features they want. For them. Not for the entire customer base or potential markets. For them. And they are happy to drive your product strategy – where they want it to go.

Can a startup successfully address these dark side issues? Absolutely. To be successful you have to. Will you fall victim to most of these at least once? Of course. I’ve never heard of any company that survived the transition to post-startup unscathed. But the one edge that a startup can never afford to relinquish is that customer focus that Todd describes in his articles.

May the force be with you.