Handling Low Performers Without Becoming the Manager

A practical guide to protecting project outcomes when you don’t manage people

At some point, most senior engineers run into this tension:

Someone’s work is slowing things down. And the outcome is at risk.

Getting things done requires multiple follow-ups. Questions keep flowing back to you. You start spending more time helping them.

You’re not the manager. What should you do next?

It’s tempting to label this as “low performance,” and escalate. Right?

Not so fast!

When you frame the issue as performance, your options feel political. On the other hand, when you frame it as risk, your options become practical.

This is where senior engineers think differently.

Think First: Is It Low Performance?

Starting With Labels Won’t Work

Calling someone a “low performer” feels efficient, but it narrows your thinking too early.

Once you attach a label, the situation becomes personal. Conversations turn defensive. And before you know it, you have moved away from solving the actual issue.

Experienced engineers avoid this. Early labels rarely improve outcomes.

Reframe the Problem as Delivery Risk

A more useful frame is this:

Performance issues are risks to outcomes, not judgments about people.

Instead of asking “What’s wrong with this person?”, ask:

• What outcome is at risk?

• Where is the quality issue?

• What issues keep coming back to me?

This keeps the discussion grounded in facts. It also gives you room to act without needing authority over the individual.

Don’t Escalate Too Early

Escalation is the most common instinct here.

If you’re not the manager and something feels off, it’s tempting to escalate and move on. It feels responsible: someone else owns people management.

The problem is timing.

Escalating too early often backfires. You raise a vague concern without clear evidence. From the outside, it sounds like frustration. That’s when escalation turns political.

Senior engineers treat escalation as a last resort, not a first response.

Early Signals Senior Engineers Pay Attention To

Work That Always Needs Follow-Ups

Occasional follow-ups are normal.

The real sign is that you constantly have to remind someone to finish work. In addition to the cost of time, it also increases your cognitive load. You start tracking their tasks in your head.

It is a quiet form of compensation.

That’s an early warning sign.

Issues Always Escalate Back to You

Questions that should have been resolved by someone else keep coming back to you.

Small decisions. Edge cases. Things that they should have handled by themselves.

It usually means either expectations are misaligned, or someone is avoiding making decisions under uncertainty.

You Start Compensating Without Noticing

This is a hidden but big red flag:

• You rewrite parts “just this once.”

• You need to double-check everything.

• You unblock dependencies yourself because it’s faster.

At that point, expectations need to be revisited.

The Solution Ladder: Step by Step

OK. Now it’s the important part. What do you actually do?

Here’s a list of actions you can take to reveal the problems before you escalate.

Think of this as an ownership ladder. You climb it one step at a time. If a lower step works, you don’t need the higher ones.

1. Make the Outcome Explicit

Start by removing guesswork.

Be specific about:

• What to deliver

• When to deliver

• What quality level you expect

This often means translating vague requests into concrete outcomes.

“Can you move faster?” is vague.

“We need to deliver by X, so please send your PR by Y” is clear.

2. Narrow the Scope Before Judging

Before assuming someone can’t do the work, check whether the work itself is too ambiguous.

Ask:

• Is the task too vague?

• Is dependency clear?

• Is success defined?

If the scope is fuzzy, shrink it. Break the work into smaller pieces with clearer checkpoints. Many “performance” problems disappear once the problem is constrained.

This helps pinpoint where the problem is.

3. Create a Short Feedback Loop

Long feedback cycles hide problems. Short ones surface them early.

That means:

• Smaller deliverables.

• Earlier reviews.

• Clear definitions for what “good” looks like at each step.

It helps both sides to see reality sooner, while there’s still time to adjust.

The goal is risk management

4. Decision: Contain or Escalate

At this point, you have information. Now you choose deliberately.

Consider:

• How critical is the outcome?

• How reversible is the risk?

• How much time do you have?

Your options:

• Contain: Narrow scope or add guardrails. Move on.

• Escalate: Report risks with evidence, and your recommendation.

Escalation here is to focus on achieving outcome, instead of handing over problems.

But whichever option you go for, you always share your findings with your manager.

Ownership Anti-Patterns

Absorbing the Work Silently

Most of the time, it’s faster if you fix it yourself.

You don’t say anything because it feels efficient.

But in fact, this keeps delivery moving in the short term, but it trains the system to rely on you as a safety net. Over time, you become the bottleneck and the risk increases.

Escalating Without Evidence

Raising concerns without proofs shifts the focus. It becomes an opinion.

❌ “I feel this person is underperforming” does not explain anything. Your manager needs to guess.

✅ “Here’s what’s blocked, what I tried, and what decision is needed” is clear.

Ownership requires preparation. Escalation without context weakens trust.

Turning It Into Mentorship Too Early

Not every delivery issue is a mentorship opportunity.

Jumping into mentorship mode too early can blur boundaries and create extra workload for yourself, especially when you’re not the manager.

Focus on stabilizing outcomes. Growth conversations can come later.

Last Words: Ownership Without Authority Is a Career Skill

Handling these situations well comes down to ownership.

Senior engineers don’t wait for titles to protect outcomes. When delivery is at risk, they step in to create clarity and surface problems early, even when the people involved don’t report to them.

Over time, people start to rely on you in ambiguous situations. You’re trusted with broader scope and more complex problems.

This is how seniority shows up in practice.

Develop that skill, and the role tends to follow naturally.

---

That’s it for today.

If this way of thinking resonates, I write about senior-level mindset, ownership, and career growth for engineers every week.

I’ll see you in the next post.

Adler from Tokyo Tech Lead