I started a new job two weeks ago using technologies that are new to me. I was upfront from the start about what I did and did not know so there's no surprises.

I do a little of everything and so I work with three project managers at one time due to the nature of my role being involved in almost every client project we have. When assigning me a task and allocating an expected time, two of the three project managers are generous with their time estimates and have mentioned that they understand I'm new and learning a lot of unfamiliar technologies while also trying to stay on top of multiple projects (which relate to the things that I'm learning). They give me enough time that I've hit the minimum time expected (or finish in less time).

But the third manager's project(s) are the most out of my field. Despite this, and unlike the other managers who are aware of how new I am, she repeatedly asks me "How long will this take you?" and when I reply, "I honestly couldn't give you an estimate because there is a lot of dependencies to get this task done that I need to learn first", her eyes bug out and I can tell she's trying her best not to lose it. I think the reason being is that the role I filled was backlogged with weeks, if not months, worth of work from the get go and so she's trying to hit deadlines for clients. She'll then assign me an expected time that, at this point, I've gone 10 hours over. I'm salary so it's not like they have to payout overtime and I also spend this extra time finishing up the project at home (going well beyond my 40 hours which is fine).

I don't mind busting my ass; I mind the sense of dread and emergency she approaches every conversation with because she's worried about the project timelines. It stresses me out and makes me feel uncomfortable for not giving her time estimates.

I may normally question my progress or capabilities, but I've had nothing but great feedback from the other managers. The senior project leader told me at the end of this week that she's, "Extremely glad to have [me]". The CTO even went out of my way to give positive comments on my work. So... How should I handle this?


13 Answers 13


I don't mind busting my ass; I mind the sense of dread and emergency she approaches every conversation with because she's worried about the project timelines. It stresses me out and makes me feel uncomfortable for not giving her time estimates.

So... How should I handle this?

Give your best estimate. Avoiding one isn't helping you, and certainly isn't helping this project manager. Project managers need estimates in order to help track the overall project. And not giving one means they have to take their own (often less informed) guess and use that. Not giving one also makes you look bad.

Many find that breaking down the task into smaller chunks helps in creating an estimate. Often, smaller chunks are easier to visualize and estimate. And usually, you can ask for a little bit of time to do this analysis, rather than providing your estimate immediately.

Make sure you convey that your estimate likely can't be very accurate yet, and explain the reasons why. Then, promise to give a revised estimate once the project tasks become clearer. And give her a time frame for when you will provide your next estimate.

Track your estimates and actuals, so that you will get better over time.

And as your project progresses, re-estimate the remainder even if not required to do so. If you feel that your original estimate isn't likely to hold, then make sure to provide feedback to the project manager as soon as you know. Project managers (all managers) don't like surprises.

Then stop the dread, stress and uncomfortable feelings. These are emotions that you bring on yourself. Knowing that you are doing your best, and that it is being recognized by those about you should free you from these feelings.

  • 24
    +1. For the first ten years of my career I found the "when will you be done" questions annoying, but I see it differently looking at it from a leadership view. Having an idea of when different parts will be done is really important, and when a developer can't even give an indication, it makes me concerned. I lament all those times I was too nervous to give an estimate! I don't mind if the estimate is somewhat vague, and I don't mind (within reason) if the date doesn't get hit, but I need an approx date to schedule things and set expectations with other teams and managers.
    – Andrew E
    Commented Aug 22, 2016 at 11:42
  • 19
    And don't forget to give early feedback if it looks like you will not complete reasonably close to what you had said. Saying "I originally thought that this would take x, but now that I have done x/4 I can see that the problem is more complex. Having considered this I think that it will take y" is much better than "I've done x but it is not yet done"
    – Jonny
    Commented Aug 22, 2016 at 12:33
  • 2
    "there should be nothing wrong with asking for an hour or two to scope out an issue and provide a more refined estimate" This. And it still applies when you have 10 years experience working in the field. However much you know (or think you know), "jumping to conclusions" is never the best problem solving strategy.
    – alephzero
    Commented Aug 22, 2016 at 16:07
  • 5
    I fundamentally disagree with this. I regularly work with tech I understand extremely well but refuse to provide estimates when appropriate, because -- for example -- understanding PHP absolutely does not imply being able to estimate updates to complex Drupal modules. There's a big difference between providing an estimate you actually believe is reasonable (and appropriately padded) and what the OP is asking for, which is advice on someone who insists on estimates for things he does not understand. Guessing would be both dishonest and self-destructive.
    – kungphu
    Commented Aug 23, 2016 at 10:36
  • 4
    @kungphu More likely than not, the OP isn't being asked for a hard-and-fast "this will take me 5 hours" which will be 100% correct. It's extremely likely that the OP's manager simply needs an idea of the size of a task. There's a big difference between a task that will take one or more hours and one that will take one or more days/weeks. A manager needs that information, even when a 100% accurate estimate is impossible. The OP will need to emphasise the accuracy of their estimate but it will still be a lot better than "I can't say anything".
    – Cronax
    Commented Aug 23, 2016 at 11:06

Don't give a point estimate, give a range. Point estimates are usually seen as the default, but in most cases, range estimates would do a much better job. Your case is one where the range estimate is the better choice.

For a task you are very comfortable with, you can start giving narrow ranges. "I will finish the monthly report in two hours, plus/minus 15 minutes". When you are faced with a task which you don't know what will entail, the truth may well be "between two hours and two days". Simply stating that will sound insolent, so give it with an explanation. "I saw a monthly report produced in another project. I'll have to look into it. If the numbers are available somewhere, two hours should be sufficient to write up the report. If I have to find a way for calculating them, and chase down sources, it can easily stretch to two days or more".

Now, the manager can let her inner Kirk hang out and scream at you that two days is unacceptable. To which you can answer that 1) it is still possible that it is done in 2 hours, you just can't estimate the probability, 2) you cannot create true numbers out of thin air, 3) after you have gone through the process once, you can prepare better for next time (gathering numbers during the month, reusing an Excel macro to calculate them from raw data) so next month the report will take much shorter, and 4) ask her, if two days are not acceptable, what should you do if it turns out that the numbers will not be available on time? For example, provide only one section of the report (which one), or get permission to pull a second person from his usual tasks to also work on the numbers?

It is especially important to get the fourth one right. You have to display understanding for her concerns and be genuinely open to alternatives, while gently reminding her that "get it done in the time I alot" is not an option. If you come across as sarcastic or condescending, you will hurt your chances for reaching a constructive relationship with your manager.

She still won't be happy, but the best thing to do here is to take her concerns seriously (maybe you are missing an external deadline) and to engage her in your estimation process so she sees for yourself that you are not simply being difficult on purpose, or too dense. She may manage your time, but you have to manage her expectations.

  • 1
    I think you should remove the comment about point estimates, it detracts from an otherwise excellent answer.
    – Cronax
    Commented Aug 23, 2016 at 6:37
  • 2
    Why is it distracting? For me, it is the whole point of the answer. All the rest follows directly from it.
    – rumtscho
    Commented Aug 23, 2016 at 10:42
  • Detracting =/= distracting. I'm saying that first sentence makes the answer worse than it could be, because it contains a statement that is opinion at best and false information at worst. Properly used, point estimates are a valid tool.
    – Cronax
    Commented Aug 23, 2016 at 11:00
  • 1
    @Cronax OK, I toned down the overly generalizing claim. Still think it is a valid point to think about, and in the end, all answers here are based on opinion. But now that you mention it, I agree that I had worded it poorly in my original answer. Thank you for your suggestion.
    – rumtscho
    Commented Aug 23, 2016 at 11:05
  • 1
    The trouble with giving ranges is that some people only hear the lower figure... ;-)
    – Flyto
    Commented Jul 3, 2018 at 19:32

I find the PERT estimation useful for software development tasks. Summarising:

a = time if you fly through it, no delays, no problems

b = time you think it will realistically take given known delays and known problems

c = worst possible scenario, everything gets delayed, your other bosses give you extra work, and you find a flaw in your implementation at 80% through your plan

Estimated time = (a + 4b + c) / 6

Variability = (c - a) / 6

Say you think a task would take a day in ideal conditions, and normally you'd get there in the next 2 days because of meetings, but there are a few stages that could cause problems and then it would be 9 days. Then your estimate is (1 + 4x2 + 9) / 6 = 3 days, variability is 1.3 days, so you would say "I expect to get it done in 3 days, but it could easily take 4.5 days."

This way, they have an idea of when to expect it (for delivery to customers, you want to estimate the time to delivery in calendar days, including the effects of meetings, holidays and so on), and an idea of what a conservative estimate might look like. If there is a big variable, like 'it might break component X, so then I'd have to modify and rebuild that component, which would be an extra week', then flag that up in the response - 'I expect it to be done in 3 days, but it tests the limits of component X, so there could be an additional week there'.

This is one of the hardest bits of working in small businesses with multiple competing demands on your time. So grasp it with both hands and don't shy away from giving estimates. The sooner you get a handle on it, the better things will be. If quizzed in person, don't be afraid to say "I can't give you an estimate that would be any use off-hand, let me send you something by the end of the day".

Good luck.

  • 2
    No idea if PERT is working well, but I don't get why someone downvoted you without leaving a comment. So you get my +1.
    – mafu
    Commented Aug 22, 2016 at 11:08

Estimating timeframes is an important skill, work on it. Factor in everything you know, give yourself a healthy and generous margin and give the estimate. As you progress this gets easier and easier. If there's multiple variables, factor them all in, each with a margin.

Otherwise you get stuck with what you got stuck with, a wildly inappropriate timeframe you're struggling to meet.

  • 7
    Also probably worth bearing in mind that the manager is either equally bad at this, or else is an evil genius who's screwing every possible hour of unpaid overtime out of the questioner by sticking them with lowball timeframes. It's not like the questioner is the only person in this company flailing around with little chance of successfully predicting anything ;-) Commented Aug 22, 2016 at 9:51
  • 2
    It may be worth noting that lots of (bad) managers consider a "generous margin" to be theft of hours from the company.
    – Magisch
    Commented Aug 22, 2016 at 11:43

You say: "She'll then assign me an expected time". This is probably the most important thing to address. She's asked you for an estimate. You have been unable to give her one, so she has gone ahead and made a plan anyway.

The point is that as the technical specialist, your estimate is probably the best one available. Has she just made up a number, or has she got a basis for the number she's chosen? It's probably reasonable for you to ask how she's arrived at it. You may need to use all the professional tact at your disposal, but running away from this won't help either.

The distinction between an estimate and a plan is crucial. In refusing to give her an estimate, perhaps you have given away your opportunity to influence the plan. It might be possible to say: "I really don't know, but I understand we need to plan something." At least then you can discuss the plan. As it will be based on inadequate information, you'll want to plan to replan it. Often it can be really helpful if you can say when you think you'll know more. For example, "At the moment I don't have enough information. It's impossible to estimate it right now. In order to make progress, I'd suggest we start by planning 4 weeks for it, but I'll know much more by the end of the first week, so let's meet then to see whether that's anywhere near the mark. Is that going to work for you? Are there any other constraints I need to know about?"


Does she ask "how long will this take" and expect an answer right now? That would be utterly ridiculous and incompetent. I'll assume that she is not incompetent but wants a proper estimate.

There is a commonly used strategy for getting good estimates which is used by agile development / scrum. For a proper estimate, you need a precise statement what work needs to be done, and what the acceptance criteria is. Then you split the work into components that take at most two days each. Then you estimate how long each component takes. I mean you estimate. Your manager can't estimate. Your manager can state their wishes, which you should completely ignore, because wishing doesn't get the job done. And you don't make any estimates for anything taking more than two weeks, because that is just about impossible to get right.

Making these estimates will take you considerable time. Probably a day or so. It's not lost time, because doing the estimates, you find out what all the components are that need doing. So you are prepared when you actually start the work. It may be that you also need to write down the specifications what needs to be doing. Which also takes time, which is also not lost because without some decent specification what you want you might as well not start.

And when you make that estimate, you take everything into account. Mostly you take into account that you are not working 40 hours a week without interruption. And then you take into account the minor detail that you are working for three people, so instead of 30 hours a week she will get about 10 hours a week of your work.

One answer showed something like "customer sign up functionality". That's much too little for a proper estimate. There's so much you will be missing. Something like this, you need to write down all the components, ever item that needs doing. Overwise you will not estimating, you will be guessing.

And finally, stop doing 50 hours a week right now. As a salaried employee, maybe you need to work overtime if it is needed due to business reasons. A huge backlog that was there before you even started isn't a business reason. That problem isn't solved with overtime, and not with unpaid overtime, but by hiring another employee. And a manager who is incompetent at making estimates is also not a business reason.

  • "Does she ask "how long will this take" and expect an answer right now? That would be utterly ridiculous and incompetent." - This heavily depends what industry OP is in. In some fields, especially in the consulting world, it's very accepted for project managers to ask this & expect an immediate answer. If you work for a company that's building a major piece of software, this is obviously less reasonable...
    – c36
    Commented Jun 4, 2019 at 1:18

Split the task you have been asked to do in subtasks. Estimate how long each task should take. If any task is either hard to evaluate or longer than, say 2 days, split it again.

Once you have a list of small tasks, re-evaluate to make it consistent. Add whatever margin needed to make you feel confident (e.g. x2 every estimate)

Group you subtasks in deliverable features of possible, then give a schedule to the PM.

This planning work is usually done in collaboration with the team, the team lead and with input from the PM, though (to split in features, and give priority to these).


If I know what I'm doing with every piece of technology involved and know the infrastructure, and a project manager asks me how long a given task will take, I sketch out a flow diagram, break that down into components, estimate each component, add it all together. That's my hours estimate. Then I take that number and multiply it by 2.5x. This allows for unexpected problems.

If there's any part of it that's unfamiliar... add 5x for unfamiliar infrastructure, 10x for unfamiliar programming language, 10x for unfamiliar RDBMS product. I usually nail it within 10% of this adjusted estimate.


Some good things others have covered: take some time to break down the task into smaller chunks that you're more familiar with; give the best estimate you can; update as soon as you know more. I'll add something I haven't seen yet: give a confidence interval.

Think of it from the other end. As a PM, I have to ask people for estimates all the time. My org is growing and we're not collectively used to formal project management - so people often refuse, which drives me nuts, because I have nothing to work with and no idea when something will be done, so I can't make status reports or tell if we're on schedule or need to reprioritize, etc. So, it's understandable that your third PM's eyes are bugging out when you don't answer, even if they're not handling it that well by making up numbers and putting more pressure on you instead of helping you through the process.

And I get it, you won't really know until it's done. But if you think about it, you probably know at least a little bit more than the PM - five minutes, five days, five months? Here's what I do when I'm the technician and I have to give an estimate: give two instead.

"There's probably a 50-50 chance that it's easy and things will go smoothly, in which case it'll only take about 5 hours, which with my current workload means I should have it for you in a week. Even if it goes wrong in a few ways I can think of, I'm 90% sure it should take less than four weeks."

Do check in again once you know which of those is more likely, especially if something unforeseen has blown up and you think it might be longer than the second estimate.

Also, if the estimates the other two PMs have been giving you (presumably based on past experience with others in your role) have been reasonable, consider asking those other project managers for help with the third. They may have some insight to offer - either on the general skill of estimation, or on the specifics of what sorts of tasks your new role is typically responsible for and how long those usually take.

  • This is exactly what I wanted to say. Thanks. This manager must learn to deal with the fact of life that when doing things for the first time, accurate time estimates are really difficult to provide. It's probably worth discussing this in general. Commented Aug 23, 2016 at 20:33
  • I like this idea and came across similar in one of, I think, Steve McConnell's books. So at the start of the project I may say this task will take 1 week and there is a 100% margin of error. After it has been refined then I can say, it will take 6 days and there is 50% margin of error etc. etc. The key is that management takes on board the margin of error, and doesn't just hear the estimate! Commented Aug 23, 2016 at 20:41
  • @LaconicDroid I think a margin of error makes sense when you already have a pretty good idea of what you're doing and what might go wrong (or right). One of the more common tasks I do depends heavily on the crap shoot of what we get from the vendors every year; in that situation saying "20 minutes, with a 3000% margin for error" isn't as helpful as saying "30% chance it'll be done in a day or less, 90% chance it'll be done in a week." Sounds like OP is in the latter situation, at least for now. Commented Aug 23, 2016 at 20:48

Being "NEW" is not the problem here.

Providing estimates, as a new or old employee, is a pain until you master the magic words to ease every PM's firing thoughts...

We recently started following scrum and obviously estimating our tasks. It's difficult to estimate tasks, especially when working on new technologies.

Enough talking, give me the solution now?

Here is a fantastic article which I believe fixes issues with estimates and will makes you less stressful, as it did for me.

Simply add risk to your estimates:

Section Line Item Estimate Risk
customer sign up functionality design html & css 12 MEDIUM
create new asp.net page 4 SMALL
add javascript validation 6 SMALL
post sign up details to 3rd party API 16 LARGE
Total 38 MEDIUM (76.25%)
Best 29
Worst 50
Avg 40

(example table taken from the above linked article)

Based on my experience

You can't ask a PM to slow down, but what you can do instead is give your best estimates with risk factor. This risk could be anything e.g. New technology, third party software, disorganized code of ex employee etc..

Not sure how desperate you are for this job, but don't spend a second working overtime for free. Ask yourself, would you pay you extra for no reason?

  • @JoeStrazzere Not able to find exact reference to article where I read it, but here are some close examples : calleam.com/WTPF/?page_id=1445, saying all that.. my main agenda is to ease OP's stress or other readers who going to read this :) Commented Aug 22, 2016 at 11:25
  • Martin Fowler say that in his book, that that quote is out of context, most software projects that fails, fails because of misinterpreted or changed requisites (in example client wanted A and you realized B). Spending time in creating legacy code that does not what is required to do is the major killer (so tecnical skill even play a marginal role according to certain stats, the most dominating requisite are always software requisites) @JoeStrazzere Commented Aug 22, 2016 at 13:32
  • 1
    Googling for "Most software projects fail" turns up a Standish Group report dated 1995: projectsmart.co.uk/white-papers/chaos-report.pdf ; that's rather a long time ago but I feel the situation has only slightly improved.
    – pjc50
    Commented Aug 22, 2016 at 13:45
  • 1
    define "fail", though?
    – njzk2
    Commented Aug 22, 2016 at 14:15
  • 1
    @pjs50 the report you reference says "The Standish Group research shows a staggering 31.1% of projects will be cancelled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. " So how do you define "fail"? Commented Aug 22, 2016 at 20:30

I haven't seen this answer...
Talk to your immediate manager/boss and ask them what the priorities are - how many hours per week should you spend on each of these items as well as other items (research, education, team meetings, etc.) A few years ago I became overcommitted, and worked with my boss on how many hours per week to spend on each type of item. That worked great. If a task type was allocated 10 hours, and I knew something would take 40, then it would be about 4-5 weeks. I would also caveat any deliverable date with any prerequisites such as needing information from other people.

As an aside: Consider taking one short class (credit or no-credit, an EDx class maybe) in project management to be able to manage your projects and to "manage up" to the project manager. A little bit of research and understanding will give you many of the tools mentioned by the other answers.


One more point that wasn't mentioned yet: Talk to coworkers who have done similar tasks (if they exist) and get a feel for what timing is usually necessary.

I was in this same boat when I started my job. I had to report to 3-6 project managers (depending on what projects I was working on) and they ALL wanted to know how long things would take.

I did my best to estimate, and yes - my estimates were quite off at first. Usually on the low end. (To the point where one of my project managers always multiplied my estimates out by X percentage before telling it to the client!) Eventually I started adding a generous buffer to every estimate that I said (even when the buffer seemed unneeded!) and my estimates slowly started getting better.

The biggest help, though, was talking with coworkers. If a project manager asked me how long something would take, and I really had no idea whatsoever, I'd ask for a drop of time to get back to him/her, and then I'd catch a coworker for a few minutes to get his/her sense of what's involved with task.

In cases where I couldn't do that, I would give my best estimate - and then later go talk to a coworker & get an idea of what his estimate would have been. Although it doesn't help in the moment, the goal is here to improve over time, not to get it right the first time.

Estimating is hard. Don't beat yourself up about it; just focus on trying not to repeat the same estimation mistakes twice.


In a negotiation, the person who names a number first, loses.

Your answer should be "That depends, what expectations have been set? what are the hard deadlines? What other tasks are dependent on this and what are their deadlines?"

Note, don't ask them what the urgency level is, because then they get to tell you it is critical for the survival of the human race.

Also, don't ask them when they WANT it done. That will give them an opportunity to say 'yesterday'.

Then, depending on their answer, you can follow up with anywhere between:

Sure, I'll get it to you by then (whilst secretly knowing that's twice the time you need).

Through to "That won't be feasible with my current workload, if it needs to be done then, you'll have to speak to one of the other managers and rearrange some other work." (Note, make sure THEY speak to your manager, not you).

Or even the extreme of "That isn't feasible even if I have no other work to do, which may require either more people to work on the project, or resetting customer expectations."

  • 2
    This is not negotiation it is a work task that you have already agreed to perform. Commented Aug 23, 2016 at 21:22
  • It is a thing where one person wants a number to be as small as they can get away with, and one person wants it to be considerably larger. How do you plan to solve this conundrum without negotiating?
    – Scott
    Commented Aug 23, 2016 at 22:16
  • @Scott This has nothing to do with what either party "wants", as you said yourself in this answer. A man-hour estimate is not the same as a priority decision. Let the managers work out what gets done when. For now the OP should just answer the question. No wonder the PM is stressed when they have no earthly clue what they have to work with when going over the resource allocation plan. Commented Aug 23, 2016 at 22:49
  • when working on multiple projects for multiple managers, then estimates do depend on the priorities of each project. @scott: i'd remove the first line in your answer as it makes it unnecesarily controversial. otherwise this answer doesn't deserve the downvotes it is getting.
    – eMBee
    Commented Aug 24, 2016 at 4:58
  • "In a negotiation, the person who names a number first, loses.", this is true +1 Commented Aug 7, 2019 at 21:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .