64

We are in a small company with around 10 developers. I am the team leader and responsible for the development process.

Supervisors and salesmen are close to us since we are a small team, but have no clue on how software is developed.

When they ask me how much time I want for a change (bugfixes/features) in a product, my response is 'let me calculate it'. After giving them the schedule, they start by saying OK you can do it in XX time which differs a lot from my plan. We are using a model close to Agile basic principles and have circles per week or per three days.

Of course I argue and say that this cannot be done. They seem to have no idea on the effort we are doing. They do not want to see WHY my schedule is for that amount of time.

I know this behavior is stupid, but how can I make them see the problem?

12
  • 4
    I'm not the downvoter but I think it is because you said "their fault". Some people react like Pavlovian dogs when confronted with "bad" words.
    – ThomasX
    Commented Apr 27, 2012 at 10:48
  • 102
    Ask them how long it will take them to sell 100 licenses. Then tell them, no, that doesn't fit into your plan.
    – Bryan Oakley
    Commented Apr 27, 2012 at 10:55
  • 8
    You need to apply the Scotty Principle: youtube.com/watch?v=ufkh1cKG8Dw
    – jfrankcarr
    Commented Apr 27, 2012 at 11:36
  • 11
    The marketing division will be the first up against the wall, when the revolution comes.
    – naught101
    Commented Apr 27, 2012 at 13:45
  • 5
    @naught101 "Who let all this riff-raff into the room?"
    – maple_shaft ♦
    Commented Apr 27, 2012 at 14:49

17 Answers 17

Reset to default
65

If the salesmen are also the ones who are in charge, you can say, "Ok, I can go with your schedule. Which features or responsibilities would you like me to sacrifice in order to make your deadline?" That way you're not saying "no" to the people in charge but you're not committing to impossible things. The decision is in their hands how to run the business. If they want to axe other things to make time for the changes, let them.

EDIT: We need to respect and submit to those who are in authority, while still doing our jobs with excellence. The only way to do this is with humility. I'll work on whatever my boss wants me to work on, but I can only do so much. When you tell him like it is with an attitude of submission, he is in a better position to make better decisions and he'll want more employees like you.

Make sure these things are documented too in order to explain why the commitments are unreasonable and how the situation was resolved. It can help coworkers deal with similar situations in the future.

10
  • 6
    +1 love it! I have often employed this technique even on internal projects, it pushes the responsibility right back on them. Great fun to watch them bluster "um, all of it".
    – ozz
    Commented Apr 27, 2012 at 14:06
  • 3
    @ozz exactly: that's when you learn whether they're serious (in which case they start naming things you can cut totally or deliver later) or whether they just think you developers are slacking or over-engineering (make sure you can demonstrate that's not true)
    – MarkJ
    Commented Apr 27, 2012 at 16:41
  • 6
    @naught101: be careful, you're close to the Godwin point ;)
    – Clement Herreman
    Commented Apr 28, 2012 at 19:12
  • 2
    @naughty If those for whom you work are unetical scum, it's time to do a job search! If they are fools, It may be time to do a job search too, but obviously for a differnt reason.
    – TecBrat
    Commented Apr 28, 2012 at 19:13
  • 5
    @naught101 I did make a little broad of a generalization. There are times when submission is the wrong thing to do. But as long as your boss isn't asking you to be evil, submission to authority is usually a Good Thing despite what our culture may say. And there are usually better alternatives to pursue before you have to say "no".
    – Phil
    Commented May 1, 2012 at 19:01
49

In my experience Sales people think that everything is a negotiation where you meet eachother somewhere in the middle. That's basically how they work. They try to sell a product to a client and ask high, the client offers low and in the end a price both parties agree on becomes the agreement.

They also take this mentality to the workfloor. They assume you're asking for too many hours so they will try to argue off some of the hours, just as in a negotiation.

Giving exact estimates, has only given me headaches.

What you can do is play along: give a higher estimate where they can shave off some during "negotiation" and in the end, end up with the hours it really costs you to do.

16
  • 116
    This answer starts well then ends badly. Don't play games. Tell them its not a negotiation: unless its possible to trade off features to reduce cost
    – MarkJ
    Commented Apr 27, 2012 at 11:20
  • 36
    The answer is good. Programmers don't like playing such games, but that's how the world works.
    – quant_dev
    Commented Apr 27, 2012 at 11:40
  • 15
    +1. Abhorrent as it is, you have to know your players to play the game. If your client/boss is an engineer or a numbers cruncher, they'll view figures as absolutes and expect estimates to be accurate. If your client/boss is a sales-person, they expect a negotiation. Of course, you don't have to accept it. You can always try t change your boss/client but I don't predict a good outcome.
    – pap
    Commented Apr 27, 2012 at 12:10
  • 6
    You could always tell them that if they think your estimates are negotiable, you'll happily increase them by some unspecified factor, so that there's some bargaining room. That way you're letting them play their game, but not being forced to be deceitful...
    – naught101
    Commented Apr 27, 2012 at 13:37
  • 55
    Seriously, don't do this. Apart from anything else, its doomed to failure. Salesmen and supervisors are natural negotiators, developers aren't. You will lose the negotiations anyway, and the salesmen & supervisors will be even more convinced that you're a bad team player, padding your estimates & lying to them. They'll even be right! You could get all development work oursourced this way. Instead try to present them with some options to reduce timescales, like dropping features or incurring technical debt. Thats virtuous negotiation.
    – MarkJ
    Commented Apr 27, 2012 at 13:51
26

Do not show them their fault!

Try to argue better what changes you make, give them more detailed estimates. Make a suggestion like "We can do this in your X hours instead of mine Y hours, if we will give software testing to outsource". Or "We can do this faster, if we exclude this part of requested functionality".

3
  • 5
    +1. I agree. You want to feel better, blame them. Otherwise, if you want something to change for the better, you need to charm them a little. Helps to make them think it was their idea.
    – Neil
    Commented Apr 27, 2012 at 9:53
  • +1. The healthy attitude is for the whole team to work together to the company's goals. Mentioning outsourcing is bold (considering you yourself are outsourceable!). Its good though. It shows you are thinking hard to try to save time & money.
    – MarkJ
    Commented Apr 27, 2012 at 14:02
  • 1
    But do you really want software testing outsourced?
    – user20574
    Commented Aug 7, 2014 at 9:27
21

"After giving them the schedule, they start by saying OK you can do it in XX time which differs a lot from my plan." First of all ask them how they calculated their XX time.

Suggest to them that a record is made of your estimate and their estimate. Then you can compare the actual against the predictions and see who is more accurate.

2
  • 6
    Unfortunately, they'll then accuse you of gaming the result.
    – CaffGeek
    Commented Apr 27, 2012 at 13:33
  • 1
    There is that possibility, but then they can say you are gaming the system buy over specifying your estiamted time. They would need to justify their reason for claiming that you have gamed the result and also justify their own estimate of time. Otherwise they leave themselves open to simply looking incompetent. Another benefit of doing this is that if used honestly, you can improve your time estimates for the whole team.
    – Jaydee
    Commented Apr 27, 2012 at 13:43
19

Say "I stand by my estimate." And then of course hit your estimate. When it happens three times, they'll probably trust you.

2
  • 3
    Or they may have fired you by the time you "defy" them for the third time. While your estimate may be correct, getting a reputation for being stubborn may cause further friction down the line.
    – Burhan Ali
    Commented Apr 28, 2012 at 8:54
  • 2
    I've been doing it for 20 years and it's worked out pretty well. :-D
    – tzerb
    Commented Apr 28, 2012 at 14:40
16

"When they ask me how much time I want for a change"

At that point stop them. It's not how much time you want. It's how much time you need. If they insist, give them both the time you want and the minimum you need.

It may also help to keep a very visible measure of incurred technical debt due to all the shortcuts forced upon you by Sales. Nikolay is widely optimistic that you can influence Sales by talk, when their current behavior gets them bonuses.

In fact, if Sales is really driven by such incentives, then you should take that into account when formulating your response. "Feature not committed by Engineering" is a perfectly valid reason to drop a Sales request.

4
  • 1
    What do you do with the time that you want, but don't need? Spit and polish? Make coffee? Probably better to say "I can do a functional, but ugly job in 2 weeks. I can make it enjoyable to use 3. I can make it sing in 4, if you give me an extra designer for a week. You choose"
    – naught101
    Commented Apr 27, 2012 at 13:43
  • 1
    Time you need: Meet requirements. Time you want: Meet customer expectations.
    – MSalters
    Commented Apr 27, 2012 at 14:48
  • Customer requirements?
    – naught101
    Commented Apr 27, 2012 at 15:11
  • 1
    @naught101 - customer's requirements do not exist, only a customer's expectations, and how they require their expectations to work.
    – Ramhound
    Commented Apr 27, 2012 at 15:54
7

To get away from their preoccupation with hours, change the game. Instead of estimating time, estimate complexity in relation to some given usecase that forms a baseline.

You mention that you have something of an Agile approach, why not try Scrum?

In other words do short Sprints, tell them that "yes in one week I will be able to develop three of your five features" then make sure you deliver on those three features. Have them prioritize the changes/features/bugs and work strictly in that order. (Of course there is more.)

Teach them about the iron triangle of time, cost, quality and scope. You fix three and the fourth is the triangle area and thus a function of the others. I would guess that it is probably more important in the end when you are delivering, how much it costs and hopefully that you deliver with quality than exactly what you are delivering.

6

This is a huge bugbear of mine for sales/consultancy led projects and it's a tough situation. This is often an issue of how the company operates.

It is a classic case of the tail trying to wag the dog , sales guys doing whatever they can to close the sale, promising the world in features, and guaranteeing a ludicrous timescale, software development process and everything/one else be damned.

Either they will listen to you or they won't, it is not necessarily a fact they do not understand, more likely, they know fine well, but all they care about is closing the sale, getting the business and worry about deadlines later.

That being said, customers can be a pain in the backside, they want things done cheaply, and they want to know when it will be done. And they want a discount to boot.

One way to mitigate this is to have a tech guy involved in the sales meetings. Now this is not necessarily feasible in every company, but may be the only way to at least try and reign in the sales guys.

7
  • 2
    Any convincing liar can close a sale by promising the world, but then that isn't a sustainable business model because company decisions based entirely on closing the deal are focused on revenue and not concerning themselves with costs and liabilities. You could bring in tens of millions of dollars in revenue but if it results in project costs that are in reality double then you won't be in business very long. Sales led companies only succeed with exceptional sales people who understand when to walk away from a prospective client.
    – maple_shaft ♦
    Commented Apr 27, 2012 at 10:54
  • 4
    You do realize that if the sales-guys didn't close sales, there would be no need to build anything and we'd all be out of jobs? Who's the tail and who's the dog is not that clear.
    – pap
    Commented Apr 27, 2012 at 12:28
  • @maple_shaft I totally agree
    – ozz
    Commented Apr 27, 2012 at 12:48
  • 2
    @pap spoken like a true salesman! You are right to an extent of course. As mapleleaf says, if you have rubbish salesman who know nothing about tech estimating, your company will soon go out of business. By tail wagging the dog, I don't mind that the sales team bring in projects, but not that they have the final say in how long things take, which is what the OP was talking about.
    – ozz
    Commented Apr 27, 2012 at 12:51
  • 6
    @Pap And if engineering can't deliver what sales promised, sales would be out of a job too.
    – Andy
    Commented Apr 27, 2012 at 12:52
4

It might help to differentiate between how much time something will take and how much time will be charged. How much time something will take is a technical decision, they have no basis to disagree with you, be stubborn. How much the salespeople want to charge for that time is their decision and their responsibility to sell to the client.

Other than that the incentives need to be sorted out or you'll always be fighting an uphill battle. If sales bonuses are paid not on the outright value of the sale, but on the difference between the value of the sale and the cost of delivering it then they have an incentive to listen to you.

2
  • often times there is a cost per hour of work that is charged. If it will take 1,000 hours to finish, the only acceptable price is 1,000 * that price, anything before/beyond that range isn't the true cost of the project. You either pay less per hour for the same 1,000 hours of work, and lose money on the deal, or you spend to many hours on the project and overcharge. If you finish in 900 hours then the only acceptable decision would be to bill only 900 hours amount not 1,000 hours amount. Of course if your 900 hours is really 800, and it still cost you the 1,000 amount things can be fishy.
    – Ramhound
    Commented Apr 27, 2012 at 15:58
  • 1
    @Ramhound But this isn't about project based work, its about product based work. If a 50% discount on 15 hours of development will gain you a product sale to a value equivalent to 1500 hours of development then it's worth giving the discount and making the sale.
    – robertc
    Commented Apr 27, 2012 at 16:44
4

If they want to cut the schedule - ask them which features they want to be left out and the priority of those.

Then work on features in order of priority and tell them they can have they product whenever they like but it won't contain all the features they requested until the end date you specified initially.

2

If its a persistent problem, how about seconding a sales guy onto the development team for a week or two. Give them a book about the X programming language, and tell them to do it in their estimate. 99% of the time they will fail miserably, and be loath to question your estimates again. They might also get an idea of what it takes to do software development and realise they are not helping the process.

2

Make clear you are estimating the amount of time it will take, not promising you will get done in that time, and that getting you to lower the number is nothing more than talking you into lying to them. It won't actually magically make the software get done faster.

Ask them how much good it would do to talk a woman into lowering her estimate for her pregnancy from 9 months to 7 months.

Better yet, get a product manager. Salesmen will tie your product into knots chasing commissions, because they have little incentive to care about the overall product and every incentive to chase the current sale.

1

There are two issues, which need disentanbled.

  1. Stop quoting in time, start quoting in dollars. This quickly allows them to do a cost / benefit analysis, and allows you to add a standard "time to analyze" quote. Time is too sticky, because it doesn't reflect the real amount of work done (forty hours could be done in a day, five days, or three weeks), and it is far too easy to not push the budgeted release cycle back for such a request.

  2. Provide the sales staff a request input into the dev cycle (preferably a non-human interface, to save time (measured in money)).

Sales people tend to think in terms of (if I have X, I can close this sale). Their requests are often not coherent with the current architecture of the product, but they are coherent with the current need of a customer.

Indicate to the sales force that such requests are vital for your product, and as such, you need to not lose them in the "quick request, will take longer than the period of interest, drop the request, repeat" cycle. Such requests need to be captured, analyzed, prioritized, integrated into the product, tested, and released with the next release cycle.

Then back up your words with actions. Shorten the release cycle to under two months, indicate which items are going to be in the release, and hit your deadlines. Don't educate the sales staff about the internal reasons this is necessary, just do an analysis of what an out-of-cycle request minimally costs (in dollars), and what the risk (extra dollars and percentage of occurrence) it could cost if a problem exceeds minimal complexity. Then ask the sales person if the sale is large enough to support the out-of-cycle request.

Once they have a process for an in-cycle request, and they have an idea of how much it costs to handle an out-of-cycle request, odds are good that you can convert their out-of-cycle request into an in-cycle request, or determine that the out-of-cycle request is profitable enough to justify the expense.

1

Well, I'd hope that in order to commit to a piece of work, it's understood you and Sales need to agree meeting the requirements is worth the value.

Emphasise that unless you and Sales can agree, they can't make the sale and the job does not happen, so either you need to agree a counter-offer for the customer (smaller spec, longer timeframe, etc.), or else they need to find another customer.

There's no point signing a contract with a customer that you know you cannot fulfil, it will just end up taking up everyone's time and you risk losing the customer and others, and may not even get the money for the job.

0

If you feel your estimates are accurate and history reflects that use this.

When they say you have XX time, revise your estimate taking out features until it gets down to this time. Don't take out testing.

Then it is a negotiation about features and time, not just time, which history says you cannot change. If they insist on negating over time, start negoting bonuses for hitting said time (if you team is willing to work the overtime to get there). Say we can make the time you want, but it is going cost you a $1000 bonus to get there

Remind them that software development is like a factory and the factory is capable of producing X in Y amount of time. Goes to the bonus again, you can work overtime, but it is going to cost. Don't call it overtime either or they will just work you to death. It needs to be written down as well. X product by Y date for Z bonus. You might also insist on a day off afterwards since the team will be burned out after that. Also have in the contract that adding features or bug fixes over X% of normal time will add time to schedule.

You can't change the time, only take out features.

2
  • comparison of software development to a factory is scary. A factory has a template that delivers the exact same thing repeatedly. Programming is the opposite - you start with nearly a blank slate every time. I would stay away from this comparison as non-tech people might get the wrong impression
    – Morgan T.
    Commented May 2, 2012 at 19:58
  • 1
    The factory analogy is right out of the Agile concept. What you do is each developer rates how difficult they think a task is. You average that score (it's not hours, closer to t-shirt size etc.) and then assign to the task. Over time you track the number of points you actually accomplish in a cycle and that is your teams capacity. It has proven to be very successful for many teams. The agile concept evolved from the lean management concept that was originated by Toyota.
    – Bill Leeper
    Commented May 7, 2012 at 23:58
0

I've seen a lot of this negative, positional division in my career and I think the best way work with it is be as honest and transparent as possible. (Negative phrases like "behaviour is stupid", "have no clue", "cannot be done" should be avoided. Look for solutions/root causes.)

First, it looks like everyone is employing positional bargaining (book). They want what they want and you want what you want.But what is really driving that? Look at what drives their position and target that. E.g. sales just wants to get the product out as quickly as possible to make more sales and help the company's profits. What's wrong with that? And from your side you simply want to make the best quality software you can. So you just need to find a middle ground. I think the best way to do this is education, honesty and transparency. Treat them as part of your team and not "us vs. them".

Agile and Scrum methods try to incorporate this into the entire process. Certain aspects of Scrum take care of this nicely:

  1. A product owner that prioritizes features and chooses what goes in each sprint. This person is part of the team. This should be a person that has the clients' best intentions in mind. e.g. this could be a sales person or supervisor. They are involved on a regular basis in deciding what goes into the product so there's great motivation and responsibility (they'll learn to NOT push for time vs quality/features)
  2. Any stakeholders are team members as well, they just don't get control in the the backlog/sprints/timeline. Treat them as such and they can learn how estimates are calculated and the inherit complexity behind software development.
  3. A scrum master works at improving the process over time. It's not expected to be instantly scrum as that is unreasonable in any situation. They work at removing roadblocks for all team members (and the company).

In summary, just be honest, positive and try to educate - it will eventually improve. Even if you don't officially follow agile/scrum, read some literature to get a better understanding of these concepts and motivations.

-2

Another approach would be to make it impossible for them not to see WHY/HOW you're giving the estimates.

Since you are responsible for the development process, why don't you track the team velocity and show them, based on your past iterations, why you won't make their deadline? I think it is simple: "our current speed is X, and we have Y story points for this iteration".

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