War of the worlds: techie against salespeople

The traditional conflict of sales and production in technology companies has deep roots, much more distant than even the appearance of the first telephone companies. Today we’ll talk about where all this comes from and how to make it profitable and profitable.

image

Motivation defines consciousness.


The reason why salespeople do not like developers and representatives of other engineering specialties is familiar to anyone who has sales experience and lies on the surface. They are annoyed even by how much the latter are in no hurry!
After all, the seller is interested in doing as much as possible and faster, and the developer must first of all do it qualitatively.

The conflict of motivation is the reason for the war of the worlds, which you can observe in your company. Sales people are paid more often for the result, programmers for the process. Salespeople are encouraged by quantity, quality by programmers. It’s hard to work in sales, but difficult in programming, and these are very different things.

Interestingly, combining the motivations of these different roles in a company is not so simple. It makes no sense to encourage millions of lines of code from programmers, just as it makes no sense to encourage perfect diction from a manager on a phone call.

What remains?

Constructive or destructive conflict?


In fact, the conflict between sales and production is at the same point: the point of delivery of value to the client (delivery). At the moment when your company shipped the device or provided hi tech consulting service, or installed software developed for the client on the battle server, a conflict may or may not happen.

Usually sellers seek:

  • have points of influence on the client;
  • maximize profit on the client;
  • make the customer as happy as possible.

At the same time, engineers seek:

  • to do an interesting job efficiently;
  • fulfill the requirements of your immediate technical supervisor;
  • maintain comfort in their work.

Sellers try to avoid:

  • responsibility for the technical complex details of contracts;
  • shift dates.

Engineers try to avoid:

  • responsibility for poor performance of technically complex requirements;
  • communication with the client directly.

Most of the conflicts between sales and production follow from these premises, however, some of these conflicts are not only inevitable, but also useful.

Constructive conflict is a conflict that helps the parties to the conflict to learn something new that is useful for themselves, to become a result of the conflict better than before it started.

A conflict of sales and production can be constructive if the following conditions are met:

  1. Sales in your company know production capacity well and do not question it. They know that you can sell just as much, and they have no problem with that.
  2. The production at your company knows that it is not profitable for them to disrupt signed contracts, that if they fail, they get some tangible discomfort.
  3. In communication with customers, there is partial interchangeability between representatives of sales and production, that is, the manufacturer has the right to try to sell, and the seller has the right to justify the technical concept.

If these conditions are met, the conflict between sales and production is constructive: in this case, sellers demonstrate an example of result-oriented behavior, and manufacturers bring quality to the work.

How to identify and stop destructive conflicts


Destructive conflicts have clear markers, and here they are:

1. A demonstrative manifestation of disrespect for a colleague. A programmer can call a salesperson an offensive word in the presence of colleagues, or vice versa, a salesperson will condescendingly speak about the programmer's role publicly.
Any manifestation of disrespect at all levels must be strictly suppressed until the parting with the employee.

2. The prevalence of information about “who is to blame” over information “what to do.”
When discussing the situation, in this case constructive periphrase works well. The employee says: “Because of this line in the statement of work, we will not be in time by Friday.” Perephrase: “I understand correctly that this particular task is a serious challenge that can be solved only by brainstorming and a champion jerk?”

3. Strict adherence to the "letter of law" and the boundaries of their job description.
Many technical experts flatly refuse to participate in client calls, even to explain the difficulty and to buy time for themselves. Similarly, a salesperson can take a tough stance and say: “I sold, and now you want it”, and it will be wrong.

To deal with this, the following things will help:

  • to prescribe the regulation “operations in the gray zone, which everyone is afraid of” (as an engineer communicate with the customer, as a salesman to help the technical team justify the increase in estimates, etc.)
  • introduce incentives for the targeted action into the motivation system.
  • provide training on conflict resolution and create an agreement on how to resolve them.

Stop fighting! Let's play better


In fact, it is this motto that works best when viewed for a long time.

In this article, we described how to systematically reduce the number of conflicts among engineers. Surprisingly, it turns out you can create a "game so as not to swear." If you determine the fact of a resolved conflict as a useful action, then all your developers, especially the most gambling ones, can be hooked on this story.

To do this, think and conduct a questionnaire in a team, what might be a welcome prize (let there be several), enter a champion label for resolving situations, describe clearly and clearly what is an action to resolve the conflict (for example, an agreement on SMART and a handshake of participants) , appoint your office manager to look after the sign and you will be surprised to see how your sales people rush to collect points for mediating quarrels among colleagues, and programmers conspire not to swear.

However, business gamification is a separate and interesting topic and, as they say, is another story.

Article author: Andrey Mayboroda

All Articles