The cause of conflict between developers and sales

Most software engineers can recall a situation where a salesperson asked them if they could deliver a particular feature yesterday. The surprised developer then explains that the requested functionality will never be on the roadmap. The salesperson will then clarify that they promised it to a potential customer, leaving little room for debate.

Let me be clear here. Both sides are wrong, although for different reasons, but to understand why we need to explain the purpose of every company: The creation of value for the company.

Note the part that says "value for the company." The company is not the owner, stakeholders, or employees. A company can function perfectly without any of those. The owner might sell the company, and stakeholders change all the time. Some companies even fired most of their workforce, including their best people, because the company pivoted to a new market that didn't require their skills.

The reason why people are hired, promoted, and fired is thus always related to the mission of creating value.

Software engineers get hired because they can aid the company in creating value. A company that doesn't need software engineers to create value will most likely not hire a software engineer. They will buy a product from another company.

The same applies to those working in sales. It might sound strange, but not every company needs a sales division. Small companies will hire a salesperson when they need one. However, most companies have a salesperson because having others pay for your products/services is the easiest way to generate value for the company.

What actually happened?

Let's go back to our situation and think this through. What reason will a software engineer have to refuse a feature request, and why would a salesperson request a feature that is not part of the delivery?

• The software engineer might argue that adding the feature has a considerable cost and risk.
• The salesperson might argue that the value of the software increases significantly and prevents the software from becoming outdated.

What I find interesting is that both sides are correct but also wrong.

• The software engineer is correct about the functionality and cost but doesn't understand that there is no value in "working software that doesn't sell."
• The salesperson is correct about the potential profit and the risk of becoming obsolete but needs to understand the effort required to make software.

If both sides discuss it, they will likely agree that the other is making a valid argument. We don't have those talks because both sides have targets to achieve that are invisible to the other side. The salesperson is most likely unaware of the quality that needs to be delivered, while the developer needs to be made aware that providing the requested feature prevents the salesperson from closing sales.

So how can we fix this?

First, both sides must agree that their shared goal is to generate value for the company. We often have personal goals that might conflict with this statement. And thus, this is way harder than most people think. Most developers want to be proud that the software is stable, while sales only need it working without issues for the first 20 days or so. And sales might be so focused on selling that they need to understand that their developers are the product's primary consumers and that we are the first ones who are majorly affected when the software has a bug.

Once addressed, we can focus on the core problem: Poor communication. And luckily, this has an easy fix. Sales should keep developers constantly in the loop about what the customers need. And developers should inform sales about the current direction of development.

But what if we have the problem now?

Whether you are a developer or a salesperson, start by communicating. Accept that both sides were not taking the other side's situation into account, apologize, and promise to do better in the future. Doing so restores the relationship and allows focus on the current issue.

Once done, both sides have to talk about the value. If the sale involves billions, most software engineers will understand that the development direction needs to change. The same is true for sales; when they know that the cost involves months of work, they can do the math and see that the price is unlikely to be covered. Those are the easy scenarios.

In most cases, it will be more complicated. In that case, we must quantify the revenue, cost, and risk. Once both sides have numbers (use best, worst and likely scenarios instead of a single number), they can compare numbers and evaluate the risk. When both sides have shared goals, they should be able to agree on the same outcome. A small warning: This sounds easy, but it is anything but easy.

My final advice to both sides

Dear developer, please talk to sales and ask them about the state of the market. Show interest in what ways the company could generate value. A part of sales we need to hear more about is the effort required to convince a potential customer. As a result, sales often have much information about what improvements the product needs to become better. The improvements sales will suggest are different from those presented by support.

Dear salesperson, creating software is a monumental task that developers can do at a decent speed if the work is organized. Experienced developers prepare code so that sudden changes have a minimal impact, but the only way we can do that is by knowing what is going on. Also, ask the developers what they think about the product; after all, they start, use, and quit the applications many times during the day. You might hear something that customers also complain about but can't express. And most customers enjoy a call in which they hear that the company takes their opinion seriously.

Take the time to find out what makes the other side tick. Ask questions and take in the answers. Listen to the different perspectives and be open to changes that benefit both developer and sales. Doing so will create healthy working relationships and lead to both sides' success.