SLTF Consulting
Technology with Business Sense



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

Copyright © 1998-2012 SLTF Consulting, a division of SLTF Marine LLC. All rights reserved.