I Hate Lunchables!
Managing EDA Tool Installations

Sales and Engineering - Who'd of Thunk It?

While I was in college getting my engineering degree I spent several semesters as a co-op at Intel just outside of Portland, Oregon.  Two of those semesters were spent in a technical marketing group where I spent a significant amount of time developing training collateral to help our customers do 100BASE-TX PHY conformance testing.  It was one of the most fun jobs I've ever had.  I got to get my engineering groove on doing technical work and at the same time help Intel's customers develop better products using our silicon.  When I graduated I went to work for Intel full time as a verification engineer.  As a verification engineer I was (and still am) able to flex my technical muscles and can have a major impact on the final quality of the end-user product. 

However, I soon discovered there was something missing from my professional life that left me a little down in the dumps.  What was missing?  It was the interaction with "customers".  Somehow I didn't feel quite as motivated to get things done when the only person who cared what I was up to was my manager and the design engineer I was working with.  (Though I must admit, I have always gotten a bit of sick, sadistic pleasure from finding flaws in other people's work - one of the hallmarks of any good verification engineer!).  Sitting in a cubicle all day staring at a computer screen is a perfectly natural state for some engineers, but not for me.

I've found that in order to be truly satisfied with my career I need to feel I'm doing more than just enough to get by.  That's one of the things that has driven me into consulting, and one of the reasons I started reading up on the sales process.  As an engineer I'm always thinking of new ways to solve old problems.  The worst part about having so many great ideas bouncing around in the old cranium is they always seem to bounce off each other and collide just about the time I'm hoping to persuade someone that there might be a better way to solve their problem.  They get mixed up, diluted, and in the end may cause more confusion than provide assistance.  With a better understanding of the sales process I believe I can help more people more frequently.  I've been reading Zig Ziglar's "Zig Ziglar's Secrets of Closing the Sale" over the past weekend.  A few key phrases have stuck with me so far:

  1. "The customer is the biggest winner in an ethical sales transaction."
  2. "Honesty means we believe so deeply, so completely, so fervently in what we are selling that we can't understand why other people don't buy."
  3. "People buy for their reasons, not [ours]."
  4. "Words alone will often fail, so [we] demonstrate to make the sale."

Let's break them down one by one to see how they can apply to an engineer collaborating with others.

The Customer is the Biggest Winner...
I take this phrase to mean that when I'm able to "sell" my ideas and products (in the form of source code, documentation, etc) the benefit to my "customer" should be much larger than it is to myself.  For example, if I can ensure the quality of taped-out silicon, shave 10 minutes off of the time it takes every engineer on the project team to run every regression, or enable cross-site collaboration through the creation of a robust SCM methodology, I've given the customer (my manager, my company, my client, etc) far more benefit than the monetary value of the time and effort I spent on coming up with the solution in the first place.  If I haven't accomplished that, I haven't done my job.

Believing in What We Sell...
I'm not sure to what extent I believe in the power of positive thinking to solve the worlds problem's, but I do know that in order to make sure the customer is the big winner, I need to believe deep down in my heart of hearts that I've got something so beneficial to my "customer" that I can't fathom why they're not interested.  If I've just thrown together some half-baked code and I know it, I'll never be able to convince a fellow engineer that it's worth the time it will take that person to learn to use that code.

People Buy for Their Reasons...
This is the one I struggle with most.  We may believe our team will come out ahead using our solution, we may not understand why no one wants the fruits of our labor.  So far, so good.  But if we can't empathize with the people we're working with enough to understand the objections they have to our solution we might as well just throw in the towel. This has happened to me several times over the course of my career.  I've pushed hard for specific tools and methodologies, changes in staffing levels, and the like.  The times I've been successful have been the times when I was able to get into the minds of my coworkers or clients so I could counter any objections and make them feel like the solution was their own. 

Words Often Fail...
Engineers don't take kindly to talking points and slick marketing presentations if they don't have a basis in reality.  If you're trying to convince your colleagues to move in a new direction you'll need to do more than just talk.  They say it's better to ask forgiveness than permission.  It will often be well worth your effort if you take a little time to come up with a demo to back up any project proposal.  That way you can deal with objections in real time vs. saying you'll need to get back to the group after additional research.

And So On...
Recently Mike Pedneau from TI gave a talk to a group of verification engineers here in Austin.  In it he discussed the difference between engineers doing "high value" work and those doing "low value" work.  I think it's safe to say that the higher the value of the work, the more selling you'll need to do to be successful, and vice versa.  If my assumption is correct, those engineers worried about loosing their jobs because the value of their work is low might want to consider taking up an interest in sales.