The other day, the development team and I had a meeting with some stakeholders.

The stakeholders asked for a new feature with the follow-up questions of "How long will it take to do it?"

As the team manager, I said "Roughly X".

And then one of my leading developers said "It can be done much faster. In X/4, including tests and buffers".

I feel really uncomfortable with this statement because:

  1. It implies to the stakeholders that I have no idea what I'm talking about when I provide estimations
  2. It can also be interpreted as "the TL is giving high estimations, so his team can work with ease"

What should be the best way to address this, both in front of the stakeholders & the subordinate developer?

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Kilisi
    Commented May 27, 2021 at 2:54
  • 4
    @JoryGeerts No. Its the devs job to give an estimate to OP and OPs job to do something with it to the client. Eg x2, or x50 or whatever
    – Martijn
    Commented May 27, 2021 at 9:26
  • 2
    Very culturally dependent, but maybe investigate which estimate is right rather than focusing on organizational hierarchies Commented May 27, 2021 at 12:24
  • 5
    @HansKilian The issue isn't whether the estimate is correct or not. The issue is that mid-meeting with stakeholders is not the time to have those discussions about the estimate, and especially not if it means contradicting the head of the department. Commented May 27, 2021 at 14:30
  • 7
    Something else to consider: If you didn't want the devs to give input to the stakeholders, why were they there at all? Was this a meeting that should have been attended only by the manager, and then communicated back to the devs? Commented May 27, 2021 at 16:18

9 Answers 9


You need to talk to your dev, but not in front of the stakeholders.

Your team needs to have a united front face. My normal policy when I led a team (engineers, not devs) was to defer giving the timeframe stating we'd need to look at all the angles before giving a firm timeframe. But my team was also aware that they didn't have the authority to give timeframes and as professionals we all knew meeting protocols of not disagreeing with the lead in meetings that included others.

Even before I was lead I knew this, and this is what you'll need your team to be aware of. Your other alternative is to exclude that developer from some meetings, I've seen that done more than once as well when a staff member has a tendency to speak without thinking.

When speaking to the stakeholders don't put a team member down. A simple explanation like 'He's a great dev, very focused and efficient, but he's not aware of the full picture. We have other work to do as well." is sufficient.

Simple reason is that the lead is the one who will be held responsible not the staff member. It's one of the reasons for having a lead.

  • 50
    @a.t., Because an eager less experienced member of the team will always try to impress the higher-ups by giving shorter estimates. To that person, it's a dopamine rush. And such a dopamine rush in one person could easily cost the rest of the team 12-hour workdays, including having to work on weekends and holidays, only have to the big boss be disappointed when the project is finally delivered much later than what he remembers having been told initially. Commented May 26, 2021 at 19:52
  • 18
    @StephanBranczyk yep even without that, many devs, myself included have a tendency to look at the abstract problem and once they found a nice elegant solution for that, the implementation seems easy and fast, but one almost always overlooks the nitty gritty details then on ad-hoc intuitive estimates. Estimation is tough work, ad-hoc estimation requires lots of experience and good self-control. Independent of attempt to impress. Especially contradicting with an apparent easy solution is dangerous because one may overlook something and then the easy solution doesn't work out and it falls apart. Commented May 26, 2021 at 23:04
  • 5
    @GwynEvans The dev's level of experience makes no difference for this answer; it's based on the subordinate dev relationship as described in OP's question.
    – A C
    Commented May 27, 2021 at 7:04
  • 10
    @JoryGeerts "The stakeholder didn't ask "when will it be done", they asked "how long will X take"." - In my experience, when non-devs ask "How long will X take?", they actually mean "By when will X be done?". But all of this is irrelevant. If my superior states "It will take X amount of time" in a meeting. I won't say anything different except maybe, that "this optimistic estimate will put some pressure on the dev team"... you never know what kind of politics are going on if boss-man obviously overestimates an effort.
    – Fildor
    Commented May 27, 2021 at 11:05
  • 16
    @JoryGeerts Consider if the dev says "it'll take 1 hour" and the stakeholder says do it. 3 days later the stakeholder asks "where's my result?", the dev says "Your hour is scheduled for next month." The dev's estimate may be 100% accurate and correct but the stakeholder is not going to be happy.
    – Hellion
    Commented May 27, 2021 at 17:26

The first time it happens, handle it quietly. The dev was most likely just trying to add value/effort to the project and did not mean to specifically undermine you. He did, but give him the benefit of the doubt that it was not his intention.

At the time, kind correct back and allow for the possibility that the dev may actually be correct. Something along the lines of telling the stakeholders:

We'll look into a more detailed estimate and see what we can do. For now, I'm going to ballpark estimate [your estimate] but we will refine this.

After the meeting, speak to the dev directly. In order to create the least amount of friction and enhance the likelihood of the dev hearing what you're going to say, first hear them out. Listen, interpret, and provide accurate feedback. Maybe they are right, maybe they are not.
Let them know you appreciate their input (regardless of being correct, they are trying to help), but explain how the meeting was not the right place or time for that input.

Now that their idea has been heard, shift the conversation to how your estimate factors in more than just the dev's own work. Your estimate contains safety padding, time for internal development needs, time for meetings and expected delays due to back and forth communication, other concurrent workloads for your dev team, and so on.

Stress that you are the public face of your dev team, and that the dev is present in the meeting specifically for the technical questions, not to represent the team; and that the main focus contains more than just the technical part, so the dev cannot and should not override your input.

If this happens again in a second meeting, swiftly meet the dev's statement with established facts, in front of the stakeholders.

[Dev], as we talked about before, the estimate I provide contains more than just the barebones technical implementation. There are additional considerations that you are not aware of, so your estimate cannot possibly account for them.
[Stakeholder], I apologize for the confusion. I expect the task to take [your original estimate] in its entirety.

Sidenote: if the dev starts arguing with you and elaborates their position or digs deeper into why your estimate is off, shut it down immediately, telling them that they can talk with you after the current meeting. Do not let them take control of the conversation.

At this point, after the meeting, sternly discuss this with the dev. This is the part where I would no longer first ask them for their input, but rather strongly point out that their behavior is effectively undermining your position, and that you cannot tolerate this in meetings with stakeholders/clients. Get them to verbally agree to not pull this move again.

If it happens a third time, this is the part where I would consider an official warning, disciplinary action (depending on the severity of their behavior), and formally uninviting the dev from further meetings.

This is no longer a matter of a well-intentioned dev who makes a faux-pas. This is a matter of a developer who bypasses you even when explicitly instructed not to, actively undermines your leadership, and plays the dev team off against the stakeholders. That is not a person I would trust or freely allow into open discussions.

  • 72
    Common sense: when your manager overestimates the effort, you keep quiet. If it results in spare time, you will find something useful to fill it. If your manager underestimates the effort, that’s when you speak up. Carefully.
    – gnasher729
    Commented May 26, 2021 at 17:46
  • 5
    @gnasher729: Unless the manager is already setting a promise in stone, I'd be inclined to still only bring it up afterwards rather than in front of a stakeholder. But I agree with all the rest you've said.
    – Flater
    Commented May 26, 2021 at 21:39

To a certain extent, it depends as to which estimate is accurate - you say the dev is one of your leading developers, which suggests they should know what they're estimating, but we don't know if you do?

There's a bit of a red flag when you gave an estimate then say you're uncomfortable because it "implies to the stakeholders that I have no idea what I'm talking about", rather than simply acknowledging the possibility that you're not omnipotent and the dev may have picked up on something you didn't.

Ideally, there's be 'internal' discussions regarding effort required, but it sounds as if you jumped in before that was possible, stating a figure which may have been significantly off, where leaving it unchallenged in the meeting was likely to have significantly skewed the 'features-list' for the next release/sprint/whatever.

Basically, are you sure you didn't back them into a choice of publicly correcting you or keeping silent and misleading the stakeholder - which choice was the best one for the company/product?

  • 4
    Agreed, although there are more diplomatic ways the dev could have handled it. Like, "Boss, we might be able to significantly beat that, let me talk to you about options after the meeting." That gives the shareholders the option of optimism without embarrassing the manager or committing them to a shorter timeline. Commented May 27, 2021 at 4:22
  • 2
    For effort-based estimates a developer knows better than a team lead, and I would take the developer's estimate over the team lead's. Any kind of elapsed-time estimate (which needs to account for other commitments/resourcing/holidays etc) the developer will know less, much less in many cases. This sounds like it was elapsed time, in which case, the developer should keep their mouth shut.
    – numenor
    Commented May 27, 2021 at 12:32
  • 1
    Being a good developer does not inherently make you good at estimating times.
    – musefan
    Commented May 28, 2021 at 10:40

In addition to the answers above (Reiterate your message to the stakeholders, talk to the dev separately), there seems to be a problem with this dev knowing what their role in the organization is.

I have had to explain to devs in the past that it is not their job to correct their managers in a meeting.

I've had to explain that as the one who is responsible for the project, the manager/project leader bears the burden of making the estimate. I've explained that this is a benefit for the dev, because they don't bear the responsibility if the project is not done on time.

This dev also seems to be afflicted with the curse of thinking they are smarter than you are. It's common among developers. I'd say most of us have gone through it at some point.

I wonder if some of the dev's willingness to undermine your statement at a meeting is from the culture of the internet where everything is flat, there is no hierarchy, and people argue with everyone about everything regardless of who they are.

Finally, I would lay out exactly what your expectations for the dev are before the next meeting. You might say "We're going to be meeting with [people]. I'll do most of the talking. You are going to be there to listen and to help answer specific questions from me about X if it's something I'm not familiar with. If you have specific questions about the project that must be answered right then, go ahead and bring them up. If I push back on those questions, just let it go until later. For any other questions, write them down and we can discuss them afterwards."

It's important to know one's place, and many people have not had it laid out to them. It's easy to think it's "common sense", but nobody is born knowing these things.

  • 6
    A curse of smartness? I would venture that managers should be striving to hire devs who are smarter than they are.
    – Igor G
    Commented May 26, 2021 at 19:46
  • 3
    Managers should be hiring smarter devs. But part of that should be understanding that providing an estimate that accounts for the work to be done and buffer for unexpected work, and delivering that estimate to the stakeholders, is the manager's job, not the dev's. This dev might be a genius technically but they've demonstrated startling naivety in undercutting their manager in front of a third party, which may be from the arrogance of thinking they know all the things that go into an estimate.
    – Xono
    Commented May 27, 2021 at 6:50
  • 3
    If the dev was invited and asked for input,they probably do not have a problem with knowing their role. And it would probably be better to ask them before giving estimates.
    – eckes
    Commented May 27, 2021 at 10:26
  • 1
    @IgorG At least they should be smart enough to know when to keep their heads shut.
    – Fildor
    Commented May 27, 2021 at 11:13
  • 1
    This is a good, insightful answer.
    – Kilisi
    Commented May 27, 2021 at 13:20

This is gonna be a different answer - but writing because I believe my points deserve to be more than a comment..

I used to take it rather personally when I encountered situations which you have mentioned. Not least because the over-optimistic estimations given by junior or relatively inexperienced developers tend to be very wrong on the lower side. But I have also seen even technically senior developers giving estimations which tend to be very wrong at the end.

As a technical Architect, I was usually tasked with challenging these estimations, but the expectation from stakeholders was that I lower the estimation, not the other way..making the job doubly difficult.

Understanding a few things helped me to handle these situations:

  1. Appreciate that there will be developers or engineers who want to impress stakeholders by claiming that they can do a job really quick (even if it means compromising quality by adding technical debts or by working overtime). I once worked with a senior dev. who never missed an opportunity trying to impress Head of Product (business guy) that he could do a given fix or feature in a day. I used to tease that developer by calling "Mr. one day"..I am not saying that you should follow that feet, as it depends on your relation with that person and overall team dynamics.
  2. Appreciate that stakeholders will almost always want to hear that something can be done quicker..so they will put pressure on the technical team. May be they had never got the requirement correct, there are technical debts, team members are going on holidays...still they usually feel much better when they feel that they could successfully negotiate an estimation..so just take it as part of the office politics
  3. Understand that your job as a technical lead/manager is to make stakeholders aware of the risks with a given estimation
  4. Like someone else already commented, a successful strategy could be to tell stakeholders that team will sit together, agree on a number and will get back to them..This is usually a good defence as everyone nowadays agree that development should not be a one man show and so estimations should also come from a given product team - not just from a single team member
  5. Finally, from my decades long experience in the industry - I have consistent experience that estimation is a dark art. There is nothing scientific about an estimation..still industry and self-anointed pundits came up with a variety of snake oil methodologies to make "estimations more accurate" (such as poker cards etc.). Don't take it personally when you encounter a lower (or higher for that matter) estimation and move on.

It's a team issue, not a personal issue.

There are a lot of answers already themed around putting the dev in their place. In my opinion, that's not the most productive way to address the issue, and is very likely to increase tension in the team.

I agree that you need to have a conversation with this dev, but rather than saying "don't undermine me in front of stakeholders", why not ask "how did you and I get such different estimates for this task?" That way the conversation is framed around sharing context and growing as a team rather than authority and blame.

Maybe you know something they don't: sure the code itself is easy, but integrations with other systems and teams will slow you down. Maybe they know something you don't: they've had to solve this exact problem in a previous job. Maybe there was just a miscommunication or misunderstanding about the ask. Assume positive intent.

In the spirit of that, I think you may be too worried about the stakeholders' impression of you. They probably were shaken by the two different responses, but most people don't jump from two disparate numbers to "this guy has no idea what he's talking about" or "he must be conniving to stretch the work out so they can kick back". More likely they're just as curious (and perhaps unnerved) as you are about why the numbers were so different, which is another reason it behooves you to find out why they're so different. Not right, not wrong, just different.


As a team lead, all you can give in such a meeting as a rough estimate. The client should understand, that this is up to 50% off - in both directions.

A real estimation is done in an estimation meeting, were every team member estimates a story with Fibonacci numbers. Then there is an open discussion without any fear of consequences for too high or too low estimates. Vastly different estimates are great indications, that the story is not clear and your team members see different risk or even scopes. That is a great opportunity to find and talk about such things before you even start the task.

You as a team leader made a mistake to bring the junior developer in this unfortunate situation. He should not be punished, but you should think how you can protect your team members from such damage in future!


What should be the best way to address this, both in front of the stakeholders & the subordinate developer?

In front of stakeholders:

Developer X, thank you for sharing. We should discuss the details at a later time to make sure we're considering all of the angles.

If this developer is worth their salt then they should humbly agree and not press the issue any further.

If they press the issue further then try restating the statement from above but more firmly.

If they continue to press the issue then you might need to ask them to step outside for a moment.

If they continue to make a scene then you have a much bigger problem on your hands; this developer doesn't respect you.

At some point you have to determine whether this developer is being naïve and thick-headed or if they've crossed the disrespect threshold and are choosing to stay there.

To the subordinate developer:

In private:

Hey, I was really surprised by the estimate you gave especially since it's 25% of what I said. Can we discuss it?

Presumably they will ramble about why they thought it was justifiable to contradict you in front of stakeholders. You may or may not agree with what they've said; it really doesn't matter because this next discussion is what's crucial.

Thank you and I hope you know that I always appreciate your input. We can certainly look into giving the stakeholder an updated estimate.

There is however something I would like to establish moving forward. I would like to maintain a sense of unity and synchronization in our team especially when talking to stakeholders. Would you be willing to bring up issues such as this one to me privately after a meeting? I don't think it looks good on us if we're providing contradictory statements during an important meeting such as that one.

  • 2
    I hate it when my contractors are not allowed to speak open and without fear. Then I don't need to discuss this in a meeting, then I can write an email. I want to hear the different opinions. Every good costumer is not after the last penny but should have the well-being of his software and "his" development team in mind.
    – usr1234567
    Commented May 27, 2021 at 19:25
  • 1
    @usr1234567 Well that's a little short-sighted to call it fear; more like cohesion and respect. You like it when your subordinate introduces something to a contractor which you weren't aware of? You assume every stakeholder knows or cares what the heck are tests and buffers and how little or a lot it affects the project estimate. If I'm a financial stakeholder in a large-scale construction project and the project manager's subordinate acted disjointed then that would immediately raise doubts in their ability to do the project.
    – MonkeyZeus
    Commented May 27, 2021 at 19:53
  • Other answers talk about firing the developer. That would lead to fear. I agree with cohesion and respect.
    – usr1234567
    Commented May 28, 2021 at 9:36
  • 2
    @usr1234567 You should comment on the other answers then =) My answer explicitly abstains from the "fight fire with fire" mindset.
    – MonkeyZeus
    Commented May 28, 2021 at 13:32

He wants your job. Your job. Will you just handle your job to him? Of course not. Fortunately for you, this is very easy to counter. You just make him responsible for meet the X/4 deadline but you alocate all resources, except him, to everything else that is under your responsability. Make sure he will fail and then blame him but do not let him know you are doing this. Since you used the resources for your benefit, you will look competent and he will look incompetent. This will teach him a lesson to never menace you. But talking seriously... Yeah do that because that is what is done in real life despite being considered "unethical".

  • 1
    youtube.com/watch?v=QGmhLtsK2ZQ I mostly assume other people have the best intentions when they make a mistake, and it seems to fit with "real life" well enough. Commented May 28, 2021 at 6:56
  • 6
    Thank god you are not my boss. Such a toxic behavior. You should not profit from letting your team suffer. As a leader, you should help them succeed and their success will shine on you.
    – usr1234567
    Commented May 28, 2021 at 12:27
  • 1
    I up-voted because many here in lala land thinking everything is gumdrop and lollipops. Though as a first offense, this is a bit harsh.
    – paulj
    Commented May 28, 2021 at 13:25
  • Quite an interesting strategy. Sadly, I could see my boss doing something like this.
    – DJG
    Commented Jul 28, 2021 at 22:04

You must log in to answer this question.

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