The joys of having a non technical manager.

** Are you saying that your project manager is non-technical ???

Surely only an experienced engineer has that job ?

** Personally - I would tell him he is unqualified to be a project manager and simply ignore the ridiculous control freak.

You have not supplied near enough info on your situation or the management structure for any better advice.

..... Phil

Reply to
Phil Allison
Loading thread data ...

[snip]

That's what all the bean counters are tried to sell to Boeing's engineering management. They call it Six Sigma. No more certification or acceptance testing.

Problems will be unearthed by the customer. Sometimes literally, at a crash scene.

--
Paul Hovnanian     mailto:Paul@Hovnanian.com
------------------------------------------------------------------
Stupidity kills. But not nearly often enough.
Reply to
Paul Hovnanian P.E.

SOP at a previous employer. We started out with managers experienced in their fields. But they became less involved with technical decisions and more with planning-scheduling.

So, we became reliant on a system of "lead engineers". The manager would designate a go-to person to make technical decisions and pass him data needed for planning. As the years went by, managers became less and less involved with schedules, resource planning, etc. and less with technical details. On my last assignment, they moved in a lead that had no clue as to what we did or the state of the art in the technology.

I left. I let them lay me off when they moved the job overseas.

--
Paul Hovnanian     mailto:Paul@Hovnanian.com
------------------------------------------------------------------
Where am I going, and what am I doing in this handbasket?
Reply to
Paul Hovnanian P.E.

Apparently, you can scratch skydiving from that list.... See:

formatting link

-mpm

Reply to
mpm

Is that OK with the FAA?

John

Reply to
John Larkin

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.

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.

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.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" gives you just what it says.
See details at http://www.wescottdesign.com/actfes/actfes.html
Reply to
Tim Wescott

The first time he asks the status of a new project, tell him that the speaker design is complete..

Reply to
Robert Baer

That's exactly the situation.

Reply to
sfisher

That's exactly the situation.

Reply to
sfisher
[...] PS someone once told me the trick of using low value resistors in series with the feedback capacitors of op amp LP filters to stop HF oscillation.

Agreed. I usually fit cheap ceramics knowing their abysmal ESRs does the damping job. After the design is proved good using the cheap crap, then some points might have more expensive caps fitted for final production. The oscillation thing finally turned out as some kind of transmitter breakthrough, (cell phone maybe, do they work that high and do people talk for a whole hour at a time?). Wasn't helped by the spectrum analyser leaking via a bad input attenuator connection on one of those little gold plated connector things, brazed onto a bit of pipe, that look like they might tighten with a spanner ;)

Reply to
john jardine

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.

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.

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

Reply to
John Larkin
[snip]
[snip]

One of my life-forming experiences was sharing a cubicle at Motorola with Tom Frederiksen.

We picked on each other's designs unmercifully.

We both learned a lot from each other... he references me in his booklet, "INTUITIVE IC OP AMPS" ;-)

...Jim Thompson

-- | James E.Thompson, P.E. | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona 85048 Skype: Contacts Only | | | Voice:(480)460-2350 Fax: Available upon request | Brass Rat | | E-mail Icon at

formatting link
| 1962 | All that is necessary for the triumph of evil is that good men do nothing. -Edmund Burke

Reply to
Jim Thompson

I think we're actually on the same page here.

Reply to
sfisher

I'm lucky to work with a few very smart people who rag me mercilessly. I yell "wait! I'm the President!" and it doesn't do me the slightest bit of good.

John

Reply to
John Larkin

I've had first builds go through HAST, but anything new has already been breadboarded, and nothing else 'new' is knowingly permitted - not even types of screw, given previous experience. It's the 'knowingly' that is the catch 22 and that's why it's called a prototype.

You can waste a lot of resources getting the wrong things 'right'.

If all your unknowns are in firmware, aren't you just consuming resources the non-technical manager is too dumb to count?

RL

Reply to
legg

We do prototypes only rarely for those circuits that are hard to simulate, data sheets that are questionable, and/or layout is very critical. Granted, our multi-channel analog designs only go up to 1 MHz with gains up to 90 dB and our digital signaling going across a PCB are under 200 MHz clocking frequencies. That does make life easier. I've only done one special prototype PCB in the past 10 years for a pair of switching power supplies we were designing. I put 3 power supply designs, plus some other instrumentation circuitry, a personal project, and a special BGA part which had to be environmentally tested on this board. It was a well utilized proto board.

We can usually get the first boards working as deliverable items. I usually build up boards a section at a time so I can test isolated areas which are likely to have design issues. This sort of design process is achievable with a small, cohesive, design team and folks who have had many years of experience - including the manager. If the manager manages from a spreadsheet, there will be lots of problems. More than five engineers, there will be interface problems. My solution was feed the manager data, then have the engineers do stuff behind his back to work out issues in an informal way. Next week, I would feed information back to the manager which would piss him off because we weren't following the previous block diagram to a tee.

The last company I worked for had a hostile management takeover. Going from a CEO that was technically savvy and made the necessary big decision risks to a bunch of twittering investment-type management who's only interest was to sell the company and bilk the company reserves. Millions of dollars were spent giving each other high salaries, bonuses, and golden parachutes. In a matter of months, they took a very successful company into the doldrums. The company went from a very open structure to secretive meetings. However, their meeting outcomes were public knowledge amongst the peons because they would leave lots of information on the printer output tray, including salary lists and their employment contracts. My solution was to quit. In fact, all the key personnel quit within a year.

-- Mark

Reply to
qrk

It takes intellegence to understand intellegent people.

-- Mark

Reply to
qrk

That would be the super-watertight cast in concrete spec path. Almost none of my clients can do that. Most of the time it's "Well, we think we need this, that and the other thing but we aren't 100% sure it'll work that way". Because it's mostly cutting edge stuff, never done before. That's one reason why I do not have any surcharge for urgent stuff on holidays or weekends. My dentist does :-(

--
Regards, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Reply to
Joerg

Un bel giorno snipped-for-privacy@cwcom.net digitò:

In this thread two philosophical types of "prototypes" have been considered.

If with "prototype" you mean a frying pan board, two or three times bigger than the definitive board, with a lot of different ways to do the same thing in a sort of trial-and-error process, I partly agree with your boss. We do that only on very few occasions, when a certain knowledge lacks and trial-and-error costs less than proper design (either by learning or by hiring who already knows). The frying pan prototype means little confidence in your technical skills; this is sometimes acceptable in a small company like we are, never in a medium-big company.

If with "prototype" you mean a properly designed board, that if all goes well you can directly put in production, otherwise you will fix with some easy modifications in the BOM or PCB, then I totally disagree with your manager. No one is infallible, and whoever tells you the contrary is a damn liar.

--
emboliaschizoide.splinder.com
Reply to
dalai lamah

They need to make it into a coloring book, for the management types.

--
http://improve-usenet.org/index.html

If you have broadband, your ISP may have a NNTP news server included in
your account: http://www.usenettools.net/ISP.htm

Sporadic E is the Earth\'s aluminum foil beanie for the \'global warming\'
sheep.
Reply to
Michael A. Terrell

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.