How to support the sales team and avoid the "Often the sales team gets us into trouble just to get a commission" problem

Question

With reference to this answer:

At the end of the day, we are delivering a product to a paying customer. This customer has needs and expectations, realistic or not. Often the sales team gets us into trouble just to get a commission.

I realise there are processes (mainly with communication and project managment) that can help minimise risk (these seem to have minimal impact, mainly due to being ignored by anyone other than dev) and believe a percentage of the problem is their complete lack of technical understanding rather than greed (though this does play a part). But when it isn't possible to get rid of commissions (very good article), get (train) better salesmen, or increase dev resources, how can you minimise the impact on developer moral, timelines and generally development department being held responsible?

How common is this damaging to the business (and no one higher up will believe how much better it could be - they don't see any problem now, but wonder why sales fall through and customers aren't happy) and how do others mitigate the risk, prove development is not the issue and handle such situations where the marketing is too aggressive and overselling is normal (which all propagates from the top)?

How can you support the sales team and upper management to improve the root cause of this situation and what changes can be implemented in dev department to help with this?

Additional information: the is only one product we create and as such is sold with additional functionality as required or work to let it integrate with existing systems.

I was worried about close votes, but this is a very real problem (and I have tried to word it objectively)- if you can comment on how to improve this question, please let me know.

Answer 1

Are you sure these requests aren't deal killers? i.e. the customer will not buy your product at all if they are not met. You'll be in no position to argue otherwise.

complete lack of technical understanding

Sorry, the dev team or someone with more technical knowledge may need to get involved with these requests. Just ask to try it with one client and see how it works. Maybe there are workarounds? You may discover this was a "nice" to have instead of a "must" have. Sales people are taught to never say no. Programmer morale may improve if they see themselves as part of the sales process. They may not get commissions, but bonuses and raises are affected by company sales. Show you're part of the solution.

Start putting together internal time quotes to upper-management so they know how much this is costing the company. If bug fixes and enhancements are on a tight schedule, what is the priority? They may discover they are leaving money on the table and could be charging customers to add these features at the customer's request. Otherwise, offer to consider adding it for the next release if it is a good idea for the app.

At least start asking "why" a request is being made. The goal is for you to have the most comprehensive understanding of the problem so you can provide the best solution (I should be a salesman!). This is NOT a form of pushback. You might be surprised at the answers and make a better product.

Answer 2

They might have a better technical understanding and ability to estimate than you think, maybe even getting most of their estimates from engineering. What typically happens is estimates are made without regard to all the other commitments you've made. Sure, a feature might take two weeks if you didn't have anything else to work on. A schedule must take into account your entire capacity. If sales doesn't ask for this, then engineering should take the lead.

I wasn't in the meeting when we first tried this at my company, but I'm told it was quite painful. Basically, they put a list on a whiteboard of everything product management wanted us to do over the next 10 weeks, then engineering put a red line under what we could realistically accomplish. We wouldn't move the line, but a huge negotiation ensued about what would end up above or below that line.

What happened is they decided certain things weren't so urgent after all. Some lower-paying customers had to be disappointed. Some products were consolidated to meet more than one customers' needs. Some features they asked for a limited version that would be quicker to implement. They found ways to reuse and improve products they previously decided to abandon.

Like I said, it was painful for a while, but I think now they are much more confident in a commitment being a commitment. They don't have to spend as much time explaining why features are slipping, and trying to get customers to believe the next ship date is the real one. They know when they ask for something new that something else must be sacrificed. They are getting their top features completely finished, rather than getting everything they want, but each feature only 80% complete at the deadline.

Answer 3

I realise there are processes ... (these seem to have minimal impact, mainly due to being ignored by anyone other than dev)

generally development department being held responsible

no one higher up will believe how much better it could be - they don't see any problem now, but wonder why sales fall through and customers aren't happy

They used to ignore the schedule and constantly re-prioritise projects, even asking for two things to have top priority, we've got that more under control now, but it still goes on, they just don't tell us until it is too late.

due to their size they can use threats

these issues occur before we are involved

Those are your root causes right there and they paint a picture of a very badly broken corporate culture.

How can you support the sales team and upper management to improve the root cause of this situation and what changes can be implemented in dev department to help with this?

I have my doubts that anything you change within the dev department will make any difference; you already communicate (and are ignored), instigate processes (which are also ignored) and try to manage projects and resources properly (only to be undercut by sales and management setting priorities and deciding on features without bothering to consult dev on their feasibility).

Dev team management needs to be in the loop and HEARD in any decision involving development resources; sales and management do not know how resources in dev are allocated, yet they are being allowed to make final decisions whose outcomes depend on that information.

Priorities need to be agreed upon between sales and dev and not constantly changed without VERY good reason. Dev needs to make it clear that changes have consequences, that prioritizing one thing will reduce the priority of another and that constant priority upheaval will merely result in nothing being completed. Yes, sales get to decide what is a priority for their customers, but only within the constraints of dev deciding what is realistic within the time involved. This must be a team effort between sales and dev, they have to work together to find the best compromise which actually serves the customers' needs with best use of the available development resources.

Good luck. I suspect you're going to need it.

Answer 4

if THIS:

and generally development department being held responsible

is always the case, I don't see there is anything you can do. If you cannot change that part of the company then you will always be swimming against the tide.

The way this company does business (sales promising the moon on a stick) is actually quite common, but always blaming the dev team for not meeting targets set by sales is massively incorrect.

If this fundamental thing cannot be changed you have no chance of saving morale etc.

The sales people often have no idea what it is they are actually selling. Well, they know what a website means. They know it might have a database.... you keep stuff in there right?

To try and describe this to non-technical people, I often make the distinction between physical "real" things and computer software.

I knock my hand on the table (assuming we're at a table) and talk about how the table is a real, physical thing. It's got 4 legs, a smooth wooden/whatever surface. It is a tangible, real thing. Change the colour? Yeah, no worries, that's easy, 2 min fix (or whatever).

Huh, you want me to add wheels to the legs so the table can be moved around easily? And add a device that will raise the level of the desk? Not so easy.

Software, to non-techies, is this woolly, amorphous blob that lives inside their monitor (not their computer, their actual monitor). They can't touch it. They cannot comprehend how it works, or how it is built. They might have heard of computer code, or seen it scrolling across the screen in an episode of 24, but they have no idea that it is NOT trivial to just throw things together, or change them on the fly.

Answer 5

I would change the structure so that the sales people get their commissions not when the contract is signed, but when the product ships. That way if they sell stuff that you can't build they don't get paid.