123

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.

gnat
  • 21,442
  • 29
  • 112
  • 288
Shawn D.
  • 1,361
  • 1
  • 12
  • 14
  • 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. –  Nov 01 '11 at 15:00
  • 2
    Maybe the company should employ more developers? :-) – Giorgio Nov 01 '11 at 15:58
  • 4
    @Giorgio haha good one :) – ell Nov 01 '11 at 16:25
  • 1
    @Giorgio: more chefs in the kitchen doesn't necessarily make dinner come quicker. It depends on the product... but either way, definitely not at the end of a release cycle. – Roy Tinker Nov 01 '11 at 17:18
  • @OrbWeaver, point taken, but ultimately unless I'm gone shortly after, when customer issues come in with the half-finished software that was released, I'm on the hook to fix it. – Shawn D. Nov 01 '11 at 17:18
  • 3
    @ShawnD. For the Horde! – Kalamane Nov 01 '11 at 17:25
  • @Roy Tinker: Not necessarily, but if there is more work to be done you need more people, as simple as that. We are just experiencing this in my project at the moment: we went from 3 to 7 developers because the deadline is fixed and we realized we need more man power to deliver on time. The developers are hired from other teams that are less loaded at the moment. This is what I would call good planning and good management. – Giorgio Nov 01 '11 at 17:56
  • 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 01 '11 at 17:58
  • Is the company Adobe? – Chris S Nov 01 '11 at 21:52
  • @Giorgio: More people on a project means exponentially more communication that needs to happen between people, especially if you have the same people working on the same area of the project. Like I said, it depends on the project. Some projects have very distinct portions that can be worked on in isolation. – Roy Tinker Nov 01 '11 at 22:02
  • @ChrisS, No it's not Adobe, but from talking with a few of my friends it sounds like it could be . – Shawn D. Nov 02 '11 at 16:49
  • 1
    Don't believe it. There are companies that treat developers well. – PeterAllenWebb Nov 02 '11 at 18:32
  • 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. – Michael Brown Nov 03 '11 at 02:59

21 Answers21

147

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.

Malfist
  • 3,641
  • 5
  • 29
  • 40
  • 60
    +1 for standing up for yourself. Developers allowing themselves to be walked all over is exactly what allows such sweatshop cultures to persist. –  Nov 01 '11 at 15:04
  • Where does Shawn say he is doing overtime? – sbi Nov 01 '11 at 15:04
  • @sbi, in the Q: "... but doing 80 hour weeks for months at a time just vindicates the arbitrarily set release date" – Dan McGrath Nov 01 '11 at 15:07
  • @DanMcGrath: Ouch. I missed that. `+1` from me for this answer, then. – sbi Nov 01 '11 at 15:08
  • 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 01 '11 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. – FrustratedWithFormsDesigner Nov 01 '11 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 01 '11 at 16:01
  • 2
    @FrustratedWithFormsDesigner: that is true, and you certainly need to be aware of the fact that you might be viewed unfavourably for refusing to submit. However, in the long run it is probably better to lose your job than die from a heart attack or throw yourself under a train because you can't take it any more. –  Nov 01 '11 at 16:12
  • @FrustratedWithFormsDesigner - That's so true. And probably a good thing. Would you really WANT to be a player on a team that operates like that? – Dan Ray Nov 01 '11 at 16:53
  • 2
    @maple_shaft: Good points except that it's not always possible to have another job lined up in less than 3 months. Sometimes the local economy stinks and travel to distant places where things are better is unfeasable (moving can be necessary but can also be expensive). Sometimes there's debt that needs to be paid. Sometimes you need to work with an unfavourable situation *until* you have another employment contract inked elsewhere. – FrustratedWithFormsDesigner Nov 01 '11 at 17:59
  • @DanRay: Yes, I'd rather want to be a member of a team that mostly did the hours written in their contract, and viewed anything above that as an exception. In fact, I have quickly left every company that lured me in believing they would operate that way, but then revealed their true face. – sbi Nov 01 '11 at 21:32
  • 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 01 '11 at 23:11
  • 1
    @OrbWeaver: that's what unions are for, i.e. avoiding sweatshops, but unfortunately there's no Coders Union that I know of ;-) – dodgy_coder Nov 02 '11 at 08:45
  • 3
    _No job is **ever** worth working yourself to death over._ Repeat that to yourself. If your employer doesn't agree, it's time to leave because you can be sure they won't work themselves to death for you. (If you're self-employed then remember you've got to be alive to enjoy the fruits of success.) – Donal Fellows Nov 02 '11 at 10:49
  • 1
    I did this and eventually it got me fired. I agree with you 100% but most places that employ developers see them just as a screwdriver, a tool in their hand that they'll replace whenever they need to. It's a real problem. – stef Nov 02 '11 at 12:33
  • Or ask for double the salary. – RyanTM Nov 02 '11 at 14:15
  • I don't think you should beat around the bush. Being forced into 80 hour weeks is not reasonable. If your team is truly working such hours, it IS taking a visible toll on them and their personal relationships, and I don't have to be there to know it. Insist on a retrospective meeting after a big push. Confront management with the external costs they are imposing on their team, and ask them what they are doing to ensure it does not happen again. If they don't have any answer, be prepared with your own. If it is at all practical, quit if they do not listen or do any better next time. – PeterAllenWebb Nov 02 '11 at 18:30
  • While I like this answer, I have to protest its passive-aggressiveness. Find the salesperson responsible and have it out with him. Keep it responsible, but make your point clear and unavoidably direct. Make sure he knows that the next time this happens the conversation will have an audience. – kojiro Nov 03 '11 at 13:38
  • Sometimes bad shit needs to happen before change is considered. So in that sense organizational dynamics are like a feedback loop from control theory. I also would add that this problem is an indication of a missing role in the development team and a weak process. Backing into dates without having a technical grasp on the project never works. What does work is allowing a lead to estimate a date based on a specific feature set that is frozen in the sense that any change after agreement means a non negotiable schedule change. I would push for better development leadership if I were you. – sbrenton Nov 05 '11 at 17:44
96

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.

sbi
  • 9,992
  • 6
  • 37
  • 56
  • 1
    Make sure you learn the difference between an estimation and a commitment: http://blog.mountaingoatsoftware.com/separate-estimating-from-committing It sounds like they don't care about either, but once they do knowing the difference is useful. – StuperUser Nov 01 '11 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. –  Nov 01 '11 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 01 '11 at 19:29
  • @MarkBooth: I was talking of _all_ projects. And, yes, it does teach. BTDT. – sbi Nov 01 '11 at 21:30
  • Then again it's almost impossible to estimate accurately if you don't have all the specs, which is a situation just as common as sales determining deadlines. – stef Nov 02 '11 at 12:35
  • 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". – PeterAllenWebb Nov 02 '11 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 03 '11 at 12:40
  • 1
    @MSalters - I love the phrase *any idiot can sell below cost* - it's **so true**. So many times I've seen customers promised the earth, based on threadbare profit margins and non-existent contingencies, only to find a series of small problems push the project late, over-budget and into being unprofitable. – Mark Booth Nov 03 '11 at 13:23
  • in my experience with companies that have this problem, the failure of such projects where the estimates are set way too low because of pressure from marketing or (non-project) management is never blamed on the responsible parties. The developers are blamed for any failure, the marketing/management people are credited with any success. – jwenting Nov 04 '11 at 08:00
  • 1
    @jwenting: But if someone knowledgeable in a field lets parties not knowledgeable in this field talk him into making wrong estimation, based on arguments that have nothing to do with said field, isn't that indeed the fault of that someone? – sbi Nov 04 '11 at 08:42
  • 1
    sure. The estimates however are made by either sales or management and handed down to developers as a fait accomplit, they have no influence over them, yet are blamed for not delivering according to them. – jwenting Nov 04 '11 at 10:31
  • @jwenting: I already addressed this right at the beginning of my answer: "Make an ___estimation___ yourself before you start and ___show it___ to them." – sbi Nov 04 '11 at 10:35
  • @sbi just clarifying who makes such estimates. See my other responses as to how your estimates are often ignored completely, and you're later judged by their estimates. – jwenting Nov 04 '11 at 10:47
  • Start looking for another job now as well. It doesn't sound like a great place to work, and if you get offers, you will be in a much stronger position to educate them. – B Seven Feb 20 '12 at 18:17
52

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.

Chris B. Behrens
  • 461
  • 3
  • 6
  • 46
    +1 if the programmers' overtime is being used to close a sale, then they should receive a portion of the commission. – Gilbert Le Blanc Nov 01 '11 at 16:11
  • 12
    This would encourage the developers to release untested crap. – quant_dev Nov 01 '11 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 01 '11 at 16:55
  • 8
    @quant_dev - every situation encourages developers to release untested crap - except testing. That's a separate question. – Chris B. Behrens Nov 01 '11 at 17:07
  • 1
    @ChrisB.Behrens Yes, but sharing the commission increase the incentive considerably. – quant_dev Nov 01 '11 at 17:08
  • 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 01 '11 at 18:09
  • 3
    Maybe it's because I'm still young and naive but I wouldn't be quite so quick to blame it on salesperson greed. If management doesn't care about programmers how much less do you think they care about salespeople? Salespeople don't even really have the in-depth technical knowledge of the product that costs thousands of dollars to replace in a new programmer hire- they're replaceable. The boss could demand a sale a week or they're fired, and they can't close a deal by working extra hours. If a salesperson throws themselves under the bus for the sake of the developers, another will take his place – Rag Nov 02 '11 at 02:35
  • 2
    @robertc Unfortunately, the pecuniary cost of overtime from salaried employees (at least in the United States) is usually zero. The very real but non-pecuniary costs--ruined marriages, children whose parents are absent, burnout, turnover--are difficult to put on an accounting ledger, so they are often ignored. Vote with your feet. There ARE places that don't treat their developers like this. – PeterAllenWebb Nov 02 '11 at 18:20
  • @PeterAllenWebb - well said. I think the key is for people to learn that death marches are simply bad for business in the intermediate run. Months, not years. If a planner is not accounting for the cost of turnover in a development team, he's not planning. – Chris B. Behrens Nov 02 '11 at 21:19
  • @BrianGordon in organisations like this, sales are ALL that counts. They're counted as where the income is created, developers and helpdesk are only spending money... Worst case scenario I've encountered in such a company we got told that we were NOT a "product provider" but a "service provider", despite our main source of income being the sale of 2 commercial software products were created ourselves, and everything else being training and hardware (maintenance, servicing) related to those 2 products. – jwenting Nov 04 '11 at 08:04
26

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

RichardM
  • 584
  • 3
  • 9
  • 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 01 '11 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? – FrustratedWithFormsDesigner Nov 01 '11 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 01 '11 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. – dodgy_coder Nov 02 '11 at 08: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 02 '11 at 12:10
  • So developers must seize the means of production to recapture the surplus value of their labor? :P – PeterAllenWebb Nov 02 '11 at 18:24
  • case in point: I've had a lead give off an estimate of 500 hours to sales, countersigned by the CEO as reasonable. Sales sold the project for 200 hours. We implemented it in 400 hours (so below our estimate). Sales got a commendation for closing the deal, we developers got blamed for not meeting the deadline (by the CEO, when we'd delivered below the estimate he'd originally approved in person). – jwenting Nov 04 '11 at 08:07
21

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.

maple_shaft
  • 26,401
  • 11
  • 57
  • 131
  • 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 01 '11 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 01 '11 at 16:05
  • 2
    What's with 45hrs? Didn't you sing a 40hrs contract?? – sbi Nov 01 '11 at 17:30
  • @sbi I can't find the link to it anymore but it was a study that found a dramatic increase in stress related conditions and dramatic decrease in productivity rates after 45 hrs/wk. I was referring to the number in the study. – maple_shaft Nov 01 '11 at 17:48
  • @maple_shaft: Ah, I see. Well, I think the way you say this is misleading though. (And I'm sure you didn't _sing_ your contract. What a wonderful Freudian slip!) – sbi Nov 01 '11 at 17:58
  • 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. – Matthew Scouten Nov 01 '11 at 19:21
  • @Matthew: TBH, I'm at a loss as to what to reply to that. – sbi Nov 01 '11 at 21:29
  • 3
    @MatthewScouten how many languages do you speak? – jim Nov 01 '11 at 22:58
  • 1
    @Matthew: Provided the idiot who came up with that idea had to sit through the performance, your singing voice would have been more than adequate punishment. :-) – Donal Fellows Nov 02 '11 at 10:53
  • @jim: Just one. why? – Matthew Scouten Nov 02 '11 at 14:28
  • 2
    @MatthewScouten sbi speaks 3, I know you weren't trying to be insensitive, but you should try to take a little bit more care. – jim Nov 02 '11 at 15:47
  • 1
    It's true what you say about market forces, but it's not like any given company has the right to exist just on principle. If they cannot execute their business plan in a reasonable manner, *then maybe it is just a bad plan*. I tend to agree with the 45 hour limit. I have a great employer, and honestly do not mind working more than that on occasion, when I know it is a big help, but my understanding would wear thin after several weeks. And after several months, the problems would become theirs and not mine, because I would be gone. – PeterAllenWebb Nov 02 '11 at 19:04
  • @PeterAllenWebb If the only software companies were ones with a good idea and a good plan then there would certainly be far fewer of us employed. A business has a right to exist if people keep giving it money, they keep the creditors at bay, and they aren't breaking any laws. – maple_shaft Nov 02 '11 at 19:18
  • @sbl yes, your contract states 40 hours, but doing a bit more (say an hour a day) shows your willingness to go above and beyond your commitment, which is good for your review and career prospects. Doing much more than that (consistently) is bad for your health and just means they'll pile more and more work on you, making the problem even worse. – jwenting Nov 04 '11 at 08:09
  • 2
    @jim most mistypes are not funny, but the answer to this one was. I don't think there is anybody who thinks that "sing" was not a mistype. –  Feb 20 '12 at 17:55
11

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.

Jé Queue
  • 3,937
  • 2
  • 29
  • 37
  • 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"`. – FrustratedWithFormsDesigner Nov 01 '11 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. – dodgy_coder Nov 02 '11 at 08: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. – PeterAllenWebb Nov 02 '11 at 18:39
10

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.

Caleb
  • 38,959
  • 8
  • 94
  • 152
  • Can't do #4, you clearly know this. Sales are chasing 100x the prospects of any given active contract. – Jé Queue Nov 01 '11 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 01 '11 at 16:51
  • @Xepoch, I mostly agree. It's possible in a very small company where you've got just a few salespeople and a handful of developers, but then it's usually a matter of personal relationships. Occasionally a smart salesperson will do it on their own, usually because they want to make sure a task gets done, they want to make sure it's done right, and they want to send it to the customer as soon as it's ready. But you're right: I've not seen a manager mandate that the entire sales team stay just to teach them a lesson. One can dream... – Caleb Nov 01 '11 at 17:22
  • 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 02 '11 at 01:49
  • While the sentiment is great, this list is kind of a pipe dream. (p1) Most devs work on salary, good luck getting that changed. (p2) Sales guys work off commission, calculated from (gasp) "sales." Trying to figure out commission on PROFIT would be very hard and your sales force would rebel. What do you pay them until total "profit" is figured out? (p3) Insist that your devs won't work more than 40 hours and watch the outsourcing start. (p4) Require your sales guys to sit around an office on their butts for no reason? Do you even know how sales works? (p5) and (p6) are pretty reasonable though. – Graham Nov 02 '11 at 12:47
  • 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 02 '11 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. – PeterAllenWebb Nov 02 '11 at 18:45
  • re 1: works only when ot hours are still limited and occasional. Productivity per hour plummets when overtime becomes endemic and people get exhausted. In fact, it will inevitably lead to more people being on sickleave of forced retirement because of stress related illnesses, even suicides. – jwenting Nov 04 '11 at 08:11
  • @Graham re 1,2: our sales are salaried with an additional commission. Everyone (not just sales) gets a bonus based on profit on top of that. OT time is staggered rates, getting higher as the number of hours in a week goes up (and time and a half on weekends). Helps keep demand for overtime down as it directly affects the bottom line. – jwenting Nov 04 '11 at 08:14
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.

Nathan Long
  • 3,667
  • 3
  • 24
  • 28
  • I read a good book about this once called Never Work for a Jerk. I'm surprised it's out of print, but amazon still has used copies: http://www.amazon.com/gp/product/0880297484/?tag=resingnet-20 – Tom Resing Nov 02 '11 at 19:19
6

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.

Wyatt Barnett
  • 20,685
  • 50
  • 69
  • 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 02 '11 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. – Wyatt Barnett Nov 02 '11 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. – PeterAllenWebb Nov 02 '11 at 18:49
5

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.

MattBelanger
  • 658
  • 5
  • 8
  • 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 01 '11 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. – PeterAllenWebb Nov 02 '11 at 18:54
4

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.

pdr
  • 53,387
  • 14
  • 137
  • 224
3

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.

Joel Brown
  • 2,388
  • 1
  • 19
  • 17
  • 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 02 '11 at 01: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 02 '11 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. – PeterAllenWebb Nov 02 '11 at 19:45
2

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.

Dan McGrath
  • 11,163
  • 6
  • 55
  • 81
2

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.

authentictech
  • 101
  • 4
2

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.

brmore
  • 119
  • 2
2

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.

JOG
  • 181
  • 7
1

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.

SoylentGray
  • 3,043
  • 1
  • 23
  • 31
  • 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 04 '11 at 08:19
  • Points per story are assigned by the developers not the Sales or Business team. – SoylentGray Nov 04 '11 at 13:18
1

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.

KeithS
  • 21,994
  • 6
  • 52
  • 79
  • 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](http://www.cs.toronto.edu/~sme/papers/2005/ESEC-FSE-05-Aranda.pdf)). 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." – Scott Whitlock Nov 02 '11 at 01: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 02 '11 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 02 '11 at 14:53
1

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.

jim
  • 280
  • 1
  • 7
-1

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.

Aaronaught
  • 44,005
  • 10
  • 92
  • 126
-1

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!

Tom Resing
  • 191
  • 1
  • 4