Case Study II  

Startup B was founded by two professors of Computer Science to develop an innovative network monitoring tool. They assembled a team and started working on a first version. They soon discovered a thirst in the market for VoIP pre-deployment evaluation tools. In advance of an upcoming conference a prototype was built and started selling. As soon as there were a handful of paying customers, support calls, feature requests, and bugs started flowing from the field.

The team worked hard developing a base product while simultaneously preparing customizations for customers. There was a constant influx of demand, and management decided to grow the development team. The bigger team continued catering for the customers and pressure built up to deliver. Soon a lot of features had been developed around the initial prototype. There was hardly time to plan a more robust software development process. Soon the company landed a million dollar contract to provide a monitoring system for a large ISP in the United States. Lacking a working installer, the engineering team had to fly in one of its members to install the software from the customer’s private network. This engineer had to consider and decide over thirty configuration parameters and tweak several files to get the product up and running. The customer was surprised by the complexity of this new product and thought they got good value for their money.

In the mean time, the VCs expressed confidence in the company by investing a second round. But the product was growing out of control; lacking a serious QA procedure, developers would usually prefer to write new features from scratch instead of modifying and leveraging existing modules, out of fear of breaking something. Some team members started to feel unease about the quality of their work and started looking for alternatives.

In the meantime, the big ISP started noticing that the product would give false alarms and incorrect diagnostic messages, which they found quite annoying. The engineering team could not easily set up the customer’s environment, and lacking an automated build and install procedure they found it difficult to consistently reproduce the conditions reported by the customer. After some weeks, they finally flew an engineer with a patch, to the customer’s satisfaction. However, some weeks later, different problems started to appear at the customer’s site. The customer noticed that the product’s complexity was not manageable even by the team that developed it.

At the same time, other players started to appear in the market. They were smaller, lighter and moved faster. The company’s engineers could not outpace the competitors and they soon lost the market lead.

With revenues down, and unable to leverage the large contract to get more leads in the industry, the company received yet another round of funding. Some in the R&D team started to voice suggestions to re-engineer, but management wanted to leverage the huge investment in technology and deemed a change too risky. The engineering team was still too big to move fast enough and most revenues were from old customers renewing their support contracts. Only when forced to by the financial situation, management decided to evaluate how to be smaller and smarter. But it was too late, and a year later the company closed its doors.

The market presented a lot of opportunities to the company. But the team was always too busy solving problems and responding. It could not find the time or resources to act proactively and build a decent software development process. Management tried to solve the problem by throwing money at it and built a large, slow team that failed to take advantage of the existing opportunities, let alone create new ones.