There are endless survival challenges for newly created businesses. The degree to which a business successfully meets these challenges depends largely on the nature of the organization and the culture that evolves within it. That’s to say that while market size, technical quality, and product design are obviously crucial factors, company failures are typically rooted in some form of organizational dysfunction. To help investors recognize signs of trouble before catastrophe strikes, I started working more than a decade ago on the Bell-Mason Diagnostic, a quantitative evaluation method that includes a set of rules for examining a company and comparing it with an “ideal” organization.
Although designed specifically for people who invest capital in new ventures, the diagnostic can also be used just as effectively by those whose investments come chiefly in the form of time, energy, and imagination. In fact, anyone contemplating joining a startup—or considering whether to stay with one—can read the diagnostic and answer the questions to determine whether the company they have in mind is in reasonably good health.
There are, of course, hundreds of different ways for new ventures to fail. This article describes a few of the particularly common forms of organizational dysfunction, with reference to the Bell-Mason Diagnostic to help frame each example.
High-Tech Ventures1 offers a more comprehensive view of the Bell-Mason Diagnostic for those looking for tools to measure the health of a startup organization over time. The Venture Imperative2 describes the much more difficult challenges involved in creating new ventures from within larger organizations. Both books define key heuristics for successful ventures and then use them to describe operational patterns often indicative of impending failure.
The Bell-Mason Diagnostic assesses the health of an enterprise at four critical stages of organizational development (which, not surprisingly, are closely related to similar stages in the much more familiar product-development cycle):
These four stages correspond to key product, market, and corporate development milestones—and are measurable and predictably sequential. What’s more, for those companies that manage to maneuver successfully through these four stages, there’s a fifth stage, known as “steady state”—that happy juncture in the process where high-tech startups become stable, solidly established, sustainable, and yet still capable of continued growth.
Across the various stages, the Bell-Mason Diagnostic allows you to measure and graphically plot an organization’s performance in 12 relatively independent dimensions of activity, namely:
Startups are evaluated in each dimension according to rules of good practice distilled from experience with more than 600 companies. The results for each stage are then plotted on a 12-dimensional radar chart, as shown in figure 1.
Note that growth occurs in each dimension as the company progresses from one stage to the next, but not necessarily at the same rate. That’s because at certain stages of development, different dimensions are disproportionately significant. Still, by the time a company has reached the end of the product development stage, it needs to be pretty well-rounded.
In all cases and at all stages, the heuristics applied are specific and measurable. For example, some of the questions asked in the earliest stage include:
You would be astounded to learn how often such simple yes/no questions are answered, “No!”
Contrast this with the “gut-feel” common wisdom that has guided investor and employee decisions for as long as there’s been a high-tech industry, with reference to fabled rules of thumb such as:
The difference between relying on subjective observations like these and taking a more quantitative approach is demonstrated by the experience of Nanyang Management. Between 1995 and 1998 this venture capital firm conducted 29 systematic analyses.3 A regression analysis later showed a near-perfect correlation between actual business performance and the indicators revealed through application of the Bell-Mason Diagnostic.
More often than not, organizational problems stem from the inability of a CEO to form an effective team across all the crucial corporate functions, including: engineering, marketing, sales, support, finance, and administration. In any organization building a new product or service, conflict inevitably arises over issues such as those indicated in table 1. The collisions frequently start with product definition as marketers, who often come from engineering backgrounds, clash with the engineers responsible for actually designing and building the product. And should a significant quality problem ever arise, conflict is likely to spread across the entire organization—engulfing even the board of directors—as the damages are assessed and the underlying mistakes are rooted out and closely analyzed.
Dysfunctional Conflicts and Their Actors
|Issue that generates conflict ||Organizations involved|
|Definition of the product ||Engineering/Marketing|
|Definition of customer/market segments’ sales productivity; customer information ||Marketing/Sales|
|Product pricing ||Finance/Marketing/Sales|
|Delivery and/or support of the product ||Sales/Support/Channels|
|Resolving product or customer problems ||Engineering/Channels/Support/Sales|
|Quality ||Finance/Production/All departments|
|Managing department sizes and/or budgets ||Finance/All departments|
|Downsizing ||BOD/CEO/All departments|
Even without the impetus of an acute conflict, organizational dysfunction can develop purely on the basis of disrespect between key groups or distrust among certain department leaders. Although it’s not necessary that everyone on a team “like” each other, it is imperative that they respect one another, are able and willing to communicate with each other, and are solidly unified around a common set of business goals. Otherwise, the venture is doomed. Indeed, when intense disrespect becomes obvious at the highest levels of an organization, it can create fissures that ultimately reduce a 10+ billion-dollar company to rubble, as was evidenced in the demise of Digital Equipment Corporation.4
Organizational conflict in its own right is healthy and natural—especially with regard to the tension that seems inevitably to arise between engineering and marketing. The seed of that particular conflict rests in the fact that while the engineering team’s goal is to develop something that hasn’t existed before, the goal of marketing is to meet the immediate, present-day needs of customers while also anticipating their future growth requirements. Thus, the more unfamiliar and “new” a product from engineering proves to be, the harder that product is likely to be to market. Still, there is no reason for the resulting conflict to escalate into a company-consuming problem so long as it’s managed effectively.
Whenever products do bomb, most of the functional “misses” can be traced back to incompetent engineering or marketing, or simply to a lack of integration between the two efforts. Ultimately, however, the real responsibility for any of these problems has to be borne by the CEO and the board of directors for failing to exhibit the necessary leadership to constructively guide and manage the conflicts that naturally arise across functional areas.
With this as backdrop, then, let’s look at a number of classic failure scenarios. If any of these seem uncomfortably familiar—particularly if they appear to describe a company in which you’re currently involved—you may wish to seriously consider whether your time and/or money are being put to their best possible uses.
Although the term vaporware seems to have been with us for just about as long as the high-tech industry itself, we actually have the company depicted in figure 2 to thank for it. Suffice it to say, should you ever come across another company with a similar profile, run—don’t walk—in the opposite direction.
The founders in this case, including the CEO, all came from sales backgrounds. That helps to explain how, at a time when the power of desktop systems was such that it was barely possible to generate a single-function product, this group produced a specification calling for the combination of multiple personal productivity capabilities. Although they managed to sell that plan to a gullible group of venture capitalists, their problems started in earnest once they attempted to hire an engineering team to build the product. Given the management team’s overall inexperience in essentially every organizational function outside of sales, it’s not surprising that a strong engineering team could not be readily assembled. Then, to compound matters, while the engineers who were on board struggled (unsuccessfully) to build the product, salespeople were already out taking orders.
So as we review the company’s final scorecard, we find an organization that had a reasonable product idea, albeit one that couldn’t be implemented in its entirety. With an inexperienced CEO and a weak board of directors in charge, things started to unravel as the company found it couldn’t hire an A-team capable of building anything even vaguely resembling the specified product. Finally, the company committed the ultimate folly of staffing up with salespeople before it had a product to sell. Consequently, the company had fully burned through an ample supply of cash before it had the foundations of a product, and the management team soon learned that there were no prospects for additional investments anywhere in sight. We all know what happened next: The company crumbled and was swept up into the dustbin of history, leaving the term vaporware as its only real legacy.
Our next scenario of doom involves a story often told—a technology-focused company that repeatedly fails to define a successful product because of a lack of meaningful marketing input (see figure 3). Misguided product specifications are the inevitable result since the developers are not once forced to account for the needs and aspirations of actual users. Accordingly, they simply go ahead and build something that offers the sorts of features they themselves find appealing. The result is a product that only its developers could love. Everyone else is perfectly content to ignore it.
The problem is compounded as the company adds more salespersons in a desperate attempt to increase sales through brute force. Inevitably, the company succeeds only in accelerating its cash-burn rate. Certainly, management and the marketing group are largely to blame for this by virtue of their failure to specify design parameters according to carefully studied market requirements. But I tend to fault the engineering team for relying on obviously deficient (or perhaps even nonexistent) marketing input at the time of product definition. Ultimately, in fact, engineers are always responsible for the success or failure of the products they design!
Here’s another scenario that’s probably all too familiar. The company has just completed the difficult job of transforming a promising technology into a working product. This, of course, signals the time to vigorously expand efforts in a number of areas—market development, distribution, sales, production, and support being among the most important. In some cases, members of the board might take this as their cue to replace the founders with “management professionals” who have “done it before.”
Typically, this confronts the founders with a Faustian bargain: Either they can help the new management team prepare the company for acquisition or an initial public offering, or they can simply leave, sans stock. Most, not surprisingly, opt to stick around for the big payoff. But that doesn’t mean they’re happy. In fact, most of the core people who helped to found a company, while deeply committed to its success, are also fundamentally unwilling to yield power to newcomers.
So the new CEO who was hand-picked by the board ends up facing the unenviable task of creating a new management team made up largely of original founders reduced to diminished roles. This is a sure recipe for passive-aggressive behavior and a poisonous, sullen atmosphere. As a consequence, the new CEO is almost surely doomed right from the start. The company itself may soon sink into a morass, as senior executives work—consciously or unconsciously—to sabotage the newly arrived outsiders. It doesn’t take long for a sickness like this to spread throughout an entire company culture. Any recovery may prove extremely protracted and painful—with perhaps a succession of CEOs and a number of original founders ultimately being sacrificed before things finally get turned around.
The “brand” entrepreneur, especially in Silicon Valley, always seems able to obtain enough capital to start a new company—even when armed with only a decidedly marginal idea. Once the money is in hand, all that remains is to hire an experienced, mercenary team that’s done it all before and has what it takes to quickly get the entrepreneur back in business. From there, the game plan gets exceedingly simple: Produce a product and then, at all speed, prepare to sell the company either to a larger company or to the public at large through an initial public offering.
So what’s wrong with this picture? Only this: While revered entrepreneurs who’ve already launched three or more companies may have succeeded in making hundreds of millions of dollars for themselves and early investors, they almost certainly have never managed to create a sustainable, profitable company for shareholders. Which is to say that most of the company’s investors and virtually all of its employees are apt to get left holding the bag not long after things just start looking pretty interesting. So the note of caution I urge here is to always beware of celebrity entrepreneurs.
Startup organizations that fail are, for the most part, those that prove unable to deal with the complexity of technology and the fast pace of technological change while simultaneously growing as organizations. As technologists, our instincts usually lead us to look for design flaws or problems in underlying technologies when trying to understand the sudden collapse of a company. Although these problems can almost always be found, the real roots of the trouble usually can be traced back to basic human foibles and problematic organizational dynamics.
More often than not, the core problem proves to be any or all of the following:
All three—which, by the way, are hardly mutually exclusive and often, in fact, found to be fellow travelers—are themselves rooted in distrust. There are those company leaders, for example, who simply can’t let go of some particular responsibility largely because they have no confidence that anyone else can do the job properly. Sometimes that fear has a real basis—as in an organization where people have already amply demonstrated their incompetence. But that’s not the whole of it because dysfunction can flourish in even the most competent of organizations as a consequence of greedy, self-absorbed people who haven’t the slightest intention of sharing any power, glory, or reward with anyone at anytime.
For anyone considering taking (or holding onto) a stake in a company, it all comes down to recognizing basic weaknesses in human character and understanding how those flaws can contribute to dysfunctional organizational behavior. The ability to measure and quantify the most telling of those company behaviors is what the Bell-Mason Diagnostic is all about. And should the diagnostic serve to reveal a disturbing picture of how your organization works, the way in which you go about responding to that insight may also give you a much better sense of what you are all about. Q
1. Bell, C. G., and McNamara, J. E. High-Tech Ventures: The Guide to Entrepreneurial Success. Addison-Wesley, Reading: MA, 1991.
2. Mason, H., and Rohner, T. The Venture Imperative: A New Model for Corporate Innovation. Harvard Business School Press, Boston: MA, 2002, 301–307.
3. Nanyang Ventures: see http://www.nanyang.com.au/.
4. Schein, E. H. DEC Is Dead, Long Live DEC: The Lasting Legacy of Digital Equipment Corporation. Berrett-Koehler, San Francisco: CA, 2003.
GORDON BELL is a senior researcher at Microsoft’s Media Presence Research Group, a component of the company’s Bay Area Research Center (BARC). He has taught computer science and electrical engineering at Carnegie-Mellon University and was the first assistant director of the National Science Foundation’s Computing Directorate. Bell serves on several boards, is involved with many professional organizations, and has received the IEEE Von Neumann Medal and the National Medal of Technology.
Originally published in Queue vol. 1, no. 9—
see this item in the ACM Digital Library
Mark Kobayashi-Hillary - A Passage to India
Most American IT employees take a dim view of offshore outsourcing. It's considered unpatriotic and it drains valuable intellectual capital and jobs from the United States to destinations such as India or China. Online discussion forums on sites such as isyourjobgoingoffshore.com are headlined with titles such as "How will you cope?" and "Is your career in danger?" A cover story in BusinessWeek magazine a couple of years ago summed up the angst most people suffer when faced with offshoring: "Is your job next?"
Adam Kolawa - Outsourcing: Devising a Game Plan
Your CIO just summoned you to duty by handing off the decision-making power about whether to outsource next years big development project to rewrite the internal billing system. That's quite a daunting task! How can you possibly begin to decide if outsourcing is the right option for your company? There are a few strategies that you can follow to help you avoid the pitfalls of outsourcing and make informed decisions. Outsourcing is not exclusively a technical issue, but it is a decision that architects or development managers are often best qualified to make because they are in the best position to know what technologies make sense to keep in-house.
Judith S. Olson, Gary M. Olson - Culture Surprises in Remote Software Development Teams
Technology has made it possible for organizations to construct teams of people who are not in the same location, adopting what one company calls "virtual collocation." Worldwide groups of software developers, financial analysts, automobile designers, consultants, pricing analysts, and researchers are examples of teams that work together from disparate locations, using a variety of collaboration technologies that allow communication across space and time.
Li-Te Cheng, Cleidson R.B. de Souza, Susanne Hupfer, John Patterson, Steven Ross - Building Collaboration into IDEs
Software development is rarely a solo coding effort. More often, it is a collaborative process, with teams of developers working together to design solutions and produce quality code. The members of these close-knit teams often look at one another's code, collectively make plans about how to proceed, and even fix each other's bugs when necessary. Teamwork does not stop there, however. An extended team may include project managers, testers, architects, designers, writers, and other specialists, as well as other programming teams.