When I first started to work for National 16 years ago, I thought I was going to learn how to design good monolithic ICs. And I did, eventually. But the very first day on the job, Pete Lefferts gave me National's new 1976 Linear databook, with a list of 10 ICs taped onto the front cover. "These are the ICs that our group is responsible for. In our group, we design engineers also handle the applications engineering for our parts," Lefferts said. Well, that setup sounded pretty good to me, because up to that time I had been pretty much an expert at applying ICs. I soon figured out how to field and answer most of the calls cheerfully. Of course, there were some calls too technical for me to know the answers. So, I just took good notes and then got some help from other more knowledgeable guys. I learned how to steer the customer to the right op amp (whether we made it or not). I learned how to explain to a customer that a TO-3 regulator could dissipate 20 W, but only if attached to a heat sink. I even learned to refer to an LM741, rather than a µA741.
The most important thing I learned was that if you want to avoid lots of "dumb" phone calls, you should write a very good, clear, comprehensive data sheet. When customers ask for needed information that wasn't included, it's not a dumb question, but rather a dumb data sheet. At least 30% of the calls were caused by a lack of sufficient information in the data sheet. So I learned to put lots and lots of good info, necessary info, into my data sheet. The penalty for not doing so is having to answer "dumb" questions forever.
That reminds me of the Quality Control procedures for the "riggers" - the people who pack parachutes. Obviously, packing parachutes is a very serious, very responsible job. How do you make sure that the guy packing 'chutes never gets sloppy, never goofs off? Ah, very simple: At the end of every month or so, each parachute rigger is invited to select one chute at random from a pile of all the chutes he has packed, and then he goes up and jumps out of a plane. Ah, if only there were QC procedures as good as that one, one that we could design for other jobs! If only we could all have such a good incentive to do perfect work. But in general there is not ... if you can name one, you tell me.
Anyhow, in the last five years, our Linear group has moved further away from the concept of having every Design Engineer do applications engineering, too. This certainly makes some sense. There are some people who are really good at designing silicon, and it's not fair to tell them they can't do it if they're not also good at talking with customers on the phone.
So now we have gone into a little bit of specialization. Unfortunately, it often means that an apps engineer gets on the phone to discuss a big project, and soon needs "a band-aid to put on his ear." There are times when an hour on the phone is needed for a special case, and that really is tough on the ear. In other cases, an apps engineer gets on the "MAC," and works on several data sheets for a sprint lasting several days. I don't think I would enjoy that. Still, there are detailed technical problems that are appropriate for me to answer, and I still help out on specialized facets of applications engineering. I just don't get to take so many "cold" calls.
But what is the crucial thing about the applications engineer's job? I guess it's that he (or she) is an interface. Whenever the design engineer wants to design a piece of silicon to make a customer happy, the apps engineer should help facilitate the process, by showing the best way to teach the customer how to apply the circuit. He has to write a clear data sheet, list all of the features and specs, spell out cautions, and show what new applications are suitable.
What if the proposed silicon is lacking a necessary feature? Then the apps guy has to holler "WHOA!," until the need for that feature (or the lack of that feature) is resolved.
One time I was doing a redesign of a regulator, and the apps guy wanted me to add in protection so all of the pins would be ESD-proof, up to 2000 V. But I argued that if we added that protection, the circuit would not work in some existing sockets. Finally we compromised. I agreed to add all of the ESD-proofing I could so that the part could work in existing sockets. We wound up with a part that would pass only 800 V by itself, but when plugged into a usage circuit, its ESD tolerance was improved up to 2 kV because some pins linked together.
Other times, when a customer has difficult questions about an IC, the apps guy acts as a filter to make sure that all of the relevant questions get asked. Then the design engineer has all of the information he needs before he starts to work on the problem. The apps engineer is quite valuable when he gets all the facts lined up for the experts. Of course, most of the time, the apps engineer gets the facts and solves the problem by himself - he is the first-line expert.
What other things do apps engineers do? They design and evaluate circuits. They write and rewrite data sheets and applications notes. They teach other people by giving seminars and writing magazine articles. They communicate with every kind of user, from the grouchiest to the nicest, from the laid-back to the desperate ones. Their customers include op-amp experts, and also expert chemists who need a little advice about how to interface simple op-amp circuits to their systems. They hold the customer's hand. They won't let him fail.
Apps engineers act as a psychologist, and sometimes as a psychiatrist - they cajole and debate, and they know how to convince people to do things. They also bread-board things. And they run computers. They simulate things. They interpret ideas and data and people's wishes.
Do they get rich and famous? Usually not. Most of the time, they get (at best) begrudging thanks from the customer who did not like to be told that he needs a heat sink to keep his 20-W regulator from getting hot ... or from the IC design engineer who is mad that his project is delayed because the apps engineer talked him into redesigning his output stage to add a necessary feature.
On top of everything else, the apps engineer has the thankless job of deflecting and absorbing a thousand complaints. Like an offensive lineman in the National Football League, the best he can say is that he didn't let the quarterback get sacked today, despite the opposition's best moves. Maybe he even has the chance to make a brilliant play. But most of the time, people just beat on him, as if they were trying to wear him down. They ask every kind of picky, niggling, quibbling question. They bring his sanity into doubt. Sometimes they make his day less than fun. Sigh.
Apps engineers don't just get steamrollered. Sometimes they get nibbled to death by ducks. They may even get ulcers. But usually they have a personality that lets them survive these stresses. After all, just because we put all of the info in the data sheet - does that mean that people READ That Fine Data Sheet? If all else fails, call the Apps Engineer? If all else fails, read the data sheet? Never happen!!
I recall one friend, Jim, who had been an apps engineer for many years, and he gradually decided that he was not in a mood to talk to customers on the phone. One day his phone was ringing and he was sitting at his desk trying to ignore it, when his boss walked in. After a few more rings, the boss said, "Jim, do you know who is on that phone?" Jim replied that he did not. The boss said, "Jim, the guy who is calling you on that phone, is a customer. And you ought to answer that phone. Because that customer is me." And he went on to explain why an apps engineer really has to answer the phones. Jim was able to talk his boss into not firing him outright, but he was given a month to find a job he could agree with.
There's still one last thing that apps people do, and I think it's the most valuable: They listen to people tell them what they "need" and what they "want." Then they try to figure out what the customer really needs to make him happy. That may be quite different from what the customer says.
Sometimes the customer is unrealistic. Sometimes the apps guy is "lucky." Sometimes there's no brilliant or easy answer. But when I was doing a lot of apps work, I considered it my most valuable privilege to hear 19 people ask "simple" or "trivial" or "nasty" questions, and to answer them the best I could, just so I could hear one customer ask a REALLY GOOD question.
Sometimes the question points out a deficiency in a data sheet, leading to an improved data sheet, so every user gets the advantage. Sometimes it leads to an applications note, or a magazine article. Other times it leads directly to a new product. Other times it leads to a debate, or an argument with your boss, or a screaming contest. Out of that argument often comes some better way to do something. But you never can tell which caller will be asking the really valuable question. Sometimes it's the op-amp expert - and sometimes it's the chemist.
My boss will probably be pleased to hear that the amount of time I'm "wasting" on apps engineering is less than a couple hours a week. But when someone asks me to put on my Applications Engineering hat, the calls I get are really some of the most interesting and valuable ones. That time isn't "wasted" at all.
Comments invited! / RAP
Robert A. Pease / Engineer
And now, here's a comment from Kerry Lacanette, Applications Engineer for Data Acquisition Circuits at NSC:
Bob, I don't think the customers are as bad as a reader might infer from your discussion. I can think of lots of those annoying "duck" calls in which a series of customers would ask "why don't you build a ... ?", or, "Do you have an ... IC with a pin that does ... ?" or some other question that we thought we had spelled out clearly in the data sheet. While we may have been annoyed by some of these calls at the time, or we carefully explained to the customer why they couldn't have what they wanted, these customers were really voting - voting for features, products, and better data sheets. We have occasionally counted these votes, and brought out better products because of them.
"Nibbled to death by ducks?" Yeah, I feel that way on a bad day. But would I prefer to take only the "good," "intelligent," or "challenging" questions? Nope. - Kerry.
Kerry, I agree with you completely! You have helped me complete what I wanted to say. Another way to look at it may be that just because a question is "dumb," it doesn't mean the "answer" is dumb. The answer may be challenging or complicated or valuable - and vice versa. Thanks for your comments. - RAP
Originally published in Electronic Design March 5, 1992.
RAP Update: I got several comments and letters from several Applications Engineers. They tended to agree that being an Applications Engineer is quite challenging ...
