Rights and Responsibilities: The Root of Workplace Involution
# Random TalkI’ve found that workplace involution can all be traced back to an imbalance between authority and responsibility. When authority and responsibility are misaligned, a few situations tend to arise:
- Responsibility without authority: people are held accountable for results, but cannot make the decisions that affect those results. This leads to helplessness, blame-shifting, and ultimately lower quality
- Authority without responsibility: people can make decisions, but don’t have to bear the consequences. This leads to hasty decisions and a sense of unfairness within the organization
I think the most apt way to describe this situation is probably the plot of Hanzawa Naoki. The protagonist, Hanzawa Naoki, is a banker who is upright and always thinks of the bank. He detests corruption, bribery, and falsified accounts, but he always ends up facing a boss who wants to cause trouble.
There’s a scene like this: his boss hands Hanzawa Naoki a 50 billion yen financing case, but has actually been secretly colluding with Nishi-Osaka Steel. After rushing through the approval process, the boss dumps all the responsibility on Hanzawa Naoki. When he was being criticized by the review department, he said something like this (I don’t remember the exact lines):
Hanzawa Naoki: “You also bear responsibility for this loan being approved, because you were the ones who stamped it.”
Review Department: “That’s because you kept urging us.”
Hanzawa Naoki: “If a loan can be approved just because you keep urging, then getting a loan is far too easy.”
Review Department: “We respect the judgment of the front line.”
Hanzawa Naoki: “If you respect the front line’s judgment, then you wouldn’t need a review department.”
Why are authority and responsibility so important?
If employees themselves do not have to be accountable for their authority and decisions, then the quality of those decisions naturally won’t be good. For example, someone may have the authority to control the budget, but not have to take responsibility for the company’s revenue. Then when teams come to request budget, they can decide whether to approve it purely based on whether they like that team.
Development teams often run into this kind of situation too.
- Team members are responsible for increasing development speed, but when they propose improvements and are rejected by upper management, the team ends up bearing the consequences when development quality suffers
- A refactoring plan is proposed, but because upper management ignores the importance of technical debt, the development team bears the consequences. Developers have to fight fires every day and fix hotfixes
The short-term consequences of an imbalance between authority and responsibility are hard to quantify, because they mostly show up psychologically. Employees with responsibility but no authority will feel that even though they are trying so hard, nothing seems to change. In the long run, the damage is obvious: employees lose motivation to improve, and when they keep following instructions day after day, they gradually lose their sense of belonging.
In the book I read before, The Soul of Perfect Decisions, it mentioned that people who refuse to hand over authority are sinners.
Authority must come from responsibility. For example, for a boss who invests 100% of the capital, because the boss is responsible for making money for the company, they must also have 100% control. So all company decisions are ultimately up to the boss. The boss bears the risk of the company going bankrupt and not being able to pay salaries, and if the product sells well, the boss also enjoys the fruits of the company’s success. Employees do not need to bear the risk of bankruptcy, and even if the company makes money, employees’ salaries do not necessarily increase.
Many bosses often ask employees to work hard, but that alone is impossible. If you want employees to work as hard as the boss, then give them the same equity.
Conversely, designing a good reward-and-punishment mechanism makes it easier to stimulate employee growth. In machine learning, there is a concept called the objective function. The training process of machine learning is about continuously reducing the loss function and maximizing the objective function. A model will not do what you “expect” it to do; it will only do whatever makes the loss smaller.
Organizations are the same. Employees (or teams) will optimize for the behavior you actually reward, not the things you say are important.
Practical approach
It’s simple: delegation and incentive mechanisms. Delegate within the other party’s area of responsibility. For example, the development team can optimize metrics such as Infra costs, MTTR (Mean time to Repair), and iteration speed. If they meet the target, they should be rewarded, such as with a bonus, but they should also be given enough authority. For example, tool expenses within budget do not need to be reviewed and can be approved directly; do not interfere with the development team’s technical choices. If the target is not met, it’s also simple: just withdraw the reward.
See? It’s actually very simple. The clearer the reward function, the better. The reward function must be carefully considered. Suppose you set Token Usage as a performance metric; then you may end up with millions of lines of useless code.
It’s the same with Story Points. But once upper management starts overseeing these metrics, they often turn into acting. Employees will do everything they can to optimize the metrics while hiding the real situation, resulting in reports that show the team developing very quickly and generating lots of Story Points, when in reality that is not the case at all.
Many companies do not understand the importance of responsibility and authority. When there is a problem, they blame employees; when employees try to improve things, they are told everywhere that their direction is wrong; and in the end, the boss can’t stand it and steps in to do it themselves, leaving no time to focus on more important things. I think this is a struggle many middle managers and founders face.
At such times, you can start with responsibility and authority: give employees appropriate authority, and aside from major decisions being made by you, do not interfere with their decisions.
What if they fail? I think employees should be allowed to experience failure within a certain range, because only by experiencing it firsthand is growth possible. If goals and rewards are set in advance, then when failure happens, just improve next time. But if you give no authority while still making employees responsible, then when failure happens they will naturally think it’s your problem, and they will also feel frustrated because they didn’t get the reward.
So I would suggest a few directions:
- If you are an employee
- If you want to move up: proactively align with your manager on expectations, your goals, and the scope of your authority. Ask clearly what the reward is after meeting the target, and confirm what your responsibilities are
- If you want to maintain the status quo: review your work over the past few months, draw clear boundaries around your responsibilities and authority, and do not take the blame for things that aren’t yours. Mutual help among colleagues can only hold things together for a while; only an incentive mechanism can last
- If you are a manager: think about what your company’s goals are recently. What authority are you willing to give employees? What rewards are there when they achieve the goals? Do authority and responsibility match? Write it down clearly—the clearer, the better
Expectation management
Expectation management is something Denny reminded me is a very important part of career development. He mentioned that much of the disappointment in the workplace comes from a mismatch between input and output.
“I’m clearly working this hard, so why didn’t I get the reward I deserved?” Denny
I thought about it, and that’s indeed true. In the workplace, being the kind of person who does everything—filling out documents one moment, fixing bugs the next, and then handling customer complaints—may be great, but is that really what the boss wants you to do? Usually not.
Expectation management matters because it helps you understand what both sides expect from each other, so you won’t end up in a situation where you clearly did ABCDE, but your boss actually only cares about F. Conversely, as long as you do F, then the rest of ABCDE becomes bargaining material for raises and performance reviews.
Achieving a perfect balance between authority and responsibility is difficult, but within your own capabilities, I would recommend this approach: “Treat work that technically isn’t yours as if it were, and care deeply about the outcome.” For example, you are given a task: the client wants you to calculate the monthly cost of the current architecture. At that point, you can think a bit further: “Why does the client want the monthly cost?” By observing carefully, you may realize they actually want to calculate product pricing.
Then you can casually gather data like the current MAU (Monthly Active Users) and DAU (Daily Active Users), and calculate the conversion rate of registered members. Assuming the company’s target gross margin is 50%, you can use these data to infer what the pricing should be. This has a few benefits:
- If the client really wants this data, they will be very grateful
- Even if this is not the data the client wanted, since you already know it was extra work, you won’t feel shortchanged
In the workplace, you should focus more on tasks where the upside is huge if successful, but the downside is limited if you fail.
The workplace is like a stage
A recent realization I’ve had is that it feels like everyone in the workplace is acting, and more than 90% of the work is not important. In many situations, the workplace already has a script written for it, along with fixed rules, and we are all acting according to those rules. If you don’t like the rules but still have to go along with them, that is involution.
For example, the expectation management and the design of authority and responsibility mentioned in this article. As I mentioned in the article about quitting, you don’t necessarily have to play this game. You may think: why, when I see something unreasonable, can’t I proactively improve it myself instead of being forced to accept metrics I fundamentally don’t agree with?
Maybe you should also consider possibilities beyond working at a company. (Absolutely not advocating that everyone quit on the spot!)
Related Posts
- Defaults and TasteAn essay extending Wiwi’s “Default” — discussing the unwritten rules of Fukuoka escalators, how AI content takes over SEO rankings, and Voltaire’s definition of taste.
- “It Depends” Is the Phrase I Hate MostMany engineers end a discussion with “it depends.” But to me, what matters most is whether a discussion can actually move forward.
- Are You a Critic?Being a cynical critic feels great and makes you feel superior, but in the end you’ll realize it leaves you with nothing but emptiness.
- Why Company Stage MattersMany people use terms like startup, growth stage, and stable stage to describe companies, but these words are too vague to serve as useful criteria. What is this company surviving on right now? How does it grow? What is its most painful problem? If you understand company stage, you’ll know what problems you’re solving every day, and whether this company is actually a good fit for you.