Years ago, I attended a leadership workshop at a previous company. We were discussing empathy, adapting to different personalities, being patient, and understanding what people needed from us.
At some point, one of the leaders asked: “Okay, but why only us? Why are we the only ones expected to change?”
I remember thinking he had missed the point. Of course we should adapt. We were the leaders. We had accepted roles that required more patience, better communication, and the ability to work with different people.
But I never quite forgot his question. Over time, I started to understand it differently.
He was questioning an expectation I had accepted without much thought: whenever a working relationship struggles, the leader should become more understanding, more adaptable, more skilled. The expectations placed on the other person barely enter the conversation.
Today, I think his question deserves a serious answer. It also raises a bigger one: what actually makes someone a good leader when the people, resources, and conditions they work with are far from ideal?
The problem with judging leadership by results alone
We tend to describe good leaders through familiar qualities: empathy, clarity, confidence, charisma. Those qualities matter. They tell us something about how a person interacts with others, but much less about the quality of their decisions in difficult circumstances.
One manager inherits experienced engineers, stable priorities, and a product people understand. Another inherits capability gaps, unresolved conflict, and commitments made before anyone checked whether they were achievable.
If the first team delivers more, how much does that tell us about the two managers?
Results matter. A leader cannot spend years talking about good intentions while nothing improves. But results need context: the starting point, the authority available, the decisions made, and the direction of change.
There is also a less visible question: what is producing those results?
A team may deliver because people understand their work and take responsibility for it. It may also deliver because the manager quietly corrects every weak decision, chases every commitment, and finishes whatever remains incomplete.
From a distance, those teams can look equally successful. Their ability to sustain that performance is very different.
When helping hides the actual performance problem
Imagine an experienced engineer whose work repeatedly misses agreed quality standards. Important cases go untested, familiar problems return, and incomplete work arrives at review too late to correct comfortably.
Their manager discusses specific examples, explains the expected standard, arranges mentoring, and protects time for learning. They check whether the workload is reasonable and whether requirements are clear. The engineer understands what needs to improve.
Months later, the same issues keep appearing.
The manager begins rewriting parts of the implementation before release. They anticipate the missing tests, correct the design, and chase the dependencies. Eventually, they start doing this before anyone else notices a problem.
Delivery improves. The engineer appears to be performing. The manager gets praised for being hands-on.
But the organisation is now planning around a misleading picture of capacity. Some of the engineer’s apparent contribution depends on another person repeatedly completing their responsibilities.
That arrangement has consequences beyond the manager’s workload. The performance problem becomes harder to address because the evidence keeps disappearing. The engineer receives mixed signals: the feedback says improvement is needed, while completed delivery suggests everything is working. Stronger colleagues see that some people’s commitments are routinely covered for them.
A leader who keeps making someone’s performance look better may be making the underlying problem harder to solve.
There are legitimate reasons to intervene. A critical release may need immediate help. Someone dealing with a difficult personal situation may need temporary cover. The question is what happens afterwards: is the intervention acknowledged, is the underlying gap addressed, and is there a plan for reducing that dependence?
Without those things, an exception becomes an expectation.
Diagnose the gap before deciding who should act
“Underperformance” describes a gap between expectations and what happens. It does not explain the cause. Before assigning responsibility, a leader needs to understand that gap.
I would separate three possibilities.
1. The conditions make good performance unrealistic.
Priorities change constantly. Decisions wait in approval queues. Requirements conflict. The team is expected to deliver work that exceeds its capacity.
Here, pushing individuals harder will accomplish very little. The leader needs to improve the conditions, resolve trade-offs, and challenge commitments that cannot be met. A missing environment or unresolved dependency does not become an engineer’s attitude problem because the deadline is approaching.
2. The person does not yet have the required capability.
Someone may understand the expectation and be willing to meet it, but lack the skills or experience. The response might involve mentoring, narrower scope, examples, practice, and more frequent feedback.
The important question is whether capability develops. A course invitation or an assigned mentor is not sufficient evidence that support worked. Look at what the person can now handle, what still requires help, and whether progress is reasonable for their role and the complexity involved.
3. The person is not meeting responsibilities they understand and can reasonably fulfil.
Someone repeatedly ignores agreed feedback, leaves known problems unaddressed, or fails to raise foreseeable risks despite having the information and opportunity to do so.
We should be careful about claiming to know someone’s motivation. We can, however, address observable behaviour. A leader does not need to prove that someone “doesn’t care” before holding them accountable for repeatedly missing a clear expectation.
These situations can overlap. They still require different responses. More coaching will not fix every organisational constraint, and more empathy will not resolve every refusal to take responsibility.
Support does not transfer ownership of the job
Once expectations are clear, conditions are reasonable, and meaningful support has been provided, the individual remains responsible for doing the work.
That includes applying feedback, developing missing skills, communicating risks, and taking agreed commitments seriously. When a commitment becomes unrealistic, ownership includes raising that early and helping renegotiate it. It does not require pretending that every estimate was a promise carved in stone.
Leaders do not have to exhaust every imaginable intervention before accountability becomes legitimate. There will always be another course, another explanation, another communication style someone could suggest.
The test is whether the person has had a fair, relevant opportunity to succeed.
For an experienced engineer, that opportunity comes with expectations appropriate to their seniority. A senior title should mean something beyond technical familiarity. It should include judgment, collaboration, and the ability to respond constructively when work falls short.
You should not need to remind a senior engineer indefinitely that they must test their changes, communicate a blocker, or follow through on something they agreed to own.
And code review itself is not micromanagement. Challenging a design, rejecting work below an agreed standard, and giving concrete feedback are necessary parts of engineering. The distinction is whether the engineer remains responsible for thinking through and making the correction, or whether the manager repeatedly takes that responsibility away.
The leader owes them a fair chance. The engineer owes the team a serious response to it.
If improvement does not follow, the next step may be a change in responsibilities, a formal performance process, or a decision that the role is not the right fit. Repeating the same support indefinitely is also a decision, and colleagues bear its cost.
Empathy needs to work in both directions
This brings me back to the workshop.
I still believe leaders should develop greater emotional discipline and adaptability. Their authority creates an obligation to use those skills carefully. A careless comment from a manager can carry consequences that the same comment from a peer would not.
But greater responsibility does not make the leader the only adult in the relationship.
Engineers can also be expected to consider how their behaviour affects colleagues. They can listen to feedback without requiring their manager to find a perfect combination of words before any of it becomes their responsibility. They can recognise that their manager has competing obligations and cannot be available to resolve every uncertainty immediately.
There is something uncomfortable about a version of empathy that treats experienced professionals as though they have very little agency. We recognise their expertise when assigning important work, then behave as though their communication, effort, and response to feedback are almost entirely products of their manager’s skill.
Respecting someone includes taking their ability to choose and act seriously.
Personal circumstances still matter. Support, temporary adjustments, and appropriate accommodations can be essential. But those should lead to an explicit agreement about what is reasonable now, rather than leaving one person’s responsibilities permanently and silently distributed across everyone else.
What if the organisation refuses every realistic option?
Now take the harder case.
The manager has improved the process, clarified standards, provided support, and addressed the performance gaps. Some limitations remain. They ask for additional capacity, changes to team composition, or an adjustment to scope.
Senior management rejects all three. There is no budget, no replacement available, and the deadline has already been promised.
What does good leadership mean now?
The manager still has work to do. They must prioritise, protect essential standards, communicate the likely outcome, and keep pursuing workable options. But they cannot create capacity through personal obligation.
An escalation needs to make the decision concrete:
“With the current team, we can deliver A and B by the deadline. Including C requires moving the date or adding the capability we discussed. My recommendation is to defer C. If we keep everything, the likely consequence is a missed deadline.”
That gives leadership a choice and a recommendation. An email saying “we are at risk” is rarely enough.
If the organisation insists on the original commitment anyway, responsibility for that decision belongs with the people making it. A manager can remain accountable for how they manage the team without accepting blame for capacity they were explicitly denied.
This is particularly relevant when the manager cannot change compensation, approve hiring, or replace a contractor. We should evaluate their decisions within their actual authority.
Quietly working extra hours may rescue the immediate commitment. If that happens repeatedly, leadership receives evidence that the original demand was reasonable. The cost has simply been kept out of view.
Making limits visible does not require allowing preventable harm. It requires honest forecasts, explicit trade-offs, and clear reporting of the additional intervention needed to deliver.
A fairer way to judge a leader
There is a philosophical problem here: we often judge people by outcomes they influence but do not fully control.
A leader can make a sound decision and still get a disappointing result. Another can make a poor decision and benefit from an experienced team, favourable timing, or someone else’s exceptional effort.
That does not make outcomes irrelevant. It means one outcome is insufficient to judge the quality of leadership.
I would look at five things:
Diagnosis: Did the leader investigate the actual causes, including their own contribution?
Conditions: Did they establish clear expectations and address obstacles within their authority?
Development: Did their support help people build capability, with visible progress or a timely recognition that it was not working?
Accountability: Did they follow through when reasonable expectations continued to be missed?
Honesty: Did they make capacity, risks, and the true cost of delivery visible to the people making decisions?
Then I would examine results over time: what improved, what remained stuck, and whether the team became more capable or increasingly dependent on the leader.
This is a demanding standard. A supportive personality alone will not meet it. Neither will good delivery numbers sustained by endless personal intervention.
Look at the work you keep rescuing
Choose one recurring problem that keeps bringing you back into the details.
Ask yourself:
What responsibility am I repeatedly completing for someone else?
Have we made the expectation explicit and checked that it is achievable?
What relevant support have I provided, and what changed afterwards?
Is the next action mine, the individual’s, or a decision for senior management?
Who currently sees the real cost of getting this work delivered?
The answers may reveal something you still need to improve as a leader. They may also reveal that you have been carrying a responsibility that belongs elsewhere.
Both possibilities deserve an honest look.
I still agree with much of what we discussed in that workshop. Leaders should listen, adapt, and understand the people they lead. I would now add an expectation that was missing from the conversation: the people receiving that support have obligations too.
You can be a good leader and still have someone on your team who is not doing a good job.
Your responsibility is to address that reality fairly and directly. You do not have to spend the rest of your working life making it invisible.
If you are a tech founder or senior engineering leader and too much delivery depends on you filling the gaps, this is part of the work we do in Get Out of the Loop: identifying what belongs to you, what belongs to your team, and which decisions the organisation needs to make.
Reply with LOOP if you want to explore where that responsibility has become blurred.