When Should You Tell Your Manager A Developer Is Struggling?

Dev Leader Weekly 149

Jul 20, 2026

TL; DR:

Raise concerns early, without jumping to termination
Coaching needs observations, support, and follow-through
Managers remain accountable for the whole team
Join me for the live stream (or watch the recording) on Monday, July 20 at 7:00 PM Pacific!

When Should You Tell Your Manager A Developer Is Struggling?

I came across a question from a team lead who had been coaching a junior developer for roughly 20 months. Progress had been difficult, and from the team lead’s perspective, the developer had actually started moving backward. They were less proactive, still needed a lot of direction, and did not seem to be responding to the coaching.

The question was basically: When should I tell my manager this is not working?

My immediate reaction was that this conversation should have started much earlier. But I want to be extremely clear about what I mean by that.

Raising awareness early does not mean asking your manager to terminate someone early. It means sharing what you are observing while there is still time to understand the problem, adjust the support, and give the person a fair opportunity to improve.

You can check out my full thoughts on this in the video below:

Raising Awareness Is Not A Verdict

Some people hear “I need to tell the manager” and immediately translate that into “I am trying to get this person fired.”

Those are not the same thing.

A useful conversation with your manager is not:

“This developer sucks.”
“They are never going to make it.”
“We need to get rid of them.”

Those are conclusions. They skip over all the information your manager actually needs.

A better conversation sounds more like this:

Here is the work the developer has been trying to complete.
Here is where they are consistently getting stuck.
Here is the coaching or support I have already tried.
Here is the progress I expected to see.
Here is the trajectory I am seeing instead.
Here is where I need help.

That distinction matters because feedback is deeper than a single verdict. If all you provide is a label, your manager cannot tell whether the issue is skill, unclear expectations, poor coaching, team fit, missing context, or something else entirely.

Actionable Tip: bring observations, not character judgments. Describe what happened, what support was attempted, what changed, and what you need from your manager next.

There Is No Magic Ramp-Up Number

The Reddit discussion had people at both extremes.

Some people claimed they could tell within a week whether a developer was going to work out. Other people pushed back and said new hires need months before anyone should be concerned.

Honestly? I do not believe there is one magic number.

A junior developer learning their first professional codebase is in a different situation from a senior developer joining a familiar domain. A new graduate may need help learning how work moves through the team. A transfer may know the company but not the product. Someone may be technically capable but completely lost in the domain.

The important signal is not whether they reached full productivity by an arbitrary date. It is whether you can see a reasonable trajectory.

Are they asking better questions? Are they retaining what they learned? Are they taking on slightly more responsibility? Are the same blockers repeating without any change? Does the support they need seem to be increasing instead of decreasing?

You may not know the answer after one week. But if you have worked closely with someone for a few weeks or a couple of months and the trajectory concerns you, that is enough reason to share what you are seeing.

You do not need certainty before you communicate.

Your Manager Should Not Be Surprised

If I pair a new developer with a team lead, technical lead, intern buddy, or another engineer, I still expect to check in.

How is the new person doing? Where are they getting stuck? What is going well? Does the person helping them need anything from me?

I do not need a formal performance report every few days. I do want enough communication that the next conversation makes sense.

If a team lead tells me after several months, “This person is not working out,” and that is the first concern I have heard, my response is going to be: Wait, what happened?

The concern may be completely valid. But now we have lost months where we could have changed the coaching, clarified expectations, or added support.

Regular check-ins are one reason I care so much about helping people make the most of their one-on-ones. These conversations should surface small signals before they become enormous surprises.

Actionable Tip: give your manager lightweight progress updates. “Going well,” “still learning this area,” “we are trying a different approach,” and “I need help” are all useful signals.

Clarify What Your Lead Role Actually Owns

“Team lead” and “technical lead” can mean completely different things from one company to another.

In one organization, a lead may be expected to actively coach developers, adjust how work is delegated, and drive onboarding. Somewhere else, the lead may own technical direction while the manager handles nearly every people-related concern.

This ambiguity is one of the mistakes new managers and leads can make. Everyone assumes they understand the role, nobody states the boundaries, and important work falls into the gap.

If you are the lead, ask your manager:

What coaching do you expect me to handle directly?
What kinds of concerns should I raise immediately?
How often do you want onboarding updates?
What decisions can I make without checking first?
What support can I ask you to provide?

You should feel empowered to help. You should not quietly inherit full responsibility for another employee’s performance without the authority, context, or support to handle it.

Do Not Just Drop The Problem And Walk Away

There is another failure mode here.

You tell your manager, “Bob is not ramping up very well.”

Then... nothing happens.

Did you expect the manager to take over? Did the manager expect you to keep coaching? Is someone changing the plan? Does the developer even know what they need to improve?

Raising awareness without agreeing on a next action is not enough.

Depending on the situation, the next step might be:

Pairing the developer with someone else for a different perspective.
Giving them a smaller, better-defined area to own.
Spending more time on domain context instead of only code.
Setting clearer expectations for initiative and communication.
Having the manager join a coaching conversation.
Identifying training, documentation, or tools that are missing.
Checking whether the team or role is simply a poor fit.

The point is not that every struggling employee can be turned around. Sometimes the role will not work out. But if the only action is repeatedly saying “they are struggling,” nobody is actually helping.

Make Sure The Coaching Is Not Part Of The Problem

Managers often hear different versions of the same situation.

The junior developer says, “Things are going well. I hit a few blockers, but I am working through them with the senior developer.”

The senior developer says, “This person takes no initiative. I have shown them this five times and they still cannot do it.”

So what is actually happening?

Maybe the junior developer is disengaged. Maybe they are not retaining information. Maybe they are afraid to ask questions. Those are all possible.

But maybe the senior developer’s idea of coaching is screen sharing, clicking every button, writing all the code, and saying, “Watch what I do.” Then they are frustrated when the other person cannot reproduce the process alone.

I have written about how senior developers can accidentally make learning harder, especially when expertise makes the difficult parts feel obvious. Watching an expert move quickly is not the same as practicing the skill.

Actionable Tip: let the learner drive. Have them share their screen, choose the next step, explain what they think is happening, and ask for guidance when they get stuck. It may feel slower, but you can finally see how they reason.

Technical Aptitude Might Not Be The Whole Story

When someone seems unmotivated or passive, it is easy to jump straight to a personality judgment.

Sometimes that judgment is wrong.

Maybe they do not understand the domain well enough to know why the work matters. Maybe every task feels like an isolated technical request with no connection to a user or business outcome. Maybe they are overwhelmed by the codebase and trying not to expose how lost they feel.

Managers and leads often say, “There are no stupid questions. Ask anything.”

I genuinely mean that when I say it. But I also understand that new employees may still worry about looking unqualified in front of their manager. Pairing them with another engineer can create a safer place to ask those questions and build confidence.

That is part of why a manager needs multiple perspectives. Talk to the developer. Talk to the person coaching them. Look at the work. Ask what each person has tried. Do not assume one story gives you the complete picture.

Accountability Still Belongs To The Manager

As a manager, I can delegate pieces of onboarding. I can ask a senior engineer to be an intern buddy. I can give a team lead room to coach someone and adjust the day-to-day approach.

I cannot delegate away my accountability for the team as the manager for the team.

At the end of the day, the manager is responsible for making sure employees have clear expectations, appropriate support, useful feedback, and a fair process when performance concerns exist.

That does not mean the manager personally performs every coaching session. It means the manager remains engaged enough to understand what is happening and act when the team needs help.

This is where accountability without sliding into blame matters. The goal is not to decide which person deserves to be attacked. The goal is to understand the system, clarify ownership, support improvement, and make a responsible decision.

A Practical Way To Escalate The Concern

If you are a lead and you are worried about someone’s progress, you do not need a dramatic speech.

You can use a simple structure:

State the observation. What specific behavior or outcome concerns you?
Describe the trajectory. Is it improving, flat, inconsistent, or getting worse?
Explain the support. What coaching, pairing, documentation, or context have you tried?
Share the impact. How is this affecting the developer, the work, or the rest of the team?
Ask for help. What do you need the manager to clarify, provide, or decide?
Set a checkpoint. When will you compare notes again?

That might sound like:

I have been pairing with this developer on the deployment workflow. They can complete the steps with direct guidance, but they are still unable to complete the same workflow independently, and the same questions are repeating. I have tried written steps and two driver sessions. I would like your help understanding whether we should change the coaching plan or clarify the role expectations. Can we check in again after the next two tasks?

That is specific. It leaves room for investigation. It creates an action. And it does not pretend you know the final outcome before the manager has even joined the conversation.

Earlier Communication Can Be Kinder

Waiting can feel compassionate because you do not want to get someone in trouble.

But silence is not always kind.

If the developer needs different coaching, earlier communication helps them get it. If expectations are unclear, earlier communication gives the manager time to clarify them. If the team is a poor fit, earlier communication creates more options. If a formal performance process eventually becomes necessary, the concern should not appear out of nowhere after nearly two years.

The time horizon for raising awareness is much shorter than the time horizon for giving someone a fair opportunity to improve.

Those ideas are not in conflict.

You can communicate early, coach patiently, gather better information, and avoid rushing to a conclusion. In fact, early communication is what makes that patience more responsible.

The Question Is Not “When Do I Give Up?”

The better question is: When do I create enough visibility for the right support to happen?

My answer is early and regularly.

Do not wait until you are completely frustrated. Do not turn one difficult week into a permanent label. Do not hide the concern for 20 months and then hand your manager a final verdict.

Share the signal. Ask for help. Agree on the next step. Keep checking the trajectory.

Maybe the developer turns things around with better coaching. Maybe they thrive on a different team. Maybe the role ultimately does not work out. You cannot know that from the first concern.

What you can do is make sure the concern is handled with clarity, accountability, and enough time for people to respond.

If you have a software engineering or career question, leave it in the video comments or submit it anonymously at codecommute.com. I would love to hear how your organization divides coaching responsibilities between leads and managers.

Dev Leader Weekly

Discussion about this post

Ready for more?