In Engineering fields, how often do you find yourself being asked to be a "salesperson", and what is your reaction? [closed]

Question

I have recently been told that my "salesmanship" is lacking when it comes to getting my ideas implemented. I receive the feedback that my ideas are sound and the data to implement is compelling, and even that the ideas are presented in a way that management can understand, but I am not doing a good job of "selling" the idea when it comes time to implement.

I feel a little odd about this because on the one hand I can understand that, as an engineer, I haven't honed this skill. However, on the other hand I feel almost blindsided that this is a skill I am expected to have; the decision-makers have already said, "go implement", but when I go to implement, the people with whom I am supposed to partner put up barriers to progress.

I'm wondering how others deal with this.

Answer 1

I think I know what you mean. The terms "selling" and "salesmanship" are somewhat confusing in this context. Really you just need to be able to explain the situation and the reasons behind it in a context that the other side can understand. This differs when talking to management or engineers. I would call this more justification than selling.

1. Justifying to management

If you are talking to management to get a green-light for an idea, you need to not only explain why it is technically viable, but also what the business benefits are of this idea above other ideas. For example: it costs less to initially implement; it is easier to maintain (costs less); it is harder to maintain (creates lucrative service contracts)...

What is 'good' really depends on the business strategy of the company as highlighted by the last two examples which are opposite from a technical perspective, but both might be considered beneficial under different business strategies.

If you don't like or disagree with the business strategy of your company, leave and start your own business and treat your customers better. Or at least you can begin to understand why your ideas are not adopted despite being technically fantastic.

2. Justifying to engineers

It sounds like you've already got the go ahead from management and now you're struggling to convince other engineers why this way is actually better. Well, the reason you're struggling is because those other engineers don't understand the business strategy and how your idea fits in with it. So now you find yourself in the odd position of having to explain the business strategy to engineers. You don't have to justify the business strategy itself, only why your technical solution fits in better with the business strategy dictated to you from management. You need to do this in terms that non-business oriented engineers will understand, which can be tricky because quite often the best technical solution is at odds with the business strategy.

Example

I'll use a real-world example that I had to deal with recently to explain. This is from a software company, but applicable to any engineering situation.

The company wanted to have two separate work streams (two teams) doing essentially the same thing, creating two different products (that do the same thing) for two markets. Utter madness technically, especially when both products could share so many components and in fact could even be the same product with some minor configuration options to address the differences in these two markets.

Engineers were struggling to agree with this approach until I explained to them that 80% of the revenue was coming from one market, and the competition there was also much more fierce, so the business strategy was to focus one team solely on this market, without any consideration for supporting the other market so that they could move quickly and stay ahead of the competition. The secondary market was still worth exploiting and growing, so the second team would focus on that. This is the strategy given to us, this is the problem we need to solve, not that other problem of making the single-product.

Conclusion

I don't think you need to learn sales, you just need to be able to identify when other engineers are trying to solve a different problem than you (normally caused by ridiculous non-technical things like customers, profit, economics, and all that malarkey). Then you need to be able to explain what the problem actually is and why, so that they jump on board with your (already accepted by management) idea.

Answer 2

"Salesmanship" in this context, means "being able to overcome resistance."

"Resistance" can take one of two forms. It could be "reasonable" resistance for e.g. economic reasons, whereby the proposed technical solution is not economically feasible. In this case, you might do well to find a cheaper solution, or at least an acceptable compromise. Here, you don't need classical "selling" skills but you do need some "marketing" skills to put together a package that will convince the bean counters that you won't break the bank. These people will at least be direct about their objections that "the math doesn't work," or "the numbers don't add up" [to a profit].

The "unreasonable" kind of resistance takes place if you happen to be going against vested interests. Then you need to find out what those interests are, who the "decision maker" is, and whether your technical solution can be revamped so that those objections disappear. This is more of an internal, "political" situation than a straight "selling" situation.

These are not everyday engineering issues, but do occur from time to time. I'd field them as well as possible because these events could make or break an engineering career. This is particularly true if you have aspirations to leave engineering and go into "management."

Answer 3

I find that often clients are resistant to change (internal or external clients), and even when they agree that technically something sounds/ appears to be a good solution, they do not want to let go of their existing process or product. (Why? Because that's what we've always done)

So you have all of this beautiful data - and an elegant solution to a clients problem. This is where the real work begins. This is also where it gets tricky, within the company I work for this has been handled by encouraging engineering staff to pursue MBA degrees to help develop their business sense, we also hired a dedicated marketing staff to help polish proposals and presentations, because the truth is not all engineers are great "salespeople".

As far as helpful advice, I guess what I for you as a basic starting point would to find a good book on marketing, or persuasive speaking, as it doesn't sound like the problem lies within your technical solutions.

Answer 4

I wouldn't be too stuck on the "salesman" term here. Engineering is (supposed to be) a (mostly) rational enterprise (sometimes). So the general approach would be to identify and understand technical and business related aspects/concerns and address them rationally.

Stabbing comfortably in the dark about your specific issue, I would say it is probably worth thinking about whether the most important aspects and impacts of your idea are clear in your peers' minds. Things like money, time/resourcing, potential to win projects could be considerations you'd want to address. The other answers provide already some good comments.

I'd like to add the following that I think hasn't been mentioned yet:

Timing in regards to impacted disciplines

A good idea / innovation may struggle if it means immediate, additional and potentially unpaid work for a partner discipline or colleague. E.g. (coming from a building design and construction background) if the building service engineers have essentially finished their design and your new idea would lead to substantial changes to their services, you have a problem because you are asking them either to work for free or to enter variation negotiations with the client. Same thing would happen no matter what stage they are if they have overclocked their hours for whatever reason.

Possible solutions could include:

• Push for your idea earlier in the project to give your colleagues time to digest and understand the impact of your idea
• Make your idea part of your team's bid (your idea might win the next project for the team)
• Is there an opportunity to influence the project brief?
• Consider that it might not happen in this project. Take your time to explain the idea to colleagues outside the context of the immediate project. Listen, ask questions, try to understand the reasons for the resistance (there might or might not be good reasons as already discussed by @TomAu and @jhabbot).

Resourcing impacts of partner disciplines

If your partner disciplines don't understand your idea, they might decide not to support it since they will have a hard time identifying how much resources and time they should allocate. Project time is often not the right time to fix this; people chase deadlines then (although sometimes project time is the only opportunity). Try to introduce ideas early on. Listen to your peers' concerns and offer help overcoming them.

Understanding the design process within your context

Who pays for the project? Who benefits from the specific idea? Who is impacted during design, execution, operation, phase out? Are there implications to the project program or budget (for clients and/or any disciplines involved) if your idea is taken up? Is special resourcing required? Does it make someone obsolete?

Don't get stuck on your one idea and on this one colleague who keeps telling you to improve your salesmanship

If this particular idea doesn't fly today, let it go for now, wait for the next one, however keep the idea at the back of your head and mention it again when the time comes.

If you can't convince this one key person, find another one or wait for another one. In the meantime keep asking what they mean by "salesmanship", if they have a good example for it, what they would have expected from you, if they could get you a mentor or if they could mentor you themselves. Their response to these questions might also help you understand their motivation and thinking.

Answer 5

In the field of civil engineering, I don't think I've ever had comments on "selling" my ideas. There is certainly scope in my field for people of all levels to make technical suggestions, and those that are good get implemented.

I wouldn't say there is much "selling" to be done within internal civil engineering teams though. There is normally a problem to be solved, there may be meetings to discuss it, and the actions come out of the meeting. I get the impression that in your field you are more of a manufacturing/production engineering and hence only good ideas get prototyped? I don't think I can find an equivalent in civils.

Answer 6

As once engineering career evolves it is important to develop soft skills. Good communication skills will help persuade peers to accept once point of view.

A presentation with extensive engineering analysis data that appeals to engineering design team member doesn’t always appeal to manufacturing or operations engineering team members. In such cases it is a good idea to tone down engineering analysis data and highlight the benefits to manufacturing or operation engineering departments.

As once engineering career evolves it is beneficial to understand engineering’s impact on other department such as marketing, accounting, manufacturing and operations. Building good relationships with members of other departments helps the process communicating complex technical information. These internal departments our internal clients and they need to be server the same or better then external clients.

Established reputable companies in US recognize the importance of soft skills. These companies have programs to develop soft skill and good communication skills for their employees. Personality test such as Myers and Briggs help determine the personality characteristics of individuals, and training programs to develop any area deemed needing attention.

Finally “Getting to Yes: Negotiating Agreement Without Giving In” and “How to Win friends are Influence People” are too good books to read to help address concerns of the stated question

References:

• Getting to Yes: Negotiating Agreement Without Giving In
• How to Win Friends and Influence People
• Myers–Briggs Type Indicator