Developers Vs. Sales Reps: Can’t We Just Get Along?
How software developers can communicate effectively with their sales colleagues to build better products and improve customer satisfaction.
Relations between sales and development personnel within an enterprise software vendor are not always easy. Although we’re all working towards the success of the same company, taking the wrong attitude or approach to communications can easily derail discussions and lead to unproductive interactions.
In this article, I’m going to highlight areas to be mindful of and how things can be better handled so that both sides can continue working in harmony for the benefit of all stakeholders. Please note that I’m not going to be specifically describing what goes on in our company, but, rather, discussing the relevant issues as they would apply generally.
Different companies have different names for these roles, but for the purposes of this article I’ll be using the terms:
- “Sales” or “Sales Reps” when referring to people who interface directly with customers, and,
- “Developer” to mean staffs that work directly on source code.
When a Sales Rep Asks, “Can you make XYZ?”
The Dreaded Question
Developers working for enterprise software vendors are all familiar with their sales rep colleagues bounding up to them full of excitement with a customer request.
Here’s a few typical examples:
“Hey, can you make XYZ?”
“A prospect told me, ‘If it could do XYZ, then I’d buy it!’”
“One of our customers told me, ‘I want it to do XYZ. Could you add that feature?’ I reckon if we did, we could count them in our sales pipeline!”
As a developer, this can put us in a tricky situation. Although we’re already up to our eyeballs in tasks, we want to do anything that would increase customer satisfaction and therefore sales. However, we are not a limitless resource. We must consider realities such as schedule, personnel, and priorities. However, when we try to mention such items, it can seem as though we’re trying to find a reason to avoid having to do the work and add the feature. They can get the impression that we’re being cynical or difficult.
The frustrated sales rep thinks to themselves, “I was just asking if it can be done or not!” They then go complain to management that, “Our developers are being difficult.” Or, “Our developers just don’t understand sales.” Such scenarios can easily spiral out of control until we end up with the dreaded “Development vs. Sales” dynamic permeating the office and bringing down everyone’s spirits.
Taking a Step Back
Rather than looking to place blame on one side or the other, it’s more productive to see the situation as having been caused by poor communication and insufficient sharing of information. There’s no point in fighting. After all, both sides want to satisfy the customer’s needs and push the business forward.
As a developer, we can work on improving the ways in which we respond to such requests. However, often the person asking, “Can you make XYZ?” hasn’t fully considered the implications of what they’re asking and doesn’t have a clear idea of precisely what they want. Therefore, there isn’t enough information for the development side to give a sensible answer.
The solution is for developers to regard this kind of question as an opportunity to work with the sales staff to figure out what exactly is wanted.
Shifting to “Yes, we can!” as Our Default Response
First, I’ll write a premise from my experience as a developer. Of course, not all developers think like this, but I think it’s generally accurate.
While it’s true that sales staffs have a different perspective to those in development, they are human beings working for the same company. We are all on the same team. It’s generally unlikely that they’ll ask for something utterly impossible or unreasonable.
So, most of the time, when a sales rep asks a developer “Can you make XYZ?” In most cases, the request is technically possible, so it’s best to answer “Yes, we can.”
Of course, development work requires time and resources. However, we can get to that later. For now, in most cases, it’s best to give a positive response.
We developers spend our days working on technology that we want people to actually use. Therefore, having a direct request from users of what they want is a chance we don’t want to miss. We shouldn’t discourage our colleagues in sales from bringing us ideas or requests that might take our company’s business to the next level.
That said, there will be situations where it may be impossible to realize with today’s technology, or it may be something that has compliance issues.
For example:
- Sending 200 TB of data from Japan to the USA in 0.001 seconds (impossible with today’s technology).
- Collecting the social security number of all people in a particular country (even if it were technically possible somehow, it would be unethical and illegal).
- Send an email to Abraham Lincoln (impossible last time I checked!).
Well, these were ridiculous examples, but my point is that when something is clearly impossible or illegal, we must decline the request on the spot to avoid getting their hopes up. However, we should do it gently and explain the reasons why without making the sales rep feel patronized or belittled. It’s just not worth making enemies when we don’t have to.
Hypothetical Example: A Burger Shop’s Order System
[If you’re Hindu, Muslim, vegetarian, or vegan sorry — perhaps you can just imagine they sell super, ultra gourmet burgers with ingredients you can eat?]
Initial Assessment
I’d like to illustrate with a hypothetical example. Let’s imagine there is a fictitious data integration middleware, “SuperDataLinker” which finds and integrates remote data snippets.
And, one day, a sales staff comes to us with this request:
“There’s a restaurant called, ‘BurgerX’ that wants to allow people to order burgers in advance. Can you build it?”
BurgerX (fictional) is well-known for its incredible hamburgers. In this story, there is a nearby office occupied by a company whose staffs love it so much, they want to be able to place orders before they go to lunch.
Well, everybody loves a good burger. However, while holding back the urge to blurt out, “Yes, we can!” We developers first have four factors to consider.
- Need: Do users really need this feature? Yes.
- Technical: Is this feature technically possible to implement? Yes.
- Market: Is there sufficient demand for such a feature? Possibly.
- Planning: Do we have the resources to develop and release this function within the timeframe desired by the customer? This needs review.
Of course, there are other considerations, but these are the main ones. They are closely related to each other, but let’s examine them one at a time.
Defining the Requirement: Are Burgers Enough?
Let’s say that we just went ahead and built the early remove order feature for BurgerX. However, once we did, we might start getting requests for being able to order different dishes or order from other restaurants.
So, then the development team goes ahead and builds these extra features into SuperDataLinker, which of course means that time and resources are required for development and testing them.
In this case, rather than agreeing to the original request and adding the desired functionality later, we’d suggest that from the beginning, we change the requirement to being able to order any item available from a restaurant of the user’s choosing.
However, it could turn out that what they really wanted was a function to consolidate orders from their staffs rather than submitting an order to the restaurant. In this case, the existing functionality can cater to these needs, so we don’t have to wait for the next release.
The point here is that if the requirement isn’t properly investigated, clearly defined, and thought through, then regardless of how well it is coded and tested, the feature won’t get used, and nobody is happy.
Therefore, before any code is written, it is worth investing the time to consult with the sales rep and work through the following questions in depth to confirm all details.
- Does the function really satisfy the user’s requirements?
- What is the background behind the request for this function?
- Could this function be realized with existing functions?
Solving Technical Challenges
Let’s say that we got through the requirements definition stage without any issues and are ready to begin work. The next question is how do we go about undertaking the implementation from a technical standpoint?
For example, suppose that we are thinking about considerations for implementing the ordering function in SuperDataLinker. We’ll likely need to consider the following.
- Can the function be realized with the OS and programming language we are using?
- How should we go about adding the functionality to the software?
- Are there any potential incompatibilities if we add these functions?
- Although there are endless possibilities, we should consider the order process in depth.
The first thing to check is that what type of interface is available for BurgerX because this will determine the difficulty of development significantly.
Let’s look at four potential scenarios.
Scenario #1: BurgerX has a REST API (highly unlikely):
- Easy to implement because many programming languages have the HTTP request function.
- If the function that hits the REST API has already been implemented in SuperDataLinker, it may be possible to proceed with without implementing any further enhancements.
Scenario #2: BugerX accepts orders via fax (somewhat more likely):
- Consider the function of collecting orders and sending Faxes.
- Consider using external functions such as fax transmission service — what would be the interface of such a service?
Scenario #3: BurgerX accepts orders via phone (most likely):
- Consider using an external service to call automatically.
- Consider implementing or adapting an automated call-answering system.
Scenario #4: BurgerX has no telephone or fax, and can only accept orders via carrier pigeon (highly unlikely):
- Consider implementing the RFC 1149 RFC for IP over Avian Carriers (IPoAC).
- Everyone loves cute pigeons, right?
So, that was obviously absurd, but my point is that depending on the interface required and technologies used, the difficulty to build it and the hours needed for coding will vary significantly.
Other variables include the programming language, operating system, external services, and implementation methods.
Once you have worked through the above process, you can determine the requirements and the necessary schedule and resources in order to make the decision on whether or not the work is doable. Only then can you confidently give the answer, “Yes, we can do it!” along with the requisite caveats.
Should the Order Function Become Standard?
This is where we need to get some long-term perspective on the future of the product as a whole. It is important to consider whether it is necessary to make the order function a standard offering in the SuperDataLinker software package vs. making it a one-off ad-hoc addition for just one customer.
If the feature is useful to other users and valued by them, it will benefit the product as a whole. However, if no other customers end up using it, then we have a problem. As we add such functions, the product becomes seen as bloated and overly complicated, damaging its market appeal.
Furthermore, even if only one customer ends up using the feature, you’ll have to continue maintaining it indefinitely, which will require time and resources on an ongoing basis.
If in the examples above, the function is set to make a specific order to a particular restaurant, then it may work well as a standard feature.
To be more specific, if the function has the capability to:
- Make a call to a specified phone number, and,
- Create the sounds for specified characters (text-to-speech),
Then this leads to enhanced functionality as a product, improving the product’s value to users.
Another possibility is to not add it as a function, but implement it by way of an external service that uses an API and existing functions. This could be the best option. Another option is to no make the function part of the standard package, but a one-off, ad-hoc addition for just the one customer requesting it.
When considering how to position the function within the product, we must ask ourselves:
- Should we release it as a general-purpose standard function?
- Or, if not, what kind of implementation methods are available?
- How would we educate the users?
Defining the Schedule
Once we’ve completed the process and reached the decision to move forward with developing the new function, we arrive at this somewhat contentious juncture. It’s now time to examine the schedule required for planning and research, coding, testing, and release.
Let’s look at the following steps:
- Technical verification
- Function implementation
- Creating a test case
- Creating a usage manual
- Testing by the QA (Quality Assurance) team
- Creating the release document
Some tasks can be done in parallel, but since there are also tasks that can only be done consecutively, even if we increase the number of people (resources) there is going to be a limit to how fast it can be completed. Also, within the company, there are obviously limited resources. Furthermore, not all qualified people are going to be available as soon as we need them due to existing projects, tasks, and duties.
With these constraints in mind, we must come up with a schedule estimate to meet the user’s request while keeping in mind that despite best intentions, things seldom go as planned. We may miscalculate, or circumstances may change.
So, this modifies our original response to the sales rep’s question as follows:
- Sales Rep: “Can you make XYZ?”
- Developer: “Yes! But, I can’t say right now when we can do it!”
However, even if we respond in this way with enthusiasm and confidence, we’re likely to be met with a cold smile from the sales rep. Generally in these cases, a user will make a request along the lines of, “On [date] we’ll cut over to the new system, so want to have it within the two months prior.”
Building on that information, we can ask your team questions such as:
- If you proceed with development using your usual resources and workflow, can you release it within the users desired timeframe?
- If not: (i) Would adding more personnel accelerate the process? (ii) Is it possible to negotiate with the user to delay the release? (iii) Is there a function that can be excluded from the implementation this time?
- Does this project need to be given priority over other projects in the company? If so, how will this be accommodated?
- Is it possible to meet the users’ needs by releasing a beta version first, separately from the standard workflow?
As your team progresses through these questions, you should reach some clarity on the resource and schedule constraints, upon which you can draft a concrete response to the user’s requests. Of course, it’s impossible to foresee all issues that will come up, and you’ll likely need to revise your schedule and adjust resources.
Drafting a Formal Response
Thank you for bearing with me through this exploration of how to respond to what, at first, seems like an easy to answer question; “Can you make ___?”
Let’s return to what our sales colleague would like to know:
“A restaurant called Burger X would like to add a function to SuperDataLinker that lets them receive orders in advance. Can you make it?”
Based on our exploration of this so far, our response may look like the following.
- Are burgers the only items that will be ordered? How about fries?
- Will this functionality be desired by restaurants other than Burger X?
- Considering these, wouldn’t it be easier for people if they could choose the restaurant and food items?
- However, rather than an ordering function, perhaps a function that collects orders would satisfy the requirement? If so, it may be possible to meet the criteria using existing functions. Is it possible to request the user to consider?
- How will Burger X interface with SuperDataLinker: REST? Fax? Not carrier pigeon, right? The development schedule will vary depending on the interface chosen.
- Furthermore, the implementation will have to adjust to meet the constraints of the specs and OS of the device which will run the software.
- Since this functionality is difficult to use overall, it wouldn’t make sense to release it as a standard feature unless it was part of an expanded functionality including being able to receive telephone calls and having an automated voice function. This is likely to be desired by the user so it would be best to proceed after first consulting with them.
- What is your desired implementation timeframe? Is it strict or open to negotiation?
- Since we have several projects currently underway, we wouldn’t be able to start work until April next year.
- If we proceed with our standard workflow and resources, the implementation would be completed sometime the year after next. However, if the priority is high, then we’d need to adjust internally. Shall we do that? What do you want to do?
Of course, throwing all of this at our sales colleague is going to give the impression that we are very reluctant to accommodate their request. That said, these are all important considerations for development, so we need to find a way to discuss them that is productive.
When we consider all of the possible risks and issues, it is easy to fall into the trap of finding the most comfortable response, which is declining their request or giving reasons why you can’t implement it. Of course, there are going to be cases where the request simply isn’t possible or realistic. However, that should be the final option. And, if that is the only logical choice, you’re going to have to find a way to let them down easily.
We want to avoid using a communication style that is unnecessarily combative and can quickly derail the discussion into an argument. However, to not explore all issues at the outset would result in misunderstandings and unrealistic expectations. A balance must be found.
There is no single correct way to go about this, and our approach should be adjusted to take into account the nature of the product, the desired new functionality, its urgency, and the status of internal resources at the time. It’s essential to carefully approach the discussion positively, being aware of them as an individual, with a focus on how we can realistically accommodate their requests.
The aim is mutual understanding can be reached among the developers, sales reps, and the customer.
Conclusion
Development and sales must centrally strive to work together for the good of the company and its customers. Over the long-term, a healthy business with satisfied customers will produce better products that benefit both internal and external stakeholders. One key to this is harmonious and productive communication between developers and sales reps.
About the Author
Takumi Toki works in the team that builds DataSpider Servista, enterprise middleware which empowers IT teams to integrate a broad range of data sources without the need for coding.
