How to manage the estimates of senior members?

Question

I am a frontend developer and I just switch both company and stack (~ 1.5 months).

The transition was smooth, I have a good relationship with my mentor and the majority of team members. I anticipated the onboarding phases and started working on the main tasks quite early.

Everything looks fine, however, I am still new to the technology and I am slower than the usual estimate provided by seniors members.

Every time we discuss some tasks and I raise some concern about the time and the effort I need, some of them keep saying "it's easy" or "it's a 5 minutes task", completely forgetting that my knowledge is not on the same level. This has happened twice already, in meeting with other people, making me upset and underestimating me.

I don't want to be rude and I usually remember them that I am new on the project, but this situation makes me feels like I am not qualified enough for this job. I already experienced this kind of imposture syndrome in my previous work, everyone seems always better than me and this is undermining my motivation at work.

I don't really know what to do. What do you think?

Answer 1

In addition to the other answers I want to make the following points.

• Something being easy and taking quite some time are not mutually exclusive, something could both be easy AND taking quite some time.
• In my experience 5-minutes-task almost don't exist. Even for the simplest bug a ticket has to be written, the solution has to be put in the development-branch and put over to production where it has to be tested. In my experience even for the simplest bugs that all takes at least 30 minutes.

Answer 2

Lots of people, when asked about something they know how to do well, will say "It's easy!", seemingly without realizing that "It's easy!" is a subjective assessment. What they mean, of course, is that it's easy for them.

And, if we're talking about software developers in particular -- it's sadly common that they're somewhat lacking in empathy and emotional maturity. So they may be even more inclined to fail to consider how something that might be true for them, might not be true for other people.

If you're speaking up in the meeting, and the estimate is getting adjusted to be realistic for you, then you're doing the important things to counter this. All that remains, is dealing with the emotional aspect.

Remember that they're only human, and that it's coming more from their own unawareness and/or insecurity than anything about you in particular, and don't let it get under your skin. Let your motivation at work be attached to your concrete, measurable accomplishments, instead.

Answer 3

This is an issue that your project manager, team leader, product owner or scrum master ought to be ensuring isn't happening.

Ideally, all tasks that belong to a team should be able to be picked up and completed by any member of that team who has the technical capability, regardless of their level or experience. (e.g. all software engineers should understand all the development tasks, all platform engineers should understand all the devops tasks, etc.)

When any team member speaks out in a team ceremony to trivialise a task, what they're really doing is preventing others in the team from being able to estimate it properly and therefore also making it harder for others to pick up that task because they've subverted the important discussion which would otherwise get into the detail of that task. It leads to potential misunderstandings with some in the team remaining in the dark about exactly what work is involved, and also leads to estimates being produced which don't have the full support or buy-in of the entire team.

The fact that some team members may have less experience should not mean that those people are left in the dark when it comes to understanding the work needed, nor that they shouldn't be involved in agreeing to estimates.

If a team is producing estimates which don't have the buy-in of those doing the work, then the whole team has a problem - Clearly, from a project/team management point of view, this is not a good situation to be in, so when it happens it means that the team as a whole has an opportunity to improve, and this should be driven by the team, but also by team/project/product leadership where possible.

One approach if you hear this happen in a ceremony is to ask for more detail from whoever calls out how easy the task is -- asking a direct question to that person along the lines of "Could you explain and elaborate on that so that I can understand the estimate?" or "What would you do to complete the task?", or even ask that their name is mentioned on the task in the context of "Speak to bob for more information" (So that someone else picking up the task knows who to go to when they need to find out what to do)

It is typically in the best interests of the Project Manager and Product Owner to ensure that everybody in a team buys-in to estimates and understands the work which needs doing. Ideally, those people should be proactively making sure that you aren't alone in needing to "battle" for others to explain what work needs to happen.

There are benefits in ensuring this doesn't happen - when that everybody in the team has a shared understanding of the work involved in a task, it allows greater collaboration and sharing of ideas during planning; a senior engineer will not necessarily always get the right estimate each time, and they may still miss out important detail or misunderstand it themselves, perhaps forgetting some of the effort (For example, time to set up their environment, impact on testing, a need to define test data/scenarios, configuration, deployment, etc.)

Answer 4

1. Set expectations with your manager. In your 1:1 talk about task X & Y. Ask him: Considering you will need to do it, with your background, what is a reasonable time frame for the task?

2. Understand that sometimes experiences people have difficultly understanding the gap a junior has. Something that is truly 10 minutes work for a senior, can be 1 day for a junior.

3. Reasonable companies and managers, when hiring juniors to a team, understand that task X will take 1 day to Tomy and 10 minutes to Alex. But at the same time, they will pay Tomy X and Alex Y.

Answer 5

Your workflow is not working (at least for you) and you need to change it. Suggest changes to your team / team lead, ideally at a retrospective meeting if you have them.

Suggest to try the following once or twice and see if it works better:

1. Projects, not tasks: You should be assigned projects which have a defined outcome / specs and a design or mock-up, but which need to be further split into individual tasks by the person responsible for them (you).
2. Breakdown: Before each project, have a breakdown meeting with another engineer (or two). Discuss how to break it down into individual tasks and any potential roadblocks or challenges to be aware of. This is also a good moment for the developer with more experience with the codebase to suggest which components can be reused or how the problem can be approached.
3. Estimation: Estimate each task separately. Use a framework like planning poker where each person secretly estimates the effort of a given task and then you reveal your votes and discuss if they're different. Typically estimations are done using abstract units of effort, but you can also use a system like 1 point = 1 day of work¹.

You should find that by assigning on a project / feature basis, you will be able to manage your tasks better. And by estimating each task, you will have an opportunity to explain why you think task A requires 5 points if your colleague thinks it's 1 point, or they might explain to you how you can approach it to make it easy.

The framework I just outlined is taken from Shape-up developed at Basecamp. Have a look at it if you want to learn more.

---

¹ This is outside of the scope of the current question, but I would generally suggest using abstract units. I mentioned workdays just because it might be easier to think about if you're first using this system.