I've been working as a team lead on a series of tight-deadline projects for a very high-profile client. I make sure going into each one that the scope of work is very clearly defined, with the client's help, to ensure my team doesn't get swamped by unexpected work while they're under pressure already.

Unfortunately my boss, the actual delivery manager for all projects under this client, has a habit of forcefully (and often) changing our priorities and inserting new deliverables that are outside our scope of work, his reason usually being as vague as "We have to have this" or "The client needs this now." After going through this several times I have noticed he is wrong every single time, and is sometimes even completely contradicting something the client stated directly about our timeline or expectations.

What's worse is when this work causes an actual deliverable to be late, he does not hesitate to throw my team under the bus in front of the client, and I can only imagine what sort of image that gives them of our company. Such confrontations have lead some team members to get burnt out and quit the project.

I've tried to diplomatically push back on these requests but the more I push, the more forceful he gets. Is there something I should be doing differently? Or is this manager just a lost cause?

Edit: To clarify, my whole team is client-facing to some extent (I personally deal with the client more often than the manager does, with regards to my projects) and are usually all present when the bus hits. Post-bus, the rest of the day (well into the evening) is usually filled with angry emails/calls/messages from the manager to seemingly random members of the team (rarely me directly, because I'm the only one who pushes back) regarding the status of whatever deliverable was delayed that I would easily classify as "badgering" to get it done.

closed as off-topic by gnat, mcknz, panoptical, Lilienthal, IDrinkandIKnowThings Nov 3 '15 at 22:55

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – gnat, mcknz, panoptical, Lilienthal, IDrinkandIKnowThings
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 6
    Have you given your manager the client-agreed-upon scope at the beginning of the sprint/project? Sending him an email, perhaps with a client rep included as a cc, specifically stating the agreed upon work, will work wonders. Then, when the manager adds to the scope, add that new deliverable to the end of the email you originally sent and makes sure you emphasize this is beyond the already agreed upon scope. – CGCampbell Nov 2 '15 at 18:29
  • 3
    The manager is actually the one who helps define the scope to begin with, and the state of all deliverables is discussed with him at least once per week (usually daily, he likes to micromanage). – thanby Nov 2 '15 at 18:31
  • 5
    So, whose the boss then? time you and he had a frank and constructive conversation. You're treading each others toes by the sounds of it. – Matt Nov 2 '15 at 19:41
  • 9
    The fox is guarding the hen house. Document scope changes and impact to cost / schedule and list your boss as source of the scope change. – paparazzo Nov 2 '15 at 19:43
  • 16
    Meticulously document all of this, then bring it up with the manager's manager. – Matthew Read Nov 2 '15 at 20:01

10 Answers 10


When your manager wants to reassign your priorities or wants to add scope to your project, clearly communicate to him the cost of this. You can do this like this:

"We might be able to add this feature, but we are already 1 month behind our project plan. Adding this feature would take an additional 3 months, so when you insist on that it is to be expected that the whole project will be 4 months late."

Your boss might try to haggle. Never fold to that. What some managers fail to understand is that time estimates are not a negotiable offer. They are a factual assessment of the situation and facts can not be discussed away. The only way to modify a time estimate is to modify the scope of the request.

There are three possible responses your boss can make to this:

  1. Decide that the feature is not worth the delay.
  2. Decide that the feature is important despite the delay and that the deadline needs to be extended to accommodate for it.
  3. Insist that the feature is necessary but that the project must also be completed within the original timespan.

When the latter happens, you need to make it clear to him that this is not possible to do. You can try your best to fulfill the request, but it is very likely that you will fail. Send these concerns in writing, so you have documentation that you warned him this would happen. Then try your best even though you know you will fail. After you failed, you have documentation that your failure was not because of you but because of a project planning failure from your boss.

  • 2
    very good advice +1 – Kilisi Nov 2 '15 at 19:11
  • 45
    +1 What some managers fail to understand is that time estimates are not a negotiable offer. They are a factual assessment of the situation and facts can not be discussed away. The only way to modify a time estimate is to modify the scope of the request. This is the story of my life. – grfrazee Nov 2 '15 at 21:26
  • 5
    @zespri The more I think about a time estimate for a programming task the higher it will usually get, because I become aware of more and more hidden complexities. – Philipp Nov 3 '15 at 2:28
  • 4
    @zespri that's why in Scrum, the team does time estimates together and the highest/lowest estimators discuss their point of view together. Perhaps there were hidden complexities that you didn't think of but it could also be that there is a better and far easier solution available than the one you thought up which can save a lot of time. The key takeaway from estimates is that it's exceedingly rare that something takes less time than the original estimate. Sure, it happens, but not frequently enough to justify negotiation on estimates. – Cronax Nov 3 '15 at 8:42
  • 3
    @zespri It's very rare for an estimate to be too high, unless your people don't trust you. A good manager knows that he needs to leave more time on top of the original estimates, not less. The truth is, people simply aren't pessimistic enough, even when they think they're considering the absolute worst case scenario. And more importantly, we're talking about negotiation here - that never works. There are ways for managers to lower estimates realistically - for example, by ensuring that the scope is properly understood, as well as the guarantees required. And, of course, reducing scope. – Luaan Nov 3 '15 at 9:40

I've dealt with very similar characters to your manager. My opinion and approach would be rather to push back on this (as you do not know what external influences are pressuring them to request the scope creep items) but document each one and the effect it has had on your ability to deliver. This will help you should you be 'thrown under the bus' at a later date.

Rather than push back, all you can do is make the manager aware of the effects of adding the additional functionality. If they are the project sponsor/client liaison, you have no control over them and their ability to amend the requirements. All you can do is be flexible and make people aware that time spent re-prioritising or re-engineering stuff to fit in the new items is time that could have been spent delivering other items.

This is far far FAR more frequent than you probably think.

If the requests are contradicting the client requests, you could set up a working group to review and sign off each request before it is considered accepted and ready to work on. If the client is party to this group, that is the stage at which these requests get flagged as not required. This does still require your time though

  • 18
    +1, I like this answer, but as far as throwing the team under the bus goes, all this documentation of issues should never be discussed with the client, it will make the company look bad. It should only ever be used internally. The boss is the one facing the client by the sounds of it, it's up to him how he justifies delays. – Kilisi Nov 2 '15 at 18:21
  • 1
    Absolutely agree @Kilisi . I missed the 'in front of the client' bit on the OP and my answer only caters for being thrown under the bus internally. – Mike Nov 2 '15 at 20:19
  • 3
    Make sure the client in the working group understands the impact on the timeline before they sign off. More than just required or not required, they need to understand they're making trade-offs and that work can be pushed off to a later date. – jpmc26 Nov 2 '15 at 21:27
  • 1
    'It should never be discussed with the client' I think that depends... if manager says "This project needs this", then isn't it due diligence to verify - with the client - the new plan? "Here is a list of previously signed off priorities... here is a requested changes, submitted on your behalf. Please verify, sign and return so we can move forward in our new direction (to: customer, manager, etc)". I think I would rather have some inter-office politics visible and products finished on time as the customer wants... instead of after-the-fact under-the-bus tossing and missed deadlines. – WernerCD Nov 3 '15 at 1:00
  • 3
    Yeah, that I'll agree with - depending. "internal CYA documentation" should be internal... but changes to priorities and adjustments to schedules should include customer consent and approval. Something that adjusts the schedule shouldn't be a last minute "Oh, we made changes... hope you don't mind" (since "we" is the company and the customer won't care if it's you or your manager) – WernerCD Nov 3 '15 at 14:48

When I've encountered this sort of scenario with someone who directly faces the client and provides conflicting information or tasks that will put an actual deadline in jeopardy, I always ask to see it in writing. Just as your organization has an individual responsible for interfacing with the client, they have someone responsible for interfacing with your company.

When a task such as this comes up, ask to see written approval from the client before deviating from an endangered task. Make sure the written approval states the risk, the knowledge of the risk and the importance of the deviation. Projects with deliverables often have rigid, pre-planned timelines that are agreed upon by all entities from the client down to the team doing the delivering. It should be trivial for this person to get the written approval if it is indeed necessary.

The wrinkle here is that this person is your boss. It could be that this person will give you an ultimatum eventually. There are a large number of options available, but each has a consequence that you have to be able to live with when everything has run its course. As with any situation, I recommend you handle it at the very lowest possible level.

  1. Have a private, very direct conversation with your boss indicating that this behavior is contrary to a good product and while it looks like it's "satisfying the client" in the short term it is hurting the client in the long term. Make it clear to him that this kind of scope creep doesn't just put pressure on your team, but it puts pressure on the entire company to live up to an unrealistic standard. Consequence: This is mildly confrontational, and even in the face of justified facts and reason it may be perceived as you telling him how to do his job. Try to avoid that at all costs, but with some folks it's inevitable.
  2. If you can't handle it locally, I'd recommend speaking to his boss regarding it. Keep it private. Keep it informational. Keep the tone entirely about asking for guidance on what YOU can do to handle the situation. While your boss will consider this tattling, you can still avoid that stigma by making sure you are putting the onus of effort on yourself. Consequence: It's possible that if this communication gets back to your supervisor (and it will), that he'll consider it going behind his back. This is my least favorite method personally.
  3. Tattle. Arrange a meeting with you, your supervisor, and his supervisor/manager to go over the situation. Have all of your topics prepared and your facts assembled. Make sure the meeting has a thesis and stay on point. Everything you say must be in support of your specific goal or it will come off the rails. Consequence: You're officially a tattle-tale. It doesn't matter what results come of it, your supervisor will harbor some resentment. Ultimately, however, the clients' real needs should be met and addressed and that's the goal isn't it?
  4. Defiance. I don't really recommend this for folks who aren't familiar/comfortable with it. There are a lot of variables involved with this kind of attitude and the consequences when it all goes wrong can be disastrous for you. You are the team lead. It is your job to make sure that obstacles are overcome and deadlines met. This person may be your supervisor, but he has become an obstacle and is threatening your deadlines. Complete your deadlines as promised. If this new scope creep doesn't get done, explain why. Be factual. Be dispassionate about it. Don't let it be a surprise. Make it known from the moment the scope creep enters until the minute the scope creeped deadline goes by. Consequences: Vastly innumerable. Best case, your supervisor gains a respect for you as a leader who sticks to his guns, works hard for his team and gets done what needs to get done. Worst case: Supervisor deems you a "non-team player" and sacks you. Most results end up in the middle. Your mileage may vary.

My best recommendation is to go with option 1 and keep it as quiet and as low on the "food chain" as possible. You can even ask to be present in some of the meetings to help prevent your team from residing under the bus. In any of the suggestions above, however, note that I recommend keeping everything compartmentalized. Discussions should stay between you and your supervisor and his boss (at the most). Complaints always go up, never down. Your team should never be privy to any dissension or malcontent on your part. They have their tasks to do, and your issues should not weigh on them. If they bring it up or are already asking questions about it, let them know with confidence that you're working on it and you have a plan in place.

Personally, most situations I've ever experienced are always handled on option #1. I've never used #2 or #3 personally, and only had to resort to #4 on a couple of occasions (in 20 years). In all cases, when you make your choice, be prepared for the fall out. There will be some no matter what you do.

  • I really like this answer as it covers thoroughly several very distinct techniques you can use in this situation. The only problem I have with it is that usually this stuff is totally dependent on there being some sort of reasonableness in the relationship between you and your management staff. Too often in my experience all these hints are moot because somebody, acting as the 'heavy' right now, just walks by and, totally out of context and informally, without any chance of discussion feedback or dialogsays "WHAT'S THE STATUS?!" and "I TOLD YOU YOU HAD A WEEK!!!" – Andyz Smith Nov 3 '15 at 11:52
  • @AndyzSmith: Yes, it's completely dependent on the strength of the personalities involved and your ability to understand who you're actually dealing with. It's very difficult for someone who is shy or diffident to understand that the way to deal with a "heavy" is to be a "heavy". – Joel Etherton Nov 3 '15 at 12:19
  • +1 really nice answer :) . Personally, if I ever find myself in this situation, I will resort to solution #1 and then, if that doesn't work, I will go to solution #3 :) . – Radu Murzea Nov 3 '15 at 13:09
  • @RaduMurzea: That is not a bad path to take. It is the most commonly recommended path in rigidly hierarchical organizations. – Joel Etherton Nov 3 '15 at 13:26
  • Yes, I agree, these techniques and knowledge of them and of the concept that people may be totally different from you will get you 99% of the way 99% of the time. I'm just throwing it out there that there ARE organizations, that are VERY sick ; they have absolutely no interest in interacting with you, their basis for existence is fundamentally absurd, and the things they ask you to do, e.g. TWICE AS FAST, NOW! are totally impossible. Their motives generally seem to be to churn through and get whatever they can, from whomever will show up. Somehow, these places exist, through some financial – Andyz Smith Nov 3 '15 at 14:59

I like the current answers, but one little thing I wanted to mention was from your edit:

"Post-bus, the rest of the day (well into the evening) is usually filled with angry emails/calls/messages to seemingly random members of the team regarding the status of whatever deliverable was delayed that I would easily classify as "badgering" to get it done."

Who is doing the badgering? Your superiors? Your clients? While getting thrown under the bus is never a good feeling, this easily becomes completely unacceptable to me. This is your team, and disrupting them from working with "are you done, yet?" would not make me a happy person.

  • coming from clients: Ask your team to forward such complaints to you and not to worry about them. Push back.. if you've recorded the instances where priorities shifted, leaving you from completing core objectives, you have those to fall back on. Hopefully, you also recorded the "updates" to your project scope and how it will affect deadlines - and have those approved by your manager. You now just show the documented expected work, with the expected outcomes of changing priority - which was approved by your manager. Address any further concerns with him and stop bothering the team.

  • coming from superiors: Explain how the situation is yours. If they need anything further from your team, come to you. Badgering hurts their productivity. You don't appreciate being micro-managed. With the same documentation example as the above, show how you estimated the changes, which were approved. (hopefully estimates are accurate, but if not, then explain why that was. In reality, every estimate being accurate is impossible.)

In both cases, a re-estimate should be provided. So they don't have to wonder. Sometimes the only answer is: "when it's figured out". That can be tough, but bugging about it is just slowing people down. You'll let them know as soon as you know.

  • I'll edit the question to clarify, but the badgering is coming from the manager. Thanks for covering both cases though. You're absolutely right about it being frustrating, I'm very protective of my team but he is just blatantly sidestepping my authority and I don't find out until one of my team members comes to me to vent about it. The problem is that there are so many of these changes that happen so fast that I could probably spend all day documenting them, and in the meantime he's already bullied someone into starting the work. – thanby Nov 2 '15 at 21:22
  • @thanby It's my opinion (so, possibly not completely correct) that he doesn't have the authority to tell your team-members what to work on, and so he is over-stepping his bounds. He has the authority to tell you what the client wants and needs, and then he can agree upon new terms with the clients with the deadline updates or stipulations that you require. – DoubleDouble Nov 2 '15 at 21:35
  • I personally don't have experience in such a massively chaotic environment you describe - but maybe using more of a easily-editable story-map could serve as "documentation" - where changes in priority need to be recorded and signed for before your team will agree to work on them. Keep the map somewhere you can immediately see him out there changing things. – DoubleDouble Nov 2 '15 at 21:35
  • @thanby Consider your time documenting this stuff an investment. In the short term, it will hurt your personal productivity, but this is a problem that really needs to be solved. The fact your team feels the need to vent about it says a lot about how destructive this is. – jpmc26 Nov 2 '15 at 23:40

I have a totally different answer for you:

1. Realize that you are a beaten dog beneath this manager, and as a result, you've become unaware of your worth, and unaware that there are better places to be. Sit in a quiet room with a simple Notepad app running, and type out all the good qualities you bring to the table, for any company delivering IT projects of the type you manage.

2. Now that you've regained your confidence, update your resume.

You know the rest.

In my 20 years, I've been in your shoes three different times, and I've tried much of what the good people on this post have recommended. Through it all, I learned that, if a manager like yours can attain a position of authority, it indicates the corrupted values of the company that put him there, and the best of your intentions will not change it. Politics always wins, and boy does it wear you out while you're losing the battle.

I have always moved on, and always been happier - except the one time I left one such place for another, got out quickly, and THEN I was happier.

Techies by and large have good hearts, and believe we can deal with anything - but that doesn't mean we should.

  • In short - companies like your employer deserve to lose good people like you. And you deserve better. That's the double-barreled moral justification to moving on. – Jerry Cote Nov 3 '15 at 14:48
  • In other words, "if you can't beat 'em, quit". I really don't like this advice. It's entirely self-serving, and does nothing for the greater good of your team members or company. – Lindsey D Nov 3 '15 at 17:36
  • @LindseyD I tend to agree. This advice seems somewhat shortsighted and immature perhaps. Experienced and mature colleagues try to find some way to work something out; anything really; anything short of going back into the temp-agency/recruiter/another bad employer grinder again. Maybe an individual can find an intermediary who kinda likes the challenge of this manager; and funnel certain amount of ridiculous through them; or perhaps it is time for an employee to find a slightly different job arena - ie, same company, same manager, but become the 'architect'. In this way one can divert – Andyz Smith Nov 4 '15 at 10:21
  • some of the more ridicilous interaction, but still provide value for your company and your colleagues. There are ways to work things out, and some interactions/problems with management are all for the good, as they lead to new and unexpected, synergistic outcomes. Maybe. – Andyz Smith Nov 4 '15 at 10:22

In situations like this, the best solution may be utilization of a formal "Change Order Request" or COR. When new items or functionalities are requested -- by whomever -- it gets put onto a COR, including associated time and cost, and before it gets added to the scope of work, it must be signed off by the client. A COR allows everyone involved to assess the value of the additional work, its cost in both dollars and time, and the mutual agreement that the change is worth it or not.

The beauty of a COR is that everyone gets tired of seeing them crop up frequently. It propels the client to define the project more clearly, while giving your manager a tool to legitimately add scope.

  • 1
    +1 Change orders make every request visible, and illustrate just how far the project is diverging from the original scope. – Lindsey D Nov 3 '15 at 17:41
  • @LindseyD What's fun about paperwork/busywork kinds of attempts to back-manage a broken management system is that it rarely ever has the desired effect unless the management style it encourages is already in place. At first, COR irritate people who like to know 'the status' and 'told you to add the feature'. And eventually you just start getting ''change'' orders like "Get the report system running" and "Make editing work". – Andyz Smith Nov 4 '15 at 10:05

You've met with the client rep at the beginning of each sprint, or project. The two of you (or your teams) have come up with an agreed upon scope of work for that duration. That is your official list. Put it down on "paper" (document/spreadsheet, what have you) and send a copy of it to your manager titled something like "Project X - client agreed scope of work".

Now let your manager manage. If/when he adds new scope/deliverables, add it to your official scope list and then email that back to him.

Let this go for a cycle (or two). If he doesn't adhere to the list and you feel strongly enough (and are willing to accept the consequences, whatever they may be, including termination I suppose), you could up it a notch or ten and send the agreed upon initial scope list to the client rep, and then each time your manager adds to it, send that as an addendum to the client. That will ensure you are covered from the point of view of the client. Just know that your career at your current company may be shortened.

  • I'm not sure it will be 'shortened'. It might be a little less heart-attack-inducing. If you let these requests continue to fester and the project doesn't come in on time because of them, how short will your career be then? – Andyz Smith Nov 4 '15 at 9:21

In my experience what happens is that this particular project becomes more and more of a gamble, instead of a planned profit making endeavor. As it becomes clear that to make money on the project, things are going to have to go faster, an especially seductive way to supposedly make this happen is for managers to use brute force authority to 'make' the project go faster. What really happens is that they just end up adding risk to the project timeline and schedule. It might work out that certain tricks or new techniques will save you 10% 15% even 25% and the project will come in right on time and everybody wins. But more often than not, statistically, things don't go quite as planned, estimates are off, not by being too long, but by being too short, delays in communications, misunderstanding, mis-coordination, etc cause lots and lots of re-do work which lengthens the project.

In my experience what happens, when management continues to brute-force, add risk to a project, there is nothing really that can be done to correct it. It is their prerogative to run it and you are the subordinate. What WILL happen, however, as the goals are totally unobtainable, is that something will slip. 9 times out of 10, what slips is the quality of the solution. The appropriateness of the features shipped, the quality of the code. Basically a lot of things that are relatively easy to hide, and smoke and mirrors over - will take the hit. That's it. the quality suffers, often tremendously. This is sometimes not too terrible, as long as some upper management see this and understand it somewhat.....but, again typically, once management see that they made money that time, in that way, they do it again. And this time, the backbone of the project, the existing code base is hopelessly defective, and is used as the foundation for the next project or a similar project for a new client. That's really when everything breaks loose, you have lots of people getting fired, heads are down, etc.

It's just like a stock market bubble kind of thing. You can ride a low quality code base for a while but eventually, just like stocks, somebody finds out and it all comes crashing down. Where you are when that happens, well, who knows. Give your stock broker a call and see.


What we have done during requests like this is (having estimated the original scope) sit down with the project owner (I would assume this would be your boss and the client) to review the request and say yes it could go in... but what should be removed from the original scope to accommodate this feature and still deliver the project on time?

They will often then sit and weigh up what actually is a big priority and small "feature creep" items will usually not then be added into the scope.

  • if not then we take something out. Win, win – Ilessa Nov 4 '15 at 9:12

Most answers here show you how to deal with a normal reasonable person and you can try them, "hope dies last" ;-)

What you are dealing with is the typical workplace psychopath, who is not interested in the client, the project, the team, the company or anything other than his own profit and career advancement.

There is usually two ways this goes, either management is smart and they figure out he has to go before he destroys the company or they think he is doing a great job and he gets promoted to the next level.

Whatever you do, make sure you have a plan B ready, best outside of this company. Me personally would go into documenting everything like suggested, but also involving the next higher hierarchy level. I would ask them to keep it confidential and that you will try to handle it, but just so they know what is going on, you will send them copies of all the strange requests the manager does. (not sure that's legal, last psycho I dealt with was fired before it got so far)

If he is anything like the guys I know, he will not understand subtle or tactful, even with strong words he will twist everything around. Write short and easy to understand, sentences, also send him mails of anything you discussed verbally, they like to give undocumented orders and then pretend you made them up.

Include statements as "like already discussed, this will add 4 weeks to the time estimate" or "the client specifically said not to ...".

Prepare for a battle on a whole different level than your usual work discussions, when put in a corner the typical pscho will do anything to get back on track. Lying and spreading rumors is their native language.

About the time management and estimates, they should only come from you and your team, if the manager were smart enough to do them properly, he would not be a manager. This problem is a very old one and there are good books about it, for example the pretty old "Peopleware", recommend reading it.

  • I'm not even sure someone like you describe here is even interested in their own profit and career advancement. It sounds like you and I have met some of the same people, who are basically highly neurotic and possibly psycho-path-ic but who for whatever reason manage to bumble and barrel their way through the McDonalds line and into a position of authority at what I would only describe as SICK companies. But alas, McDonald's is probably bad for you, too. – Andyz Smith Nov 4 '15 at 8:52
  • I guess too what I might add is that I think you have hit upon some very noticeable ( regarding Peopleware vs lying and rumors ) defining characteristics of two distinct phenomenon, namely science and business. In business the name of the game is manipulation, misrepresentation, capital leverage regardless of human impact, etc. whereas in science sometimes people use some amount of sense, logic and planning. Just saying. – Andyz Smith Nov 4 '15 at 9:05

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