Chapter 2: Supporting Development

The Art of ‘Ware [version 2.0] by Bruce F. Webster

[Copyright 1995, 2008 by Bruce F. Webster. All rights reserved. Last updated: 04/30/08]

[back to Chapter 1] [up to Top] [on to Chapter 3]

A parable in the Bible talks about counting the cost of something before you start to build. That truth is ancient and obvious, yet I’ve seen too many companies ignore it. Once you know what you want to do, you have to figure out how to do it — and particularly how much it’s going to cost. Resources required include people, money, time, mindshare, technology, and information. They are all expended as development proceeds, and not all are renewable.

Sun Tzu talks in his second chapter about the resource issues of mobilizing troops, and waging war. What’s important, he says, is to succeed as soon as possible; the longer things drag out, the worse the results, regardless of how much “better” the product. If you don’t believe me just ask anyone (else) who has shipped a product a year late.

Product development requires a core development team, support, and quality engineers, and the necessary resources from production and marketing.

It is still possible for an outstanding concept, technology, or product to be designed and developed and developed by a few people working in a garage or cheap office; just look at Google. What is almost impossible is for those same few people to bring the product to market on their own. Customer expectations of quality — in marketing, packaging, documentation, customer support, and, or course, the product itself — are at a very high level, and there are a lot of fiercely competitive companies that can provide that level of quality.

The cost of supporting these employees for 18-24 months, including salary, training, travel, marketing, and money spent on equipment, office space, utilities, and supplies, will amount to roughly $10,000 per month per person. Such is the price of new product development.

This figure is less in some places with lower wages and cost of living (say, Utah or Russia). And, of course, things can be done a bit cheaper in a start-up, particularly if the developers are fresh out of college. But that $10,000/month figure — about $120,000 per year– is a good, conservative rule of thumb, especially for business planning. The general rule is to take the annual salary of that employee and double it. IT salaries, after booming in the late 1990s, were hard hit by the tech collapse of the early 2000s. However, they are on the rise again. Plus, not all your salaries are going to be IT-related; there will be non-IT employees as well.

When you release a product, if success is slow in coming, you’ll face diminishing returns on product development and exhaustion among your engineers and marketers.

It is enough of a challenge to sustain energy and excitement through the process of actually getting the product out the door. If returns are slow and small, people can get discouraged and start looking for the door themselves.

When your developers are burned out, your technology aging, your resources diminished, and your advantages gone, then others will take advantage of your weaknesses and cut into your market. Even expensive consultants and new CEOs won’t be able to turn things around.

Few technology companies manage to keep themselves in a lead position for more than five years. At that point, they usually become victims of their own success. The visionaries who founded the company are either gone or given emeritus status. Market focus is on adding yet more features to old, bloated products; no one is willing to risk coming up with new products and technologies that might cannibalize existing ones. And so they start on the long (or, sometimes, not so long) glide downwards, shedding products and people, sometimes merging with other firms on the downward slope. Some companies manage to level off, or at least to slow the rate of descent, but they rarely regain their former status; their place in the market has been filled by other companies with newer products and technologies.

There have been product releases that were poorly done but quickly successful, but there have been few that were well executed and that took a long time to succeed. No company has benefited from a prolonged competition.

There are three dangers in a prolonged competition. First, it consumes resources that could be applied to new markets and products. Second, it narrows your profit margin, further limiting resources that could be applied elsewhere. Third, it tends to lock you in on your current products, blocking development of new ones and leaving you vulnerable to new competitors.

Note, though, that success is relative. In established markets, there are typically two to four major players who between them own 90% of the market. In such a case, gaining even a few percentage points of market share is cause for celebration; witness the fierce battles between Pepsi and Coca-Cola for mere fractions of a point of market share.

Those who don’t understand all the issues and risks in product development and release cannot understand the best techniques to be used.

Many books have been written about these issues and risks; the single best summary remains The Mythical Man-Month, written by Frederick P. Brooks. Written over 30 years ago and updated about 10 years ago, it is dead-on its explanations about why projects fail or, at least, are late and over budget. There is more than enough blame to go around: engineers, project managers, marketing folks, and upper-level executives. It should be mandatory reading for every single employee in a technology venture, as well as any associated investors and directors.

Those who handle product development skillfully don’t build engineering teams twice, nor raise capital three times.

Building product development teams twice means having to replace the original engineers with new ones in the order to complete the product. There can be any number of reasons for having to do this: the engineers get burned out; the engineers get disgusted with upper management and leave; the engineers lose faith in the company and its directions, particularly if they view the product as being “hijacked” and taken in a different direction by latecomers to the company, or the engineers are replaced and/or fired, either because of insubordination or because they weren’t the right ones for the job in the first place.

Raising capital three times before product release indicates that development and launch have taken too long. (Believe me, I know.) The first round is usually essential to get the company off the ground. The second round may be necessary because of changes in product direction or the all-too-common delays in production development. But you’re in trouble if you raise a third round of capital for anything but product launch, and possibly even then. Not only does that mean that you’re late in shipping, it also means that you’re surrendering equity — thus reducing equity incentives for existing employees — and that you do not have sufficient cash reserves to keep the company going once the product does finally ship.

Focus on creating your own development resources, and recruit from your competition. This way, you can be sufficient in both tools and personnel.

Invest in development resources, that is, the tools needed to actually create the product. All the money you can think of possibly spending on those resources probably won’t equal what you’ll lose each and every month if your product is late. Likewise, be willing to devote people and resources to creating custom in-house development resources. It’s easy to chose not to do this, because you can often “get by” without such tools and you may be concerned about the return on investment. But the right tools can make significant difference in product quality and time to completion.

Some of the best people to do your product development are at other companies and are probably at your competitors. Recruit aggressively and hire the best, strengthening yourself and weakening your competition.

When a company is drained by competition, it is because product development and marketing have taken too long. Prolonged development cripples the company.

Developers can typically sustain a high level of energy for 18 to 36 months, depending on how hard they’re being pressed. After that, they start looking around for something new to work on. A project that takes too long getting out the door runs the danger of never shipping, because key developers keep leaving to work on something else, either within the company or outside of it.

There are other significant internal and external problems caused by prolonged development. People within the company begin to lose heart, bicker, and find fault with each other. Customers question the company’s ability to deliver products in a timely fashion. Competitors use your delays against you to win customers and sow doubt about you.

Even allies begin to doubt and may seek to distance themselves from you. During the very long year between our original ship date at Pages Software Inc. and and the date when our product (Pages by Pages) actually went out the door, someone at NeXT swore we’d never ship and said he’d eat a can of worms if we ever did. We did ship, on March 7th, 1994. We never heard if this person carried out his promise; we certainly kept our end of the bargain.

In key areas of technology development, talent is scarce and salaries are high, limiting resources for other employees.

As new technologies become hot markets, the number of skilled developers is small, and they command high salaries. For example, in the software industry this has been true at various times for 8086 assembly, Windows, C++, OLE 2.0, object-oriented development, Java, .NET, Python, and subsequent technologies. Each area fills in with time as sustained demand and high salaries draw more engineers into it. But, curiously enough, the absolute number of excellent developers in a given area of technology remains pretty much the same.

When I was teaching computer science at Brigham Young University in 1985-87, the number of students enrolled as computer science majors has increased dramatically — by a factor of five or so — from when I had been a student there a decade earlier. One of the professors, who had been around since the early 70′s, observed to me that the number of really good students in the department was still pretty much the same; the five-fold growth of enrollment hadn’t brought a five fold, or even a two-fold, increase in excellent CS majors. Why? Because those students with interest, aptitude, and native talent has been signing up all along; the surge in enrollment had come from students who saw computers as a way to get a great paying job, much as my friends during my undergraduate days had signed up for pre-law or pre-med.

When a new area of technology opens up, it quickly draws to it those developers with the interest, talents and desire to become really good in it. More excellent developers do come along with time, but as they do, some of the current ones start moving on to new areas, so the absolute number stays more or less constant.

Because of this, I’d like to propose a minor addition to the vast assortment of laws and rules governing technology and engineering:

• Webster’s Constant: the number of excellent developers in a new area of technology quickly reaches a constant value, which is sustained through the period during which the technology is vital.

This may seem a bit silly or fatuous, but it’s actually critical to understand if you need to build a development team that will be working with key technologies. It’s going to be tough finding really good people, and you’ll find yourself running into the same names over and over again. The trick is getting them to come to work for you.

When funds are exhausted, then money is raised under pressure. Control is lost and equity surrendered to supply the needed resources.

One of life’s great ironies is that the worst time to raise money is when you really need it, because that’s when you agree to the most unfavorable terms. The logical conclusion, then, is to start working raising money well before you need it. If you end up not needing it, so be it; but if you do, you will have done the work in advance. That’s also important, because it takes time to raise money.

Try to gain resources from the competition. Each dollar gained from or spent by the competition is worth two dollars raised and spent by yourself.

You can leverage off your competition by learning from their market research, analyzing their plans and products, and buying their technology. See Chapter 13 (“Gathering Intelligence”) for more details and ideas.

Reward employees who recruit from competitors. Merge those recruits with your own and win their loyalty. This is called weakening the competition while increasing your own strength.

If your developers had wanted to work long hours just for lots of money, they would have become lawyers. They do it for bragging rights — for the right to say, “Yeah, I helped create that product” — and for a chance to change the industry and maybe the world. It may be hubris, but then again, the world really has changed because of products created by technology developers over the last fifty years — and the most dramatic changes are yet to come.

Employees create successful products because they desire reward. Therefore, reward them based on success and profits.

The previous maxim notwithstanding, developers do want some significant financial reward. Most developers dream of making enough money to go off and do what they really want to do, which is often to start their own company or to do something unrelated to the project just completed. Because of that, they are very keen on ideas such as stock options and profit sharing.

The important thing in competing is succeeding, not enduring.

Many companies have managed to endure a long time, and even provide a comfortable (of not always secure) living for those employed there. But once it becomes apparent that a company is only enduring, not succeeding, all the good people will leave, and it will be nearly impossible to turn the company around.

Many firms want a world-class development team, few are willing to make the effort and allocate the resources to create one. On the other hand, it’s easy to spend a lot of money without achieving the desired results. There is an art to doing it, and you’ll undoubtedly make mistakes along the way. Hey, if it were easy, everyone would do it.
[back to Chapter 1] [up to Top] [on to Chapter 3]

[Copyright 1995, 2008 by Bruce F. Webster. All rights reserved.]

Be Sociable, Share!

•