Here Be Dragons

Rule 1 in managing a technology start-up: beware the easy money

Illustration: Brad Yeo

Editor's Note: This is the first installment in Frans M. Coetzee's series "Here Be Dragons: Managing a Tech Start-Up," which discusses the perils and pitfalls of starting up your own tech company.

The day has dawned on your revolutionary idea. You and your partners are eager to start a company to bring your brainchild to market. If you are the chief executive officer, you will ruthlessly exploit the elephantine maneuvers of the competition with your hawklike perception, securely backed by your technical SWAT team. If you are the technological force, you will have the dream job of chief technology officer, directing development strategy, solving choice technical problems, and obliterating bureaucratic stupidities while your handpicked partners address the business side.

There are compensations to being a start-up executive--but the perks mentioned above are not among them. Instead, you'll find yourself rushing around at breakneck speed dealing with crises, while your staff works on the cool strategies and problems. As a CEO, you'll see every problem that cannot be solved, no matter how trivial, ultimately landing on your desk. As a CTO, you will be the organization's consummate middleman, attempting to trap zephyrs of ideas from both the business and technical sides and then returning structured instructions, only to see them promptly mishandled.

In this series, I hope to highlight the basic problems in starting a tech company, in particular those that set the business and technical sides at each other's throats. From my own experience as CTO of two start-ups, I know that the standard entrepreneurial how-to books, even those purportedly addressing technical ventures, focus mainly on the business side and fail to address the technical side in more than a cursory way. So in this series, I'll focus on the technical point of view, looking at how to work with venture capitalists, and how to understand the relationship between the CEO and CTO, as well as how to staff your company, do product planning, and avoid common cultural pitfalls.

First, let's take a look at the driving engine of any start-up: money. More grief results from inadequate technical planning before the initial financing is secured than from any other factor. The common mistake is to accept money based solely on a financial business plan, without a detailed technical development plan. Most business plans concentrate on potential customers, pricing models, and marketing projections, with technical development dealt with in a few paragraphs and budget line items. A true development plan, by contrast, fully describes the functionality of different product versions, as well as resources, risks, and timelines.

Venture capitalists won't push you to write a technical development plan--they have neither the time nor staff to vet it in depth, and they prefer to spread their risk by pushing for more stock up front and by penalizing nonperformance later on. An accurate development plan, in other words, protects you, not the VCs.

Ensuring adequate technical preparation almost always means applying the brakes to the business partners. You may fear that the competition will get a jump on you, but if you move precipitously at this point, you will almost certainly sign away whatever wealth your company may eventually accumulate. More important, you'll consign yourself to the executive hell of having to deliver against a business plan without adequate resources or time, and you'll eventually carry the blame for the company's demise.

VCs are not into risk acceptance; they are into risk avoidance

VCs are not into risk acceptance; they are into risk avoidance. The less planning you do, the more risk the VCs can attribute to your venture, and the greater the stake you'll have to give them to get their cash. From here, problems only escalate, as the first funding deal you strike will determine the amount and kind of funding you'll attract in future rounds. VCs tag companies by capitalization class: once you have raised money in US $1 million chunks, your chances of getting a $10 million chunk later shrivel. Know what you need before you start, and make sure you get it--you seldom raise too much money.

Taking money puts a value on your company. Taking money carelessly may deliver you a tax nightmare of overvalued stock and unaffordable options--if not for you, then for the executives and key employees you later hire. Always keep foremost in your mind that no money comes without strings attached. The VCs may impose conditions to show specific technical development results, thereby limiting your flexibility. They may also earmark funds for a poor-fitting corporate structure. They may, for instance, force you to hire sales staff at too early a stage, before you have any product to sell.

In short, the wrong first funding can destroy your company. The only way to avoid this pitfall is to do careful planning with your own independent advisors and lawyers; do not use the VCs' lawyers, even if this is offered as a favor.

The other reason to push technical planning at the beginning is that once operations start, you will have little time to deal with it. Paradoxically, in start-ups the most capable technical person in the company--ideally, the CTO--will not be able to focus extensively on the technical work. Why? Because the company's technical and strategic vision exists only in the founders' heads, and the CTO's primary occupation will be to transform this vision into instructions for the business and technical sides, rather than to execute it. As CTO, you will find yourself in interminable meetings with sales staff, explaining the latest product release, and you'll spend many late nights translating new market research into concrete specs for the development staff to execute.

The best way to protect your venture is to plan in detail at least 80 percent of your core technology before you seek funding or expand the business side. If possible, construct a prototype. Identify and line up technical and business partners. If you need resources you can't afford, such as factory facilities, at least fully plan how they will be utilized. Document everything. If you don't, unless you are extremely lucky, you will lose control of the core technical and strategic direction as the company accelerates.

Sure, this approach is hard, especially when a VC offers you money supposedly so you can devote yourself full time to strategic thinking and product development. But remember that most prototypes and nearly all designs can be developed with (lots of) sweat equity from a small group of individuals and a post office box. The fewer people involved, the better; if you can't find or motivate this core group, you should think twice about your ability to attract the creative minds you'll need later to build your company.

Beware the illusion that life improves after the first few months and that once you hire staff, you will return to technical and strategic work. For a start-up executive, diversions both small and large will persist. Although the CEO may no longer have to clean bathrooms before prospective job applicants arrive, he or she will still have to rush off at a moment's notice to catch a red-eye flight to pacify an angry customer. The CTO never seems to escape the curse of writing user documentation the night before a product ships.

As the company grows, the scope of your activities will only expand. My "eureka" moment came a year and a half after I'd helped found a company and we were going through a complicated merger and funding round. After two months of running around in circles, no one had succeeded in accurately calculating the terms of the deal--not our investment banker or the accountants, not the VCs or the two New York City law firms representing us. In the end, the calculation came from the only person capable of solving a quadratic equation: me, the dumbfounded CTO. I vividly remember my last question after presenting the calculation at a meeting: "Is anyone going to check this?" The answer was, of course, no.

Advertisement
Advertisement