It takes more than technical skill to consult in the embedded market
Scott Rosenthal
February, 1998
One thing I've found over the years is that if you design embedded systems for your
boss, there's a good chance you might also do it evenings and weekends for a Schedule C
business. (For those not familiar with the term, Schedule C attaches to the Form 1040 to
pay taxes on a sole proprietorship.) Additionally, many embedded designers itch to chuck
their current job and start a business designing systems for others. Instead of focusing
on all the money you think you're going to make, though, let's look at some of the
realities. What does it take to really do it? What are the pitfalls? What are the rewards?
I've been in the trenches developing embedded systems for the past 17 yrs. Over that
time, I've made many mistakes, ignored great advice from advisors because I thought I knew
better and designed some really awful things. However, I've also helped companies create
wealth through product sales, provided employment for hundreds of people (including those
at my own company) and, proudly, I can point to some real improvements in this world
because of my work. In this column, I will summarize what I've found that works and
doesn't work in design consulting.
A failed first start
Back in 1980, with three processors, a few hundred thousand lines of assembly code and
about a dozen products on the market under my belt, I thought I knew everything about
embedded systems. A friend with even more experience and I decided to make this expertise
available to the world. We rented an old warehouse, built the office walls and opened for
business-but nobody came. We starved. It took five months to get our first contract and
ten months to get our first paycheck. After two years of losing money, we shut the place
down.
Looking back, the lesson is obvious: it takes more than good technical skill to create
a business. It involves things engineers typically rebel against-marketing, sales and the
customer. So, if the world of consulting or growing a design business appeals to you, read
on.
The three ingredients
So, you've decided to go off and consult. The technical side is a given. On the
business end, you've studied guerrilla marketing techniques and your spouse will do the
books with Quicken, leaving you free to do what you do best: design. Guess what-you'll
probably fail miserably. Three main ingredients, ranked in order of importance, offer the
key to a successful consulting career in the embedded field: product, customer and you. If
you lose sight of these three, you'll fail.
Ultimately, all anybody really cares about is the first ingredient-the product. It must
sell. If it does and is profitable, your customer gets money to pay you to develop more
products. If it doesn't sell, you'll need to find another customer. It's that simple.
Stepping back from the engineer's mindset, remember that any one of the following never
is the product itself:
- An embedded system
- Carefully crafted code
- FPGA design
- PC-board layout
- Patented software algorithm
- Communications scheme
- Microcontroller/computer/processor
The trade press typically ignores this list. How many times have we seen ads or feature
articles describing a new FPGA, microprocessor or ASIC that touts that it's all you'll
need to design a product? Or that it'll only cost X dollars to purchase this new gadget,
giving the false impression that you can build an entire product for this amount.
Besides considering an entire product rather than just a piece of it, when contracting
to design an embedded system you must throw all those design prejudices out the window.
Just because you've always done it a certain way doesn't mean that it's right for the
current project. And before starting to design the system, be aware of some less technical
items about the final product. If the customer isn't willing to share this information,
move on to another one. Why hitch a ride on a sinking ship?
Consider the following information before designing anything:
- How many units a year does the customer expect to sell?
- For how many years does the customer plan to sell the product?
- What's the budgeted production cost for the product's embedded portion?
- What are the service and field-service requirements?
- Who is the intended user?
- What is his educational background?
- What's the skill level of the people manufacturing the product?
- Must the system meet any regulatory requirements?
As you can see, this list focuses on the product and not on the client or you.
Client variety
On to the second ingredient, the customer, some are great, while others are simply
ordinary. Just as you must do a great job at your assigned tasks, a great customer knows
his role in the development process. He understands that he's hired you because you're the
expert, while an ordinary customer looks at you as a necessary evil, something to be
micromanaged, nothing but a technician to carry out his whims. Obviously these viewpoints
are extreme, but anyone who's done consulting can probably relate to them.
What works best is when a customer comes to me with the what, that is, what the product
must do, and not how to carry out my work. A long time ago I worked in a gas station where
we also repaired cars (and gas was 35¢ a gallon). For repair work, we made more money off
the man who told us how to fix the car (wrong 90% of the time) compared to the woman who
just described the problem. The same thing applies to embedded design. I can think of only
a few reasons why a customer looks for an outside person or group to help with an embedded
system: either he's overloaded with other work or hasn't yet developed the technology
in-house.
Notice that your skill set isn't on the list? A great customer spells out the issues
and the constraints, then he steps back so that you can develop the how for solving the
problem. Obviously, your solution must meet the needs of the product and its end user.
With that aspect in mind, you're able to apply your experiences and create a terrific
solution.
Unfortunately, an ordinary customer places constraints on you that can seriously hamper
the design. In the end, the product might not achieve its intended goal, be difficult to
use or produce and might not be maintainable. I've been party to these problems, and it's
a no-win situation for everyone. After-the-fact finger pointing won't fix any problems.
The correct solution is to either walk away from this situation before starting the
project or try and educate the customer as to the benefits of changing into a great
customer. My next column will continue the discussion of the customer and then switch to
the third ingredient, your role as an embedded-system consultant. PE&IN
Adapted from an article that appeared in Personal Engineering & Instrumentation
News.
Return to the article index.
|
