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.

  • 49
    Why is your name attached to the product when you are not the one making the commitments? If the company wants to put out shoddy unfinished software, that is their right, but there is no reason for you to take personal responsibility for a decision that you didn't even make.
    – user31664
    Nov 1, 2011 at 15:00
  • 4
    @Giorgio haha good one :)
    – ell
    Nov 1, 2011 at 16:25
  • 3
    @ShawnD. For the Horde!
    – Kalamane
    Nov 1, 2011 at 17:25
  • 3
    @ell: Thanks. Well, I think it is bad management to try to squeeze more work out of developers than they can actually deliver. There is an inherent complexity in each project and if you allocate too little resources you end up with bad software or you do not deliver on time. It is the task of a good management to recognize this and plan consequently. Best thing is if the manager is also a good developer.
    – Giorgio
    Nov 1, 2011 at 17:58
  • 3
    Buy The Clean Coder. Read it (i devoured it in a weekend), and apply the ideas vigorously to your career. Your job is to give an honest "No" if the job can't be done. If you don't do it, you'll have no one to blame but yourself. I know that the risk of losing employment might weigh in on being brave enough to be honest. But the flip side is being forced into 80 hour weeks to meet a totally baseless committment. Nov 3, 2011 at 2:59

21 Answers 21


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.

  • 60
    +1 for standing up for yourself. Developers allowing themselves to be walked all over is exactly what allows such sweatshop cultures to persist.
    – user31664
    Nov 1, 2011 at 15:04
  • 31
    I will add that while this works, you want to minimize the damage this can cause the client relation. As soon as you get an unreasonable deadline, you need to be upfront and let the salesperson know that it just isn't going to happen, so they can deal with the client accordingly.
    – GSto
    Nov 1, 2011 at 15:17
  • 40
    Unfortunately, in many places this will make the one dev who only works "reasonable" hours appear to not be a "team player" who does not help meet goals. They are likely to be the first against the wall when team sizes are cut. Might as well just quite and look for work for a more reasonable employer. This "work-to-rule" tactic will only work if all of the developers are on board. Nov 1, 2011 at 15:30
  • 20
    @FrustratedWithFormsDesigner Who cares if they view you as not a team player? If they don't like you they can free you of that awful place and you can look for something else while you collect unemployment for awhile. Besides it is not like sales and management at that point are concerned for the good of the "team" by expecting mandatory overtime of them. It amazes me that developers with marketable and wanted skills subject themselves to this kind of managerial bullying. If you can be terminated or quit and have another job lined up in less than 3 months then YOU carry all the power.
    – maple_shaft
    Nov 1, 2011 at 16:01
  • 6
    @FrustratedWithFormsDesigner: Having personally dealt with the high risk of failure of overcommitment I can recommend looking for a new job as soon as you know things start to get shaky. Because if you're marked as a bad team player, feel almost burnt out with all the overtime, chances are high you will be backstabbed by your so-called "team" and eventually fired even if you tried your hardest. Looking for a job as you still have one is a lot better situation for you than looking for a job while you're out of one who won't give you any good references.
    – Spoike
    Nov 1, 2011 at 23:11

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.

  • 1
    Make sure you learn the difference between an estimation and a commitment: blog.mountaingoatsoftware.com/… It sounds like they don't care about either, but once they do knowing the difference is useful.
    – StuperUser
    Nov 1, 2011 at 16:50
  • 26
    +1 for showing the estimation to them. Also, a point I'd like to piggy-back on this post: even in death-march company environments, providing work for free to customers (ie. all that unpaid overtime) is highly discouraged, because the company could have been making so much more money off the same work if they had been charging the customer for it. Pointing out that sales' overcommitment is losing the company money could make all the difference.
    – user4234
    Nov 1, 2011 at 17:58
  • 5
    A project failing teaches management nothing in a culture like the one described. Since salesmen bring in the cash and developers are just a necessary expense, the developers will always be blamed for not working hard enough if the salesmen oversell.
    – Mark Booth
    Nov 1, 2011 at 19:29
  • 2
    Yeah. So when sales comes to you without a spec, insist on one before you agree to estimate, or give them an appropriate estimate range based on the level of detail they give. This will usually be something like "between one and thirty weeks". Nov 2, 2011 at 18:33
  • 2
    @Mark Booth: That's why you need to monetize the develpment costs. Sure, development is a necessary expense, but it's not the only one. And in general, management does understand that the job of Sales is to sell above cost; any idiot can sell below cost.
    – MSalters
    Nov 3, 2011 at 12:40

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.

  • 46
    +1 if the programmers' overtime is being used to close a sale, then they should receive a portion of the commission. Nov 1, 2011 at 16:11
  • 12
    This would encourage the developers to release untested crap.
    – quant_dev
    Nov 1, 2011 at 16:48
  • 5
    I got bought lunch one time by a sales manager who got a multi-thousand-dollar commission on a project I was deep in a five week deathmarch to deliver. I can't say it made me feel much better about the situation.
    – Dan Ray
    Nov 1, 2011 at 16:55
  • 8
    @quant_dev - every situation encourages developers to release untested crap - except testing. That's a separate question. Nov 1, 2011 at 17:07
  • 18
    The easier way to adjust the incentives is to subtract the cost of the overtime from the amount of the deal before paying the percentage commission.
    – robertc
    Nov 1, 2011 at 18:09

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).

  • 2
    +1 for an accurate and high level summation. Product management should be involved, but over committing and looking bad later may be necessary for the continued survival of the company.
    – maple_shaft
    Nov 1, 2011 at 15:05
  • It's good to say things like this but it's not actual advice that could help resolve the OP's current problem. What steps could they take to get to this better position? Nov 1, 2011 at 18:41
  • @FrustratedWithFormsDesigner Aside from talking with management about the need for better Product Management input in the sales discussions, well ... nothing can be done as a developer. These kinds of companies are set in their ways and anything short of a management shake up will change nothing.
    – maple_shaft
    Nov 1, 2011 at 19:36
  • 1
    Unfortunately in a lot of companies, the opinion of the sales "gurus/rockstars" often has more weight than that of product management, who sometimes are just not strong enough in putting forward their case to upper management. I've found that many sales people believe that whatever time estimate the developers put forward, it will be too pessimistic, and can at least be halved easily. Nov 2, 2011 at 8:38
  • Sales people receive far more prestige than developers as they are far more closely tied to the incoming stream of cheques from the clients. This is true even at Software companies where developers are arguably very important, but not as important as the sales people who "bring home the bacon". This is, somewhat unfortunately, how virtually all CEO's/MD's etc. will view it.
    – CraigTP
    Nov 2, 2011 at 12:10

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.

  • 2
    I agree that it is more of a struggle for smaller companies to put bread on the table. Still it is wrong (scummy) for sales to get commissions for the extra effort of developers. Management needs to recognize then rectify this situation or they will always have a high developer turnover.
    – semaj
    Nov 1, 2011 at 15:36
  • 16
    + 1 "Don't make a habit of working more than 45 hours a week, it is bad for your health and that comes first"
    – DevSolo
    Nov 1, 2011 at 16:05
  • 2
    What's with 45hrs? Didn't you sing a 40hrs contract??
    – sbi
    Nov 1, 2011 at 17:30
  • 14
    @sbi: You might be surprised. Where I work, we were indeed required to sing the contract. In fact, it took about 40hrs to sing the whole thing. (there was a lot of fine print.) The was peculiarly bad, because I have a poor singing voice. Nov 1, 2011 at 19:21
  • 3
    @MatthewScouten how many languages do you speak?
    – jim
    Nov 1, 2011 at 22:58

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.

  • 6
    This only works if the OP is allowed to see the potential feature and give an estimate before the salespeople try to sell. It sounds like the OP doesn't even get a chance: "Here is the committed feature set and here is the committed release date". Nov 1, 2011 at 20:40
  • 2
    The problem with this is that salespeople often assume you've added a contingency and that's why they commit to an earlier deadline. Nov 2, 2011 at 8:40
  • Maybe their full commission should be predicated upon an on-time delivery then, perhaps being clawed back by a percentage of the excess developer time expended. That would align the company's interest with sales. Nov 2, 2011 at 18:39

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.

  • Can't do #4, you clearly know this. Sales are chasing 100x the prospects of any given active contract.
    – Jé Queue
    Nov 1, 2011 at 16:45
  • 2
    Re 4: I used to work in a company where sales people left at 17.00, 1 hour before everyone else. It didn't create nice feelings between the sales and the rest of the workforce.
    – quant_dev
    Nov 1, 2011 at 16:51
  • 2
    @Xepoch If they're going home earlier than the programmers then they're obviously not too busy to scratch out some illuminated manuscripts.
    – Rag
    Nov 2, 2011 at 1:49
  • 1
    @Graham, I wrote "strategies that you can use," but in fact these are really strategies that management could use if they see perpetual overcommitting as a problem that really needs to be solved. #1 might, in fact, be the most reasonable. Just because you work on salary doesn't mean that you're not eligible for overtime, bonuses, or comp time. I've received all three at different times while being a salaried employee. Likewise, changing the compensation structure for salespeople isn't impossible; companies frequently offer incentives or disincentives to change salespeople's behavior.
    – Caleb
    Nov 2, 2011 at 13:23
  • 1
    Agree with Caleb. Also, usually customers that have had their timelines pushed back and scope reduced aren't happy about it and they tend to drag their feet on payment. It should not be assumed that these kinds of things don't affect the bottom line. In fact, it is often necessary for managers and sales to actually INCREASE scope without billing more in order to mollify an angry client. You should approach management with the promise that you can help get clients to stop being angry and oppositional, or at least have it happen a lot less. This is not a pipe dream. I have seen it IN REAL LIFE. Nov 2, 2011 at 18:45


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.


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.

  • 4
    And if you don't implement it they have no job, either. I can't approve this view of the programmer as support for the sales people.
    – Agos
    Nov 2, 2011 at 13:34
  • @Agos : fair point. On the other hand, how likely are you to get hired somewhere else if you get fired for refusing to work? And how willing are most shops to just hire the next guy who will go on the death marches. Nov 2, 2011 at 17:38
  • If someone wants to take a death march job, or continue on in it, that is their problem. The company they work for will soon be left with only the people that CAN'T LEAVE, often because they don't have the skill and experience to take themselves elsewhere. Skilled developers are fewer and more far between than skilled salespeople. They deserve to be treated with at least as much deference. Nov 2, 2011 at 18:49

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.

  • 8
    But do show them what they can have in four weeks. Perhaps they can have all the screens with half the fields, or some such. Or three of the key five workflows. Ask which of those three you should work on. Make it "their" problem.
    – sdg
    Nov 1, 2011 at 15:12
  • 1
    Excellent point, Robert Martin talks a lot about being firm in estimates in Clean Coder, which provides the only reasonable antidote to unreasonable management. Always be eager to offer as much as you can, but never agree to a goal, or even to "do your best" to meet it, when it cannot be achieved in a reasonable fashion. It is your job to warn of constraints. You are the one that can see them. Nov 2, 2011 at 18:54

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.


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.

  • Why is it impossible to develop a reputation as a solid workhorse dev shop that delivers realistically instead of claiming to do magic? I mean, aren't there clients out there that aren't idiots and that actually understand the things we're talking about?
    – Rag
    Nov 2, 2011 at 1:54
  • I'm sure common sense is as common amongst dev shop clients as it is in the general population. I would say every client, whether they have sense or not, will notice the gap between what is promised and what is delivered - or at least the gap between what they expected and what was delivered. The sensible ones will keep coming back when that gap is small or non-existent. The rest will just buy the cheapest quote, like always.
    – Joel Brown
    Nov 2, 2011 at 12:41
  • 3
    "The very nature of sales is over-committing." Disagree. The nature of sales is to cast your products and services in the best possible light, sell them at every available opportunity, and to create more opportunities. A history of delivering on time and under budget could be a massive advantage in all of these situations. Even if an external facing estimate of development effort has to be trimmed down from the actual technical estimates done in-house in order to make a strategic sale, that should not be an excuse for imposing them internally upon developers. That is unprofessional. Nov 2, 2011 at 19:45

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.



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


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.


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.


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.


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.

  • they'll just increase the work package per "point" (but not the duration of each "point" in an iteration) to the point where it fits the scope and budget/timeline they can sell.
    – jwenting
    Nov 4, 2011 at 8:19
  • Points per story are assigned by the developers not the Sales or Business team. Nov 4, 2011 at 13: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.

  • Ahh, but the salespeople are skilled in the art of negotiation and engineers are not. That's why they're in sales and we're in engineering! In my experience, most technical people just nod their head (it doesn't help that estimates are susceptible to anchoring bias). It's really difficult for technical people to say it'll take longer than someone thinks because they know it can easily be turned into a reflection on their ability. "You think it'll take two weeks? Joe said he can do it in a little over one." Nov 2, 2011 at 1:29
  • 1
    If Joe says he can do it in a little over one week, then Joe gets to suffer through the job. If Joe fails, sales will learn to pad his estimates. If Joe manages to succeed, likely not wanting to spend another 80-hour week ever again, he'll adjust his own estimates. If neither of these happen, Joe will be fired for failing to meet his commitments one too many times, or will burn out and quit from overwork. If you're confident that Joe is overselling, then call the bluff. Just don't be Joe; it is not worth it (ok, ok, VERY RARELY worth it).
    – KeithS
    Nov 2, 2011 at 14:45
  • The entire point of the Agile estimation is that the price is right and the pace is sustainable. Those are things that have value to a client; knowing how much it will REALLY cost, and how long it will REALLY take, and that they will get what they asked for for that price and that amount of time, is worth far more than a promise of "we'll beat any price".
    – KeithS
    Nov 2, 2011 at 14:53

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.

  • Fast and Cheap?
    – IAdapter
    Nov 2, 2011 at 21:15
  • then it wont me good.
    – jim
    Nov 3, 2011 at 16:25
  • i think they don't care about it being good, but just to sell it.
    – IAdapter
    Nov 3, 2011 at 19:45
  • as long as they know that...so be it.
    – jim
    Nov 3, 2011 at 20:07
  • 2
    they care about it being good, they'll just blame you for the project failing when the customer isn't happy...
    – jwenting
    Nov 4, 2011 at 8: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.


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!

Not the answer you're looking for? Browse other questions tagged or ask your own question.