I'm currently a junior PM with a small team of software engineers. Some of the engineers are junior, thus I assign relatively easy tasks for them to discover different parts of the codebase.

The issue began when a member is taking too much time to finish their task. We had to postpone a task for two sprints given that'll take very few hours.

I'm not underestimating the effort since I tried to help but it seems that the person always states that he didn't understand the resources given without providing further details. I eventually kept helping to the level that it becomes more of a step-by-step guide (go there, change this...) which takes more time than it'll take me to do it.

It seems now that they're always stuck and frequently ask for a meeting for help. This made me afraid that I'm encouraging dependence.

The goal was to familiarize them with the code, thus in the meeting I mentioned that the tasks are supposed to be easy, so they're supposed to finish them by the next day and if they need help they've to contact me.

I do not want it to sound like I'm underestimating the assigned tasks or their skills. If it's not appropriate to say so given the mentioned circumstances, how could I handle this situation better?

  • 1
    Is it appropriate to say that a technical task is easy to do given that it is? It depends. Do you, who are saying this, and the person who must perform the task have the same skills and understanding? You say your are a junior PM, but seems like you are also an experienced developer. Is this easy to do from your experience level or from the junior's experience level? Do other juniors have the same difficulties, or just this junior? When they ask for help, are the questions pertinent or an indicator that they don't know what they are doing? Did you communicate expectations properly?
    – Bogdan
    Jan 29, 2022 at 16:54
  • Is there a designated tech lead for the team? Jan 29, 2022 at 17:13
  • @Bogdan I assume the task is very doable from a junior's experience level as it requires basic understanding of the tech stack. Other juniors also need assistance from time to time but they eventually manage to finish their tasks. When they ask for help, the questions are often vague and most do not come until few hours before the due date. Concerning communicating expectations, I try to clarify the tasks as much as possible, but I'm not aware if I'm missing something due to my inexperience.
    – OBezzad
    Jan 29, 2022 at 22:56
  • @AshokRamachandran we're working in a startup environment. Unfortunately, there isn't one. It may be worth adding that we're working remotely.
    – OBezzad
    Jan 29, 2022 at 22:58

1 Answer 1



Is it appropriate to say that a technical task is easy to do given that it is?

No. Unless you are the one doing the task, then it's not really yours to estimate unless you're setting a management target rather than asking for a realistic level-of-effort estimate from the task performer. Only the person doing the work can estimate how easy or hard a piece of work will be for them.

If you're not practicing agility of any kind, you are essentially assigning work, defining the level-of-effort de novo, and expecting that this externally-assigned task is "easy." Clearly it isn't for everyone on the team.

Is that because you are following the wrong framework? Because you or the team as a whole lack sufficient communications skills? Or just because of individual variation in the skill sets within the team? Those are all good questions, but they are yours (meaning the team's, collectively) to answer.

Occam's Razor

Occam's Razor suggests that this developer has a different communication or learning style than you, and may or may not be sufficiently experienced to work independently. There are pragmatic solutions to each of these problems once you have identified them as a team, but they all start with open and honest communication from the whole team. That includes both you and the developer you have concerns about.

If this person isn't sufficiently experienced or skilled enough to work independently, that may or may not still a problem for the team. Aside from the toxicity of punishing people or embarrassing them by calling them out for what you perceive as a lack of skill or experience, you are still left with the problem of what to do about it.

Possible Solutions

Ultimately, you can do some or all of the following:

  1. Work with this person to fix the ongoing communication issues.
  2. Provide training and support that fits this person's needs.
  3. Stop assigning them tasks that lead to failure, and find out how they can add value to the team within their current skill set.
  4. Determine that you have an inefficient, siloed, or broken process that doesn't lend itself to collaborative learning and then fix those things.
  5. Realize that you have T-shaped people who don't fit certain tasks, or I-shaped people who don't fit the roles you've assigned them. Then fix the team's composition or the team's ability to manage its own tasking.
  6. Admit that person isn't a good fit for this team and reallocate them to a project or team that's a better fit.
  7. Acknowledge that the organization or the team's leadership (maybe even you, as the project manager) made a bad hire, and that you have a substandard team member that can't or won't add value to the project. The hiring authority needs to own up to that, and solve that problem in an appropriate way.

While these represent a rough order of escalation, they are neither canonical nor strictly linear. You need to do some self-examination, have some conversations with your team member, engage with your entire team about the process, and engage with your senior management about what you've learned and what the options are.

If senior management decides the problem is you, you may need to brush off your resume and move on. If they decide it's a bad team fit or a bad hire, then it's up to them to define the organization's next step. Everything else in the middle is largely a team process, and is your responsibility to address even if senior leadership is ultimately responsible for poor company culture or hiring processes that leads to undesirable outcomes such as hiring inexperienced project managers or inexperienced developers while failing to address the inevitable skill gaps and process problems that generates.

If you're looking to assign blame, always start with the mirror. If you're looking to fix a process problem, always start with team communications. Beyond that, it's a people problem, and there's no silver bullet.

  • Thank you for the insightful response. Concerning the 3rd point, I usually share the sprint a day before our meeting, then we meet to discuss it and each one self-assign themself to the tasks they believe they can accomplish in one cycle. For fairness, we start with juniors to have more options then seniors. Thus, should I do more effort to make sure they know what they're assigning themselves, or is it their responsibility to ask the right questions?
    – OBezzad
    Jan 30, 2022 at 16:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.