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 remainder of the series will be
posted on the IEEE Spectrum Careers site at http://www.spectrum.ieee.org/careers.
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.