What We Talk About When We Talk About Work Responsibility

This post is an AI translation of the Chinese original. If there are any discrepancies, the Chinese version takes precedence.

It’s been a long time since I got into the weeds of running day-to-day projects on the front lines as a “technical manager.” But over the past couple of days, a few things in our project group dragged my mind straight back into the nitty-gritty details of how people collaborate.

I can’t say whether my view is entirely “politically correct” in today’s workplace climate, but it reflects my honest confusion and reflection: In a team without punishing overtime and with a reasonable workload, why has talking about basic “professional responsibility” become such a luxury?

01. “Compliant Self-Preservation” Is Dragging Conscientious People Down

It started with two colleagues on the project.

Colleague A and Colleague B jointly handle Business Line 1, while B also covers Business Line 2. Over the last two days, A went to the project manager (PM) on the verge of tears. A’s feedback was blunt: B hasn’t carried any real share of the work on Line 1 for quite a while, always finding excuses when approached. Even when B did deliver something, the quality was so sloppy that most of the cleanup fell right onto A. Because A is naturally conscientious, A ended up shouldering a crushing workload and was completely exhausted, mentally and physically.

The PM’s take was that Line 2 had run into sudden issues recently, leaving B stretched thin. With limited staffing, the PM felt powerless too.

I know B reasonably well. In past collaborations, he’s always been someone who guards his personal rights fiercely and protects his time off at all costs. But from an outside perspective, he clearly lacks any sense of overall ownership. His work sits perpetually on the passing line—he won’t completely drop the ball, but he’ll never deliver anything others would rate as “good,” let alone “exceeding expectations.”

As part of my job, I sat down with B for an hour-long, candid 1-on-1. It was an exhausting back-and-forth: I laid out my concerns plainly, he countered point by point, and in the end we rearranged the workload. B’s arguments followed a very familiar script:

• “You think I look free during the day? That’s because I learn fast and get things done fast on my own time.”

• “I’ve actually put in plenty of overtime you don’t see; I just haven’t brought it up.”

• “Taking time off is my legal right. Is taking leave a crime now?”

• “Line 2 takes up a ton of my energy. Besides, Line 1 never reached out when they hit roadblocks. I asked once and nobody replied.”

After the conversation, I second-guessed myself for a while: Was I being unfairly harsh on him through tinted glasses?

No. On paper, under labor laws, company policies, and even bare minimum performance reviews, you couldn’t find a single procedural flaw in any of B’s arguments. Everything was fully compliant. But teamwork is never just about legal clauses; it’s about holding a collective balance.

With no forced overtime and an eight-hour day that easily covers the scope of work, the reality is brutal: When one person does only 80% of their job—or skims by at a bare 60%—the remaining gap inevitably gets dumped on someone conscientious, who ends up carrying 120% to keep things afloat.

Stepping in for a teammate in a pinch is camaraderie. But covering for someone else’s chronic neglect over the long haul is a systematic penalty on the responsible person, and the fastest way to poison team morale. As the old saying goes, “people don’t worry about scarcity, they worry about unfairness.” In the workplace, the most damaging inequities hide right behind the shield of “compliance.”

In the end, I had no procedural grounds to accuse him of not working. I just left him with one thought: If you’re ringing the bell for the day, you at least need to ring it properly.

02. Can Engineers Not Talk Without a Babysitter?

Then came the second incident.

B submitted a leave request. It was his right, so I approved it without hesitation. But the timing couldn’t have been worse: the issues on Line 2 weren’t resolved yet, and the project was staring down a tight delivery deadline.

The PM came over, hesitating before blurting out: “B is on leave, but Colleague C’s module is upstream from B’s, and now they’re stuck. C and D heard that I’m also planning to take leave soon, so they suggested just putting everything on hold until I get back. But my return date is the deadline… Maybe I should cancel my leave.”

I felt a deep sense of helplessness.

Even with B away, C and D were capable engineers working on complete pieces of the puzzle. Why would two professionals, facing a clear dependency between their work, conclude that “if no coordinator is babysitting the room, nothing can move forward”?

Engineers are supposed to be natural problem solvers. Yet somewhere along the way, some have regressed into assembly-line wrench turners: unless someone blows a whistle right beside them, they won’t even glance at the next station.

03. 200 Lines of Quick Code and the Baseline of Engineering Ethics

Today, B was already on leave at home. To his credit, he handled the bare-minimum handover by organizing the responsibilities for Line 2 into a detailed doc for me. C and D also finally spelled out where the blockage was: C processes and stores the data, B’s program consumes it, and D helps deploy the environment.

I had to open my long-neglected IDE and dig through C’s code myself. There were no fatal logic bugs, but the server resource planning and configurations were a mess. I walked C and D through the initial deployment verification. At the same time, I planned to use B’s doc to guide C and D through integration and rollout while B was out—if it was just a config and resource issue, we could solve it ourselves instead of waiting around for the deadline to crash over us.

During this process, I ran into another clash over what “responsibility” means.

The service C owns was burning excessive compute power, entirely because of legacy baggage left behind by an overseas team with a bloated, chaotic architecture. I suggested C take this opportunity to use solid object-oriented patterns and write a lightweight, standardized framework so we could onboard future workloads easily. To lower the friction, I even used AI to sketch out a 500-line framework prototype, complete with a 100-line example.

C’s response was blunt: “Your code is too complicated. I’m not going to use it. The script I slapped together with AI is only 200 lines.”

I didn’t force my solution down his throat. From his perspective, disciplined architecture might look like “over-engineering.” But I drew a hard line: Before refactoring his way, he had to map out the system architecture using the C4 Model and explain the system context and component relationships to me clearly.

Line count has never been a measure of code quality. It’s easy to spin up a working 200-line script with AI, but if you ignore system evolution, maintainability, and edge cases, that supposed “agility” is just punting technical debt down the line to the next poor soul. Taking ownership of the code you ship is just as much a part of basic engineering ethics.

04. Who Is Forcing the Conscientious to Become the “Overachievers”?

Working my way up from an individual contributor to middle management, I’ve always kept a fairly lenient yardstick:

• If someone genuinely gets 80% of their assigned scope done well, they’re already a “reliable” teammate in everyone’s eyes.

• If they consistently hit 100%, they’re a respected professional.

• Only those who push to 120%, constantly stretching boundaries and aiming for the best possible outcome, qualify as what people loosely call “overachievers.”

In our current management setup, we don’t squeeze people’s hours, and our delivery timelines are generous by any standard. What frustrates me is why some people immediately drop their personal bar to a bare-minimum passing grade. Nobody wants to take an extra step, or even aim for a 75.

This brand of self-serving minimalism is, at its core, a systematic exploitation of the people who actually take pride in their craft and care about their work.

Nobody in the workplace is born wanting to be an “overachiever.” Most of the time, the exhausted “core contributors” are just stuck cleaning up other people’s messes, forced to fill that floating 40% void until circumstances turn them into reluctant martyrs.

True professional ownership is not some high-minded moral guilt trip, nor is it staying late just to flatter your own ego. It’s simply the most basic contractual spirit: Deliver solid, defensible work within your own domain, and take half a step forward where workflows intersect.

When a team mistakes “looking out for number one” for high EQ, and dresses up apathy as “setting boundaries,” the project timeline isn’t the only casualty. The real damage is done to the reliable people who care, who see what needs doing, and who carry a spark in their work. And for a manager, failing to build a system that weeds out this mediocre evasion—failing to protect the people quietly holding everything up—is the greatest failure of all.