Great advice Cortland! I also ran into an interesting article on LinkedIn regarding how best to deal with your manager when it comes to these issues, without getting fired. Interesting reading…
http://www.linkedin.com/today/post/article/20131119031719-7668018-speaking-up-without-getting-fired?trk=mta-lnk _______________________ Ken Wyatt Wyatt Technical Services LLC k...@emc-seminars.com www.emc-seminars.com Phone: (719) 310-5418 On Nov 19, 2013, at 8:49 AM, CR <k...@earthlink.net> wrote: > I suspect many of us came into EMC unconventionally. I certainly did. I > walked into a job in EMC at Wang Labs after retiring from an Army career that > had me in the Signal Corps and Transportation Corps in communications and > repairing Avionics (also supervising and instructing). I had been playing > with electronics since age 12, when I used a TV focus coil to build in my > bedroom what some might call a rail-gun. > > On retiring from the Army I was a single parent with a pension that only paid > the rent. I wanted work as an instructor, but without a degree, the only > people who made an an offer paid less than I'd gotten on Active Duty. > Luckily, my my brother passed a copy of my resume' to his neighbor, who > worked for a large computer firm now defunct, Wang Labs. I was able to show > them I knew how to use the equipment and already had a high enogh security > clearance for Tempest work, so I was in. > > Having come up through the lab, I look for not merely theory, but a feel for > systems and problems. A couple of my later employers had me interviewing job > applicants and I got an (undeserved, IMO) reputation for being a difficult > interviewer, handing candidates a ferrite bead, for example, and asking, > "What is this? What does it do?" and "How?" or something like a PRD-219 and > asking, "What is this and how is it used?" (I own a couple.) > > Most of the scrUwups I've seen were the result of engineers or managers (not > just in EMC): > 1) Ignoring (or ignorance of) basic principles of EMC design; for example, as > Mother used to say (not really) "Cortland! Put that electron back before he > yells for his Dad!" > 2) Neglecting to get all parties to producing a product to ATTEND design > reviews and point out what they can and can't do given the design and desired > results. > 3) Ignoring (again BASIC) principles of shielding and grounding even in > testing (all too common). > 4) Not talking directly to engineers and techs on projects outside their own > areas of expertise. Everything matters. Even firmware. > 5) Not looking at systems a whole; test setups, platform or user > configurations, regulations and standard – everything that concerns emissions > and susceptibility in use. It took time and effort (and one actual RFI > complaint) to convince a manufacturer of telco equipment that if it was on or > near a residential property it had to meet FCC Class B. > It has been the rare employer whose management was on board with EMC problem > prevention; perhaps surprisingly, one of my better ones was Tandy, whose > first venture into the IBM compatible computer market in the late 1980's was > not only yanked off the market by the FCC, but incurred a sizable fine for > not having been submitted for testing (it failed). That'll motivate you! It > did get a me a job there. > > IMO, an organization needs both educated engineers and those who can hold > people to basic principles; if you do all the simple things right, you will > usually have done the complex ones too. WRT the EMC Cop role, I prefer the > missionary position (heh). Really, convert them, don't yell at them. An > Outside Expert many of us, at least in the US, know, was called in to look at > a PWB design and his first words to the CAD layout guy were "Your board is a > piece of sh*t!" How not to influence people, etc. They did listen to my > simpler and less confrontational advice thereafter. > > I'd have LOVED to get a job applicant who could show what's wrong, what's > right, and explain why in plain English; colleagues not in EMC will often > want simple rules: X mils of clearance and Y mils of prepreg; Z mils of > copper between bypass caps and devices etc. Sometimes it's worthwhile to make > design rules simple just to get them followed... but one must know what the > rules do, and why, and be able to teach those who must follow them . > > I was offered a job at DSC Communications (later Alcatel USA) as a test > engineer, and when I arrived, they gave me the choice of that or design. That > was no choice at all; I chose design for, as I answered when asked why, test > engineers have to fix the same problems over and over, but design engineers > can stop them from happening, By dint of constant, friendly and informal > oversight (I asked for and got read-only access to the schematics and layout > of every project from my own terminal) and collaboration with designers in > every group, I did that. I even got the mechanical engineers on board. (That > took a lunch and learn with a modified stock-pot “shielded enclosure” and a > hand held radio receiver. ) I didn't realize then, but I would learn, that I > needed to keep an eye on what the firmware and software did, too. > What does the EMC engineer need to be? Theoretician, practical engineer, > teacher, tech, missionary and salesman; electronics, metals, coatings, > insulators and chemistry; tooling, manufacturing and maintenance, all of that > too, essentially a systems engineer with a finger in every discipline. If you > find recent graduates that skilled, grab them, and pay them what it takes to > keep them, because they'll save a lot more than it costs to have them around. > Retired, I still get an occasional contract to explain High School physics to > people who should know it. And I'm still learning. > > Cortland Richmond > - > ---------------------------------------------------------------- > This message is from the IEEE Product Safety Engineering Society emc-pstc > discussion list. To post a message to the list, send your e-mail to > <emc-p...@ieee.org> > > All emc-pstc postings are archived and searchable on the web at: > http://www.ieee-pses.org/emc-pstc.html > > Attachments are not permitted but the IEEE PSES Online Communities site at > http://product-compliance.oc.ieee.org/ can be used for graphics (in well-used > formats), large files, etc. > > Website: http://www.ieee-pses.org/ > Instructions: http://www.ieee-pses.org/list.html (including how to > unsubscribe) > List rules: http://www.ieee-pses.org/listrules.html > > For help, send mail to the list administrators: > Scott Douglas <emcp...@radiusnorth.net> > Mike Cantwell <mcantw...@ieee.org> > > For policy questions, send mail to: > Jim Bacher <j.bac...@ieee.org> > David Heald <dhe...@gmail.com> > - ---------------------------------------------------------------- This message is from the IEEE Product Safety Engineering Society emc-pstc discussion list. To post a message to the list, send your e-mail to <emc-p...@ieee.org> All emc-pstc postings are archived and searchable on the web at: http://www.ieee-pses.org/emc-pstc.html Attachments are not permitted but the IEEE PSES Online Communities site at http://product-compliance.oc.ieee.org/ can be used for graphics (in well-used formats), large files, etc. Website: http://www.ieee-pses.org/ Instructions: http://www.ieee-pses.org/list.html (including how to unsubscribe) List rules: http://www.ieee-pses.org/listrules.html For help, send mail to the list administrators: Scott Douglas <emcp...@radiusnorth.net> Mike Cantwell <mcantw...@ieee.org> For policy questions, send mail to: Jim Bacher: <j.bac...@ieee.org> David Heald: <dhe...@gmail.com>
