Is there a way to combat Sales perpetually overcommitting?

Question

I seem to be repeatedly stuck in a situation where release dates are set not based on anything technical, but because someone in Sales has committed to a customer by then. Based on discussions with friends in development at other companies, the same thing seems to happen.

"Here is the committed feature set and here is the committed release date", and it's difficult to argue because at this point there is money riding on it, and that trumps everything.

In general, is there a way to push back on this? If not for this release, what about in future? The problem I have is that the only way I see one way of doing so, and that's by doing the best I can, but release the software 'as is', so to speak.

I don't want to release bug-ridden software since it's my name attached, but doing 80 hour weeks for months at a time just vindicates the arbitrarily set release date.

edit: for the record, I'm not doing 80 hour weeks now, just that comes to mind as what would be required to cover the expected feature set by the release date.

Answer 1

Stop doing the 80 hour weeks. This is positive reinforcement. Because they are getting the product on time with expected costs, they are going to continue doing it, regardless of what it does to you.

If they cannot budget time properly, then that's management's fault. Not yours.

Let them miss a few deadlines.

Answer 2

In general, is there a way to push back on this? If not for this release, what about in future?

Of course, there is: Let them fail badly with this approach. Nothing teaches as well as failing.

Make an estimation yourself before you start and show it to them. Then do your best, write good code, stop compensating for their stupidity with your free time, and when they complain afterwards, remind them of the time estimation you had shown them, based on engineering principles.

And you better start doing this with the current project.

If they keep blaming you for the problem, you'd better start hunting for a new job, since nothing will convince them that they are the problem.

As an afterthought, I think this question actually warrants a link to the famous EA story as featured in one of Joel's books: EA: The Human Story.

Answer 3

This generally occurs because of a perverse incentive - the salespeople are being paid on commission, while the production staff is paid on salary. The salespeople have several levers to work with: features, cost, and delivery date. They have a strong disincentive to lower the cost, because this generally lowers their commission, so they tend to ratchet UP features and delivery date (in terms of being earlier). They will push those as high as they can in order to close the deal.

Try and see it from their point of view, just for a moment. They've got a family to feed, too - and if the difference between closing a sale I've been working on for months is just trimming off a few weeks of the schedule, then it's an incredible temptation, especially if I don't really understand what that means.

The temptation is to say "twas always thus, and always thus will be." But one place I worked did at least have a solution PROPOSED, if not implemented...one manager finally threw up his hands and said, "if the programmers' overtime is being used to close a sale, then they should receive a portion of the commission." It wasn't implemented, but it would have aligned everybody's incentives more closely...the programmers would have been thrilled to hear about a new feature that had to come out in no time, because they'd be anticipating the commission, and the salespeople would be LESS apt to create those circumstances, because they would be less likely to work to their advantage.

Answer 4

The development team must be consulted on these decisions or you will never get out of that cycle. If you aren't managing the team, then one of your line managers needs to advocate for the development team. If they are part of the problem, then you may want to consider other employment options.

Generally speaking, Sales shouldn't be committing to anything without the Product Management's acceptance, who should obviously be consulting with the development team for timelines. There's really no good excuse for bypassing this in a big or small company because ultimately the Sales team will take some heat for under-delivering (whether in quality or scope).

Answer 5

This is almost a universal thing in smaller companies as they have a greater need to close a deal. Until I was brought into sales meetings at my company I was bitter about this but I can at least understand how and why it happens a little more.

Clients want it fast and many will play hard to get. This encourages sales to bend on time commitments just to get something signed. A signed contract is gold because you can acquire capital or credit using one. Sometimes it is better to have a tight deadline than nothing to work on at all.

Other times if it is a hot market and there are a lot of competitors then the company has an impending need to get a product out the door FASTER than everybody else. A bigger company or one with more capital can always hire more resources, a smaller one can't.

Where it is scummy is when the deadlines are truly artificial and it is pushed by sales and management to secure large bonuses for themselves.

Don't make a habit of working more than 45 hours a week, it is bad for your health and that comes first.

Answer 6

I've worked both sides of the house. Remember without sales people there would be no downstream jobs or projects.

How to battle sales over-commitment: Estimate, then take at least a 130% multiple (always plan a minimum 30% contingency). Provide and document said estimate. Realize that your effort estimates will be reduced in the sales process. That's OK, just have management carve out of the license/sales/commission agreement any reduction of those hours. If you're a public company this gets tricky with VSOE, but until you hit the sales folks with contract accountability up-front during their sales process, it will become your accountability later.

Answer 7

There are lots of strategies you can use, but you'll usually need approval or buy-in from management.

1. Pay developers overtime at an increased rate. Working extra hours isn't so bad when you're making a lot of extra money doing it. And if it starts to affect the company's bottom line management will apply pressure to sales to do a better job estimating.

2. Pay salespeople based on profit instead of gross sales. Every hour of work that they don't include in their estimate adversely affects their commission.

3. Limit the number of hours developers can work to 40 (or whatever the standard work week is in your part of the world).

4. Make the sales folks work every hour that the developers work. If they want you working extra hours to get their project done, they've got to be there too. Find something useful for them to do, like writing documentation or producing calligraphed, hand-illuminated copies of Design Patterns and The C++ Standard Template Library.

5. Have developers estimate each job instead of letting salespeople do it. At least this way you get some ability to make the schedule more reasonable. This isn't a great solution, though... developers are often terrible at estimating work required. Even if the estimate is reasonable, unforeseen events can prevent you from hitting your target. Also, we all tend not to work at the beginning of a long project with the same urgency that we do as the deadline approaches. These are the factors that motivate the short development cycles that the Agile proponents espouse.

6. Take the "agile" approach and refuse to commit. Going agile will require a lot more customer involvement, but it can also give the customer more flexibility because they don't necessarily have to commit up front to the final form of the project either. Sales might not be happy about that at first, but they might change their tune when they realize that it can provide a lot of opportunities to sell more work.

I think the least attractive solution is anything that makes the sales team look bad in the eyes of potential customers. The sales team is the face of the company. Making them look bad hurts the entire company, and it might not solve the problem -- they might feel like they need to make an even better deal for the customer in order to regain their confidence.

Answer 8

Quit

There are lots of sensible suggestions in the answers already, which hopefully can help work out this dysfunctional relationship. But in the end, you decide how much you want to work.

It's easy to get pressured by coworkers into overworking. But you're sacrificing your personal life when you do that.

Here's what you can do:

• Say to your boss, "I've had to work a lot more overtime than I want to here. From now on, I'm not going to work more than X hours per month."
• As others have suggested, estimate how many hours things will take up front. Remind them that "at my limit of X hours per month, I probably won't finish this by the deadline." Put this in an email for later reference.
• Refer to that email when the deadline goes whooshing past. "See? As projected, we could not hit this deadline in reasonable work hours."
• If they continue to pressure you to work overtime and all communication efforts fail, quit.

Personal experience

I quit my last job because I was always working overtime and always being asked to work more. I told them clearly in my exit interview that I liked a lot of things about the job, but didn't see any end to the overtime in sight.

I also clearly expressed that desire in my interview for my new job, and was given enthusiastic response. They have held true to their word: I'm rarely asked to work overtime here.

My former employer has a high developer turnover rate, and is finding it harder to recruit these days because they have a reputation for overworking. Maybe the extra cost of recruiting and training will teach them a lesson. But if not, it's not my problem.

Answer 9

First let's remember that we all generally have jobs to support the deals the sales guys make rather than to construct technically perfect programming-art. If they don't make the deals you don't have a job.

That said the trick is to find ways to work with sales to make everyone look good. Processes where the tech team can at least voice an opinion about proposals before they go out the door is key. Finding creative ways to handle compensation also helps alot -- if sales has to "tip out" engineering when engineering incurs massive overtime making an unrealistic schedule work it seems to drastically cut down the frequency of death march projects.

Answer 10

This is something you need to take to your manager (there is development managers, right?) and explain the problem. It's a change that needs to happen on an organizational level - sales needs to get buy in from development before making commitments, and before that will happen, they need to get that direction from their bosses.

There's nothing you can do to actually make the change happen, but you should definitely be bringing it up to your manager.

In addition to trying to change the culture (good luck), any time they come to you with a deadline you can't meet, push back - with numbers. Break down the project and show them your time estimate. If it's a six week project, tell them. If it's been promised to the client in four weeks, you can't do it, and you need to disseminate that information as quickly as possible. Hopefully, your salespeople will be able to go back to the client and set better expectations, or work with you to come up with a smaller acceptable feature set to deliver within the promised timeline, with the additional features to be added later.

Edit to add: Do not let them talk your estimate down. Be confident that it's correct, and stick to it. They will try to bargain with you, but don't let them.

Answer 11

One suggestion that hasn't come up yet: retrospectives.

Don't say "no, I'm not doing overtime," that always encourages other developers to swoop in and make you look bad.

But do say very clearly to your management that every time you have to do more than 40 hours a week to get a job done, everyone involved in the project should sit down in a room after the product is delivered, figure out what went wrong and what we can do to stop it happening again. Or, better still, every project should have a retrospective to discuss what went well and what went wrong.

If you're right and it's salesmen overcommitting then this will become very clear very quickly. But don't preempt the conclusion and don't be adversarial ahead of the fact. Talk about it in terms of things your team can do to deliver on time without overtime.

You never know, you may even find improvements to your own processes which can make the salesperson's estimate more feasible.

Answer 12

There is absolutely no way to combat this entirely. The very nature of sales is over-committing. As a sales rep you are there to make the prospective customer's problems magically disappear. Good sales reps will only slightly exaggerate, bad ones will cause themselves big embarrassment.

Anything you do will only cause aggravation or tension between the product people and the sales people (at least). You can try very hard to prevent really bad gaffs on the part of your sales reps, but at the end of the day the devs and sales reps get paid out of the same bank account. Your company will succeed or fail as a unit so starting a civil war with sales isn't going to help.

If you have one or more sales reps that are habitually embarrassing themselves, then the sales management will take care of the problem. As a dev, you aren't going to have the clout to do anything about it so you should focus on delivering the best product you can with the time and resources that they give you.

Answer 13

It's hard to answer without knowing your company structure.

Some general tools to help are:

• Have agree upon (but those in charge, not sales) quality controls
• Have a product roadmap (internal and external)

By having agreed upon quality controls, you have a business-driven reason for not being able to release buggy software. You might need to convince your bosses why this is important (hopefully not), but there is plenty of literature out there to aid in this.

By having a product roadmap, Sales know what they can and cannot promise to customers. If they want to change the roadmap, they have to raise it with the Product Manager/Project Manager/ Development Manager or whoever else is in change of it.

If they promise something to a customer that hasn't already being agreed to, tough luck. Hopefully your roadmap is based upon market data on customer needs. "What exactly do you propose we drop from these 8 other high priority features that we have evidence our customer base needs?"

Last of all, as already expected, don't work 80 hour weeks. You aren't even helping the company by doing that because you are just aiding them in digging a deeper hole.

Answer 14

Some very good answers here already. I will just add that you should not be driven to meet his deadlines to your own detriment. Also, I would definitely have a word with the sales person and remind him that if he over-promises and the company cannot deliver on his promises then he (and the company) will not be trusted in the future, losing him future commissions (and possibly his job), so it is in his best interest to be realistic (i.e. consult with programming staff) so that he gains trust in the company. In the short term he may gain by being unrealistic, but in the long term he will lose out by damaging his reputation with customers, his employer and future employers via bad references.

As sales people understand money more than anything else, talk to him in those terms.

Answer 15

No

I tried to make this a two letter answer and the stack wouldn't let me ... but the answer is

No

Which, isn't completely true if you own / run the company, of course. If you're in that position you can drag the sales team in by the ears and "have the talk". If, however and as I suspect, you are just a "lowly" technical person your only recourse is to complain "UP" the chain of command. That being said, my experience has been that in companies where this happens, management is aware of situation and doesn't care.

Answer 16

Show them this image (or this) and tell them that you are working with an impossible triangle.

  ·-----------------------·
 / \                       \
·   \   ·-------------------·
 \   \   \                 /
  \   \   \-----------·   /
   \   \   \     /   /   /
    \   \   \   /   /   /
     \   \   \ /   /   /
      \   \   /   /   /
       \   \ /   /   /
        \   ·   /   /
         \     /   /
          \   /   /
           \ /   /
            ·---·

In any project, if you fix two corners of these three:

• Time
• Scope
• Quality

... then the third is the only flexible one. What makes it impossible is the expectations. If they alway fix Time too short and Scope too big, then the Quality will always suffer. In an agile project, all three corners are more or less flexible.

(Disclaimer: I exclude the Cost factor from the traditional project triangle and make Quality the corner. The Time is the Cost in software projects.)

I hope you succeed in making your way to a more agile project management.

Answer 17

With Agile development we see consultants selling points for ~1000-1500 each. If you can change the sales process to where they have to sell based on the points scale then the sales team will be forced to work with the development team to come up with reasonable estimates.

Answer 18

It all comes down to one critical point; If you don't think you can sustain the pace necessary to meet the schedule Sales promised, then do not commit to the work. If Sales overpromises, it's not your problem, until you agree to the work. THEN it's your problem. Remind your boss that all the sales guys have to do is say yes and they get the check; you're the one that actually delivers on the promises, so if you say it won't work, your boss should be listening. If you have the ill fortune of having a manager who listens to his sales force more than his development force regarding what is and isn't possible, then you have the Dilbert-esque PHB, and you should be updating your resume.

This is one reason I like Agile; the development team is involved in the process from the initial design discussions. You can calibrate a "point" from both ends; the dev team decides (either explicitly or empirically) roughly how much development man-hours are inherent in a point, which management can then use to calculate points per week, points per month, etc which leads to a dollar figure. At that point, your sales team now has figures relating to the cost and time required for the current staff levels to get the current amount of scope done. If they overpromise once they have those numbers, they are out on their ass.

Answer 19

Spec the job after they give it to you and let them know how long it will take. Then when they crow about it tell them.

"I'm sorry you made that commitment but given the resources at my disposal It will take X hours to complete"

Do this every time...it worked for me.

Basically tell them they can have it Fast, Cheap and Good, pick two.

Answer 20

There actually is a way - a real way, not an empty platitude - but you may not like it.

Have someone from the development team involved in the sales process.

Now obviously you need someone with good people skills, someone whom the sales people aren't going to be mortified about taking along for the ride. And this person needs to have a broad understanding of the kinds of work that you do. They don't need to be a code ninja, they just need a mild understanding of coding in general and your development process in particular, and be reasonably good at estimating work.

This is really a job for a business analyst or project manager. There's a reason these jobs pay so well at many companies; they combine two very important and distinct skill sets. If you don't have a real BA or PM but have a senior dev or architect with social skills, they can do it too.

You also need to provide clear guidelines for the sales people. Effectively, you (as in your dev team) are sending someone to negotiate on your behalf. If you don't give them any parameters, they'll just negotiate what seems good to them. That's why you always give them parameters.

Once you understand the project scope, work out how much time you would like to have for building, testing, scope changes, and so on, plus a certain amount of buffer, then give them that number along with an "authorized minimum" - the lowest they can possibly go before putting the project at grave risk. Expect them to undercut that number by a certain amount as well, so make your minimum a little higher than it really needs to be.

Rest assured that their management is doing the same thing. The sales manager does not want the sales associates selling unprofitable deals. They are walking into each negotiation with a range of numbers corresponding to the target profitability and minimum profitability.

You may not be their managers, but if you document all of this in writing before they even start to negotiate, then you're on much firmer ground with upper management when people start asking questions about why the project is behind schedule. But it's not just about CYA; the sales team honestly does not have any clue how long certain things will take, and you're doing them a favour by giving them comprehensive information.

One other thing: Don't expect the sales team to get your team involved just for the hell of it. You need buy-in from the sales manager and executives, too. It really shouldn't be too hard to get, if you approach it from a risk perspective. You don't want to sell failure, do you? Think of the cost to the company's reputation. Think of the cost of a lawsuit. Someone technical must be part of any negotiation before any deal can be signed.

And if you really, honestly cannot sell management on the idea, then might I suggest finding a new employer? Because yours may not be around much longer anyway.

Answer 21

Disagreements like this are normally caused by a lack of communication. Either they don't understand the pressure they are putting on you or you don't understand what they are really asking for. Either way, to solve the issue, you need to understand the situation from the other point of view.

Have you ever tried selling software? It may not seem like the best answer to many developers, but until you've tried, it will be hard to see the business from the sales side. If you're a great developer, write something you really want to write and sell it. You may see that they have some valid points or you may see that they don't!