When Your Boss Calls You a Responsibility Shifter: Lessons on Communication and Leadership

Yesterday a company meeting ended with the boss bluntly stating that efficiency was low, output unclear, and results invisible, and announcing an hourly reporting system. As the sole R&D engineer, I sensed part of the criticism was aimed at me.

After the meeting, the boss told me, “You like to shift responsibility.” I initially resisted, believing I was responsible and never avoided blame. Later I realized the boss’s point was valid, but his definition of “shifting responsibility” differed from mine.

I Thought I Was Being Responsible

Our projects often involve outsourced partners. I assumed that because the company paid for services, the outsourcers should fulfill contractual deliverables—fix bugs promptly, provide interfaces on time, cooperate in integration, and give clear plans for delays.

BUG should be fixed promptly;

Interfaces should be delivered on schedule;

Integration issues should be actively coordinated;

Project delays should come with explicit plans.

When outsourcers stalled, I felt urgent because the company suffered: project delays, reduced customer experience, and overall impact on the business. I kept pushing, sometimes arguing with the outsourcers, believing I was acting from the company’s perspective.

I was standing on the company’s side of the problem.

The Boss Saw Something Else

The boss asked, “Why isn’t the project progressing?” My typical answer listed the outsourcers’ shortcomings—no bug fixes, no cooperation, no interface delivery. Those statements were factually true, but from the boss’s viewpoint they sounded like I was blaming others for the lack of progress.

Project isn’t moving forward. You’re telling me it’s someone else’s problem.

Thus he concluded I was shifting responsibility.

Realizing the Communication Gap

The issue lay not in the content but in the order of presentation. My previous logic was:

Problem
↓
Responsible Party

e.g., “The project is delayed because the outsourcer didn’t cooperate.” The boss wanted to hear:

Problem
↓
What I’ve Done
↓
Next Steps
↓
Support Needed

For example:

Current blocker: outsourcer’s interface is delayed. I have already: Prompted twice; Provided integration documentation; Synchronized risk updates; Adjusted development order. If the interface is still unavailable tomorrow afternoon, I will use mock data to continue development. If delays persist, I will request organizational assistance to coordinate.

Although the underlying issue remains the same, the presentation changes the perception dramatically.

Technical vs. Managerial Mindsets

Many engineers think: “Who’s at fault, who’s responsible.” Managers and project leads think: “Who’s accountable for the result, who drives the solution.” There is no right or wrong—just different viewpoints.

Technical executor says:

Outsourcer didn’t provide the interface, so I can’t proceed.

Project lead says:

Outsourcer’s delay is a project risk. I have taken mitigation steps; if it continues, I need resource support.

This shift in perspective was a major learning moment.

Responsibility and Authority Must Match

It’s unreasonable to expect a single engineer to bear full result responsibility without having authority over outsourcing choices, payment, assessment, or resource allocation. The mature expression is:

I have completed all actions within my scope, the issue is now an external dependency risk, and further progress requires organizational support.

Key practices: assume responsibility, demonstrate action, clarify boundaries, request support—none can be omitted.

Common Pitfalls for Engineers

1. Explaining reasons instead of driving results

Bad: “Outsourcer didn’t give the interface.”

Good: “I have pushed the integration to X level.”

2. Equating workload with value

Bad: “I wrote many interfaces.”

Good: “I delivered these business outcomes.”

3. Trying to prove you’re not wrong

Bad: “This isn’t my problem.”

Good: “Here are the efforts I’ve made.”

4. Turning communication into debate

Bad: “I’ve done a lot.”

Good: “How can others perceive this value?”

Conclusion

Looking back, the boss’s comment “You like to shift responsibility” isn’t entirely accurate, yet I acknowledge my communication and problem‑driving style need improvement. Technical ability sets the lower bound; communication, coordination, and driving ability set the upper bound. From engineer to leader, from writing code to delivering results—this is a lesson every technical professional must face.