When subordinate gives the stakeholders a lower time estimation

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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?

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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!

Answer 8

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.

Answer 9

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".