Overview
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:
- Work with this person to fix the ongoing communication issues.
- Provide training and support that fits this person's needs.
- Stop assigning them tasks that lead to failure, and find out how they can add value to the team within their current skill set.
- Determine that you have an inefficient, siloed, or broken process that doesn't lend itself to collaborative learning and then fix those things.
- 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.
- Admit that person isn't a good fit for this team and reallocate them to a project or team that's a better fit.
- 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.
