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?

ChrisF
  • 38,878
  • 11
  • 125
  • 168
Odys
  • 559
  • 4
  • 11
  • 1
    Mind saying the downvote reasons? – Odys Apr 27 '12 at 09:43
  • 2
    +1. I don't see this as a question worthy of a downvote. – Neil Apr 27 '12 at 09:51
  • _I know this behavior is stupid_ kind of makes me think that the answer to _how can I make them see the problem?_ would be you can't – gnat Apr 27 '12 at 10:35
  • 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 Apr 27 '12 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 Apr 27 '12 at 10:55
  • 8
    You need to apply the Scotty Principle: http://www.youtube.com/watch?v=ufkh1cKG8Dw – jfrankcarr Apr 27 '12 at 11:36
  • 11
    The marketing division will be the first up against the wall, when the revolution comes. – naught101 Apr 27 '12 at 13:45
  • 5
    @naught101 "Who let all this riff-raff into the room?" – maple_shaft Apr 27 '12 at 14:49
  • *"circles per week or per three days"* do you really mean *"circle"* or is it *"cycle"*? – Alex Jasmin May 03 '12 at 17:41
  • 4
    "Giving you a shorter estimate wouldn't make the project take less time, it would just garantee that it would be late." - Rapid Developement by Steve McConnell, page 230. – palacsint Jul 05 '13 at 17:11
  • see also: [How can I convince management to deal with technical debt?](http://programmers.stackexchange.com/questions/43948/how-can-i-convince-management-to-deal-with-technical-debt) – gnat Jul 17 '15 at 18:07
  • Can't believe there are so many answers and comments and no one posted this link: http://www.thomsettinternational.com/main/articles/hot/games.htm It's a long read but the section on [not] playing the games is what you're after. – pgraham May 02 '12 at 20:25

17 Answers17

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.

Phil
  • 3,660
  • 26
  • 29
  • 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 Apr 27 '12 at 14:06
  • Yes, sacrifice scope, see my Scrum answer below! – Christoffer Soop Apr 27 '12 at 14:42
  • 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 Apr 27 '12 at 16:41
  • "We need to respect and submit to those who are in authority"?! Are you kidding? That's how fascist regimes get away with committing all kinds of atrocities. What if those in authorities are fools, or worse, unethical scum? – naught101 Apr 28 '12 at 10:44
  • 6
    @naught101: be careful, you're close to the Godwin point ;) – Clement Herreman Apr 28 '12 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 Apr 28 '12 at 19:13
  • @ClementHerreman I know, I know. TecBrat: right, I was pointing out that the generalisation is a bad one, especially because it seems it's quite often the case that those in authority don't have enough information/intelligence to make good decisions. – naught101 Apr 29 '12 at 00:17
  • 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 May 01 '12 at 19:01
  • @Phil:I would probably put it the other way around, submission is OK *sometimes*, but critical thinking and nuanced decision making, and the willingness to subvert authority if necessary are *always* required. But I think that the threshold of deciding when to sumbit or not is a fairly personal thing, and we could agree to disagree on where that is :) – naught101 May 02 '12 at 00:06
  • I don't negotiate my estimates! Lets discuss priorities so we can look at what features you really need, quality and resource allocations to make sure we come up with something that is realistic that we can all work with and commit to. – mattnz May 02 '12 at 22:00
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.

Pieter B
  • 12,867
  • 1
  • 40
  • 65
  • 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 Apr 27 '12 at 11:20
  • 36
    The answer is good. Programmers don't like playing such games, but that's how the world works. – quant_dev Apr 27 '12 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 Apr 27 '12 at 12:10
  • This is an interesting viewpoint. On the one hand, we need to adapt to other peoples' mindset if we are to work with them. On the other hand, I've never thought the negotiation game was very ethical in the first place with the lack of transparency and honesty. – Phil Apr 27 '12 at 13:35
  • 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 Apr 27 '12 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 Apr 27 '12 at 13:51
  • I agree that "playing the game" is how the world works, but the sales people that play this particular game on a daily basis are probably going to be far better at it than a developer/manager. So I think that MarkJ's comment makes sense - tell them it's not a negotiation. That way you're not in a position where you're forced to compromise on something important because the negotiations went poorly. – Bob Mc Apr 27 '12 at 14:02
  • 1
    +1 Better still, give an estimate that *after negotiation* still allows you an extra 50% leeway - since schedules always slip. (And you'll be a hero if your team comes in ahead of schedule.) –  Apr 27 '12 at 14:11
  • 1
    It's also reasonable to give a generous initial estimate due to [Hofstadter's law](http://en.wikipedia.org/wiki/Hofstadter's_law): It always takes longer than you expect, even when you take into account Hofstdter's Law. If you finish early, great, there's always the next project/feature. If you finish late, you will have untold levels of stress and misery. – dr jimbob Apr 27 '12 at 14:28
  • 4
    @MarkJ - "Salesmen and supervisors are natural negotiators, developers aren't." So, we should just roll over, allow them to pad their requirements, time estimates, and deliverables—i.e., lie—while we play a completely different game (i.e. not lying)? If anything, this answer simply reinforces that programmers need to know not only how to program, but also how to play bureaucratic games just as well as any other member of the company. Anything else and you're just playing a different game. – eykanal Apr 27 '12 at 15:05
  • 5
    @eykanal If you want to sacrifice your integrity to "play the game," go ahead. You'll do well in a beaurocracy. There are some who would rather fail in the big business world than to sacrifice their ethical standards. I'd rather work at McDonalds than be forced to lie to my boss. – Phil Apr 27 '12 at 15:11
  • 3
    @eykanal - I didn't get the impression from MarkJ that he was suggesting we "roll over" based on pressure from the salesmen. On the contrary, he indicated in his first comment that we should "tell them its not a negotiation". That sounds like a pretty firm and principled stance to me - hardly "rolling over". Your point about programmers learning to play the bureaucratic game is well taken, however. It's a skill that more of us should take the time to master. But it's a shame that it has to be done that way. Isn't a principled stance by *someone* a good way to start turning the process around? – Bob Mc Apr 27 '12 at 15:12
  • 6
    @Phil - Do people who bluff in poker "sacrifice their integrity"? No, it's the rules of the game. You can call a poker player a "liar", but many would disagree with your use of the word. Bureaucracy has it's own rules, and padding estimate is part of the game. You can call it "lying", but many would disagree with your use of the word. – eykanal Apr 27 '12 at 15:15
  • 2
    @eykanal Point taken. I just don't think of it as a game, I suppose. Poker doesn't matter in the end (it's a game), but the way you relate to your coworkers and boss is very important. – Phil Apr 27 '12 at 15:20
  • 2
    Please take the conversation to chat if you would like to discuss further. – maple_shaft Apr 27 '12 at 16:05
  • Some comments cleared. Stop ignoring the above comment, take any further discussion into chat. – yannis Apr 28 '12 at 06:29
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".

Nikolay Fominyh
  • 1,038
  • 9
  • 17
  • 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 Apr 27 '12 at 09: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 Apr 27 '12 at 14:02
  • 1
    But do you really want software testing outsourced? – user253751 Aug 07 '14 at 09: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.

gnat
  • 21,442
  • 29
  • 112
  • 288
Jaydee
  • 2,667
  • 1
  • 18
  • 17
  • 6
    Unfortunately, they'll then accuse you of gaming the result. – CaffGeek Apr 27 '12 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 Apr 27 '12 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.

tzerb
  • 563
  • 4
  • 15
  • 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 Apr 28 '12 at 08:54
  • 2
    I've been doing it for 20 years and it's worked out pretty well. :-D – tzerb Apr 28 '12 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.

MSalters
  • 8,692
  • 1
  • 20
  • 32
  • 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 Apr 27 '12 at 13:43
  • 1
    Time you need: Meet requirements. Time you want: Meet customer expectations. – MSalters Apr 27 '12 at 14:48
  • Customer requirements? – naught101 Apr 27 '12 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 Apr 27 '12 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.

Christoffer Soop
  • 161
  • 4
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.

ozz
  • 8,322
  • 2
  • 29
  • 62
  • 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 Apr 27 '12 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 Apr 27 '12 at 12:28
  • @maple_shaft I totally agree – ozz Apr 27 '12 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 Apr 27 '12 at 12:51
  • 6
    @Pap And if engineering can't deliver what sales promised, sales would be out of a job too. – Andy Apr 27 '12 at 12:52
  • Pap's right. And as for customers trying to get the best price, *that's their job*. What did you expect? – MarkJ Apr 27 '12 at 14:06
  • @MarkJ - I don't have a problem with that at all. It was clearly a tongue in cheek remark. The point is, sales guys cause all sorts of trouble when they promise the world without asking the techies. So I guess in summary, this issue will always arise, and it's about trying to minimise the impact. – ozz Apr 27 '12 at 14:21
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.

robertc
  • 191
  • 1
  • 6
  • 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 Apr 27 '12 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 Apr 27 '12 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.

Matt Wilko
  • 372
  • 1
  • 8
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.

NWS
  • 1,319
  • 8
  • 17
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.

psr
  • 12,846
  • 5
  • 39
  • 67
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.

Edwin Buck
  • 489
  • 3
  • 7
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.

user52889
  • 1,683
  • 11
  • 13
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.

Bill Leeper
  • 4,113
  • 15
  • 20
  • 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. May 02 '12 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 May 07 '12 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.

Morgan T.
  • 101
  • 2
-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".

José Ricardo
  • 226
  • 1
  • 4