What Does Legal Sea Foods Have to Do With EDA?

When I drive down to Silicon Valley I usually listen to podcasts rather than just listen to the radio. One that I especially like is Russ Robert’s EconTalk, which has an hour-long episode every Monday morning on a wide range of different aspects of Economics. Normally he interviews an economist. He has also interviewed the manager of a car dealership, and other people only tangentially connected to economics. This week it was Roger Berkowitz, the CEO of Legal Sea Foods. If you have been to Boston, even just the airport, you may well have eaten their clam chowder, but they actually have 34 fish restaurants on the East coast. They started just as a wholesale fish market, then went retail too, then a restaurant and gradually grew until they now have the portfolio of different seafood restaurants that they have today.

During the podcast at one point Russ asked Roger what was the difference between running a handful of restaurants versus 34. And how different it would be to run 68. They didn’t spend a lot of time discussing it but obviously there is a huge difference in scale from operating a fish wholesaler with a restaurant next door, to operating a fish operation in Boston that handles all the fish for three dozen restaurants, the furthest afield of which is in Atlanta.

That got me thinking about support in the EDA industry. Customer support in a successful EDA startup company goes through three phases, each of which actually provides poorer support than the previous phase (as seen by the long-term customer who has been there since the beginning) but which is at least scalable to the number of new customers. I think it is obvious that every designer at a Synopsys customer who has a problem with Design Compiler can’t simply call a developer directly, even though that might provide the answer the fastest.

There is actually a zeroth phase, which is when a startup company doesn’t have any customers. As a result, it doesn’t need to provide any support. It is really important for engineering management to realize that this is actually happening. Any startup engineering organization that hasn’t been through it before is completely unaware of what is going to hit them once the immature product gets into the hands of the first real customers who attempt to do some real work with it. They don’t realize that new development is about to grind to a complete halt for an extended period. “God built the world in six days and could rest on the seventh because he had no installed base.”

The first phase of customer support is to do it out of engineering. The bugs being discovered will often be so fundamental that it is hard for the customer to continue to test the product until they are fixed, so they must be fixed fast and new releases got to the customer every day or two at most. By fundamental I mean that the customer library data cannot be read, or the coding style is different from anything seen during development and brings the database to its knees. Adding other people between the customer engineer and the development engineer just reduces the speed of the cycle of finding a problem and fixing it, which means that it reduces the rate at which the product matures.

Eventually the product is mature enough for sales to start to ramp up the number of customers. Mature both in the sense that sales have a chance of selling it and the company has a chance of supporting it. It is no longer possible to support customers directly out of engineering. Best case, no engineering other than customer support would get done. Worst case, there wouldn’t even be enough bandwidth in engineering to do all the support. Engineering needs to focus on its part of the problem, fixing bugs in the code, and somebody else needs to handle creating test cases, seeing if bugs are fixed, getting releases to the customer and so on. That is the job of the application engineers.

During this second phase, a customer’s primary support contact is the application engineer who they work with anyway on a regular basis. But as the company scales further, each application engineer ends up covering too many customers to do anything other than support them. Since their primary function is pre-sales, to help sales close new business, this is a problem. So the third phase of customer support is to add a hotline.

The hotline staff are typically not tool users, they are more akin to 911 dispatchers. Customers hate them since they are not as knowledgeable as they are themselves. Their job is to manage the support process, ensure that the problem is recorded, ensure that it eventually gets fixed, and that the fix gets back to the customer and so on. It is not to fix anything except the most trivial of problems themselves.

At each phase of support, the quality (and knowledge) of the engineer directly interfacing to the customer goes down but the bandwidth of available support increases. Engineering can only directly support a handful of customers themselves. Each AE can only directly support a handful of customers but more AEs can easily be added as sales increase. A hotline can scale to support a huge number of customers 24 hours per day, and it is easy to add more hotline engineers.

Econtalk has an episode every week going back to 2006 including Milton Friedman, Ronald Coase when he was already over 100 (he died recently) and many other famous, and not-so-famous, names. The website is here(or you can download from iTunes too). The Legal Seafood episode is here.