Re: The joys of having a non technical manager.

On Sat, 02 Aug 2008 23:41:04 -0700, Tim Wescott <tim@xxxxxxxxxxxxxxxx>
wrote:

John Larkin wrote:
On Sat, 2 Aug 2008 12:09:34 -0700 (PDT), sfisher@xxxxxxxxx wrote:

My non technical manager thinks that our (very) complex electronic
products shouldn't have prototype stages in the project plan because
electronics engineers should aim to 'get it right first time'. This
guy has had 20 highly successful years of managing the production of
speakers, and treats every little design problem as a sign of
incompetance (and I do mean little).

Has anyone else had this kind of experience and how did you cope?

We cope by getting it right the first time.

My company philosophy is to go from paper to production. That means no
prototypes. The rev A drawings and parts lists and manuals are
formally released, manufacturing builds a few, and we make them work.
Over 90% of the time, we can sell rev A.

We do simulate or breadboard small circuits if we feel that we don't
fully understand the parts, but mostly we design from the datasheets.
But we never simulate or prototype whole products.

Prototyping is self-fulfilling. If you assume the first (or second, or
third) iteration won't be right, you won't make the effort to get it
right. The insidious factor is that debugging by testing prototypes
seldom finds all the bugs... *especially* when the designers are the
ones doing the testing.

We do keep a NEXT file on every rev of every product. Anybody in the
company can add comments or requests for things to be changed on
future revs. Manufacturing creates a lot of these, like about
mechanical clearances, or requests for test points, things like that.
Before we order future/large batches of boards, we review the NEXT
file to see if it's worth spinning the board.

John

I think there's a big difference, though, between assuming that you
_must_ get a 100% success rate and aiming to get a really high success
rate like 80 or 90 percent.


The way to get 90 is to aim for 100. Which means checking everything;
asking other engineers to check everything; reviewing the PCB layout
yourself, in detail; not taking risks unless the payoff is huge;
reading the hell out of datasheets; making sure hooks are available to
get out of trouble. We're talking a couple of days of checking saving
a month or more of revision spin.



Further, if the guy really treats "every little design problem" as a big
failure, then your testing and tweaking before you get your rev A boards
into production would be signs of failure.

Spinning the layout to rev B, which will take weeks at best and trash
other projects, is the failure. Changing a few resistor values, or
even a small kluge, is perfectly fine, so long as we can sell
presentable and functional rev A boards about the time we promised.

We often know that parts values will change before we release the BOM.
Like for a filter we haven't finished designing, or a temperature
compensation factor or a loop compensation. Some parts are "TBD",
unstuffed, when the first boards are built. Failure is being slammed
by something major that you didn't anticipate, and having no hooks to
fix it.

When we do screw up, we go to the other engineers and say, "Wow, look
at the incredibly dumb thing I did!" We learn from one another.

Here's a good one: I got used to deriving fpga Vaux (2.5 volts) from
+5 using an LM1117, so I just copied the regulator circuit to a new
design, but ran it from +3.3. The 1117 has too much dropout for that,
so my 2.5 was low. I found a melf zener diode in stock whose *forward*
drop was just right to take 3.3 down to 2.5, so we pulled the
regulator and dropped the diode in.

ftp://66.117.156.8/DiodeKluge.JPG

I got some serious groans over that one. Worse groans when I started
doing the same thing on new designs.


I've worked for companies run by sales guys who really did well at the
motivational speaking, but just didn't have a clue about how engineering
worked -- including the necessity to hash out problems. Consequently,
if one of them got too close to a project the engineers were not
_allowed_ to hash out problems before going into production, so the
problems all came out in production.

That's silly too. If some manager doesn't want to see how engineering
is done, he should stay away. And engineers shouldn't RFM anything
that's not ready.

Life is simple: do the engineering right, and don't take any crap from
anybody.

John

.