78

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?

ColleenV
  • 10,629
  • 3
  • 30
  • 61
riorio
  • 5,425
  • 6
  • 22
  • 38
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat. – Kilisi May 27 '21 at 02:54
  • If your role is to manage and the (leading) developer their role is to develop the application the stakeholders care about, giving estimations isn't your job, it is theirs. – Jory Geerts May 27 '21 at 08:42
  • 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 May 27 '21 at 09:26
  • 1
    @Martijn What you said doesn't contradict what I said. :) Ideally the devs estimate and OP uses that to inform the stakeholders, 100% agreed. Here, OP decided to estimate (not their job) and dev decided to inform the stakeholders (also not their job). – Jory Geerts May 27 '21 at 09:47
  • Did this create an immediate problem for you which has to be solved or is it alright if it takes a while? – Mast May 27 '21 at 10:27
  • 2
    Very culturally dependent, but maybe investigate which estimate is right rather than focusing on organizational hierarchies – Hans Kilian May 27 '21 at 12:24
  • 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 May 27 '21 at 12:34
  • 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. – Andy Lester May 27 '21 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? – Andy Lester May 27 '21 at 16:18
  • I have seen this before. Shortly after the subordinate gave the much lower time estimate, the manager was fired and the subordinate promoted into the manager's position. – user20925 May 27 '21 at 18:09
  • 1
    @AndyLester they're there to see what is happening and to support the lead. It's a normal scenario if the Lead had asked a dev for an estimation on timeframe for their portion. Contradicting the Lead is totally different. – Kilisi May 27 '21 at 20:25
  • 1
    Which country is this? There are cultural differences, and some places are more authoritarian than others. In engineering there's also the small detail solutions need to be reality-based and sometimes calling out bullshit is just necessary. – ojs May 28 '21 at 08:22

9 Answers9

145

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.

Kilisi
  • 222,118
  • 122
  • 486
  • 793
  • 2
    Nailed it. Perfect. –  May 26 '21 at 14:36
  • 2
    Perhaps a bit naive but it seems like pretending to be a uniform body on something that can be "so" subjective obfuscates the certainty with which estimates are generated. I can imagine giving a first estimate of the order of magnitude of the timeframe may benefit the client, and A "public" 1 minute exchange between two people dis-agreeing might convey a more accurate confidence in the estimate. Can you explain why this is not preferred in your experience? – a.t. May 26 '21 at 18:42
  • 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. – Stephan Branczyk May 26 '21 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. – Frank Hopkins May 26 '21 at 23:04
  • 1
    @a.t. estimates are not fungible things, but management thinks they are - if the junior dev is giving significantly lower estimates in public than the rest of the team, then all they have actually done is undermined the rest of the team and committed them to delivering. Unless, of course, the only person going to be working on anything the junior developer estimates is ... the junior developer. And then they sink or swim on their own - they have to meet their estimate. But they have still committed the team to delivering on time because thats the estimate they gave in public. –  May 27 '21 at 02:13
  • 2
    @a.t. High initial estimates give leeway for the team to adjust downward with no negative consequences. Low estimates do not give the same leeway to adjust upward. –  May 27 '21 at 02:14
  • 2
    The concern I have with this and other answers is that the dev isn’t described as “a junior dev”, which the question implies but rather “one of my leading developers”, which to me, potentially changes the situation. – Gwyn Evans May 27 '21 at 06:13
  • 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 May 27 '21 at 07:04
  • 4
    Our Dev-Team has a golden rule - the only one without exceptions: "WE DO NOT GIVE TIME ESTIMATIONS TO STAKEHOLDERS!" We have it as a framed sign in the meeting room. Kind of like a "No Credit. No pants = No Service" sign in a bar. And whenever somebody asks "How long will ..." we point to it. Now how does that work? We ask a "when do you want it finished and when do you absolutely need it finished?" date. Then we give the PO a "Go or NoGo", maybe together with a "if we do it, X and Y will come later, Z will not be able to be finished before its deadline - still do it?" – Fildor May 27 '21 at 07:55
  • Re "but he's not aware of the full picture. We have other work to do as well." The stakeholder didn't ask "when will it be done", they asked "how long will X take". Anything that is not directly related to X is irrelevant, so using this to explain why the dev gave a different number from the manager will only make the manager look bad, wouldn't it? – Jory Geerts May 27 '21 at 08:44
  • 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 May 27 '21 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 May 27 '21 at 17:26
85

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.

Flater
  • 17,529
  • 3
  • 47
  • 60
  • 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 May 26 '21 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 May 26 '21 at 21:39
15

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?

Gwyn Evans
  • 465
  • 3
  • 8
  • 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. – Bradd Szonye May 27 '21 at 04: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 May 27 '21 at 12:32
  • 1
    Being a good developer does not inherently make you good at estimating times. – musefan May 28 '21 at 10:40
13

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.

Andy Lester
  • 2,118
  • 12
  • 20
  • 6
    A curse of smartness? I would venture that managers should be striving to hire devs who are smarter than they are. – Igor G May 26 '21 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 May 27 '21 at 06: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 May 27 '21 at 10:26
  • 1
    @IgorG At least they should be smart enough to know when to keep their heads shut. – Fildor May 27 '21 at 11:13
  • 1
    This is a good, insightful answer. – Kilisi May 27 '21 at 13:20
  • @xono Stakeholders are often just people from other teams in the company, so hardly 'a third party'. – David Mulder May 27 '21 at 19:55
  • @DavidMulder: a "third party" is not exclusively reserved for people outside of the company. It literally just means another party outside of the main two in question (i.e., the manager and the dev). Also, I think you will find there are many many organisations that work directly with clients/customers who are not part of the same organisation. – musefan May 28 '21 at 11:00
  • @musefan A "third party" in business typically is "any entity that a company does business with". To be fair "third party" in this context could have been meant as 'just someone else', but if I have my manager, the sales teams managers and me sitting around a table I would have zero qualms about openly discussing the complexity of proposed work. In contrast I would understand a third party to be for example an actual customer in front of whom I would not discuss such things. It's a pity we don't use 'second party' to refer to for example a different team/department, but oh well :) – David Mulder May 28 '21 at 12:05
  • @DavidMulder Well, when talking about the relationship between the dev and the manager, literaly anyone else is third party, including the other team members. – Frax May 28 '21 at 13:48
  • @Frax I was trying to give Xono the benefit of the doubt, but if you think Xono was suggesting that it would be naive and arrogant for a subordinate to share their estimates when anybody else is present including team members then I guess that makes the comment even more crazy. Given the harsh words used I honestly think that Xono thought that stakeholders was necessarily referring to outside parties. – David Mulder May 28 '21 at 15:33
7

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.
kube_ahmed
  • 543
  • 1
  • 4
  • 9
3

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.

LastStar007
  • 138
  • 3
1

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!

usr1234567
  • 1,844
  • 10
  • 20
-1

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.

MonkeyZeus
  • 13,479
  • 1
  • 26
  • 61
  • 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 May 27 '21 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 May 27 '21 at 19:53
  • Other answers talk about firing the developer. That would lead to fear. I agree with cohesion and respect. – usr1234567 May 28 '21 at 09:36
  • 2
    @usr1234567 You should comment on the other answers then =) My answer explicitly abstains from the "fight fire with fire" mindset. – MonkeyZeus May 28 '21 at 13:32
-3

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

Mandrill
  • 147
  • 4
  • 1
    https://www.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. – Julien Lopez May 28 '21 at 06: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 May 28 '21 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 May 28 '21 at 13:25
  • Quite an interesting strategy. Sadly, I could see my boss doing something like this. – DJG Jul 28 '21 at 22:04