跪拜 Guibai
← Back to the summary

When to Stop: Laozi's Chapter 9 as a Systems Stability Manual

Holding and filling to the brim is not as good as stopping.
Hammering and sharpening a blade cannot be kept for long.
A hall full of gold and jade cannot be guarded.
Wealth, honor, and arrogance bring calamity upon oneself.
When the work is done, withdraw — this is the Way of Heaven.

The ninth chapter of the Tao Te Ching addresses a particularly practical problem:

When should you stop?

This is very difficult.

Because we all like "a little more."

One more feature.
A slightly higher metric.
Squeeze out a bit more performance.
Prove yourself a little more.

In technology, product, and management, many problems arise not because we do too little, but because we don't know when to stop.

The system is already complex enough, yet we still want to cram in another layer of abstraction.
The product is already heavy enough, yet we still want to add a few more entry points.
The team is already tired enough, yet we still want to push for one more goal.
An individual has already reached a high position, yet they still want to grasp all the credit.

Laozi's reminder in this chapter is very direct:

When full, it becomes dangerous; too sharp, and it cannot last; hoarding too much, and it cannot be guarded; failing to retreat after success — problems often start here.

This statement, placed in today's technical world, is not outdated at all.

Chapter 9 does not speak of passive retreat.

It speaks of a mature sense of boundaries:

Knowing when to continue,
and also knowing when to stop.

First, explain the original text: When full, you should stop for a moment

"Holding and filling to the brim is not as good as stopping."

A container is already full, yet you still want to pour more in; it's better to stop.

This statement is very simple, but extremely difficult to practice.

Because "full" does not initially appear dangerous.

A fully booked requirement list means the team is important.
A feature-complete product means the product is rich.
Fully utilized resources mean high efficiency.
A fully packed meeting schedule means everyone is engaged.
Maxed-out metrics mean the team has combat effectiveness.

But from a systems perspective, fullness is not necessarily a good thing.

Fullness means no buffer.
Fullness means no retreat.
Fullness means a small change will cause an overflow.
Fullness means any sudden problem will become an accident.

A server CPU running long-term above 90% looks like full resource utilization, but a traffic spike makes it dangerous.
An R&D schedule booked 100% long-term looks like high human efficiency, but one online incident throws everything into chaos.
A product page crammed with entry points looks feature-complete, but users cannot find the focus.
A manager's schedule packed full looks very busy, but there is no time to think about truly important issues.

"Not as good as stopping" does not mean doing nothing.

It means: when the system is already near full load, the most important action is not to continue adding, but to stop and assess.

This is the first layer of wisdom in Chapter 9: Do not mistake fullness for strength.

"Holding and filling" in code: Don't write abstractions that no one dares to change

Programmers easily encounter the problem of "fullness."

Initially, it's just a simple requirement.

Later, a few more branches are added.
Later, configurations are added.
Later, for reusability, an abstraction layer is added.
Later, for extensibility, strategies are added.
Later, for flexibility, it becomes a rule engine.

In the end, the system looks very powerful, but no one dares to change it.

This is "holding and filling" in code.

It's not a lack of capability, but capability crammed so full that it becomes a burden.

For example, a coupon system.

Initially, it only supported fixed-amount discounts.

Later, it supported percentage discounts, redemption codes, member coupons, platform coupons, merchant coupons, newcomer coupons, limited-time coupons, stacking rules, mutual exclusion rules, budget control, risk control checks, and campaign delivery.

All these features might have had their rationale.

But if every addition just crams branches into the old logic, after a few years the code becomes a mess:

At this point, continuing to add features is no longer enhancing the system; it's crushing it.

A mature programmer must have a judgment:

This can no longer be crammed in.

Often, technical growth is not learning to do more complex things, but learning to call a halt before complexity swells further.

"Hammering and sharpening": Overly sharp capability is hard to sustain

"Hammering and sharpening a blade cannot be kept for long."

A knife is repeatedly tempered, making it sharper and sharper, but this sharpness cannot be maintained for long.

Because too sharp, it easily breaks. Too sharp, it also easily wounds others.

This statement, applied to technical people, has a strong sense of reality.

Some programmers are very sharp.

These people are highly capable, can quickly point out problems, and can push many things forward.

But if they remain in a state of "sharpness" constantly, side effects easily arise.

In code reviews, others dare not submit code for fear of being stabbed.
In requirement reviews, product managers dare not expose uncertainty for fear of being attacked.
In technical discussions, the team dare not propose half-formed ideas for fear of being rejected.
In management collaboration, people start to bypass this person rather than solve problems together with them.

If a person's sharpness cannot be wrapped in gentleness, patience, and constructiveness, it is hard to sustain.

The stronger the technical ability, the more one must learn to retract some of the edge.

It's not about lowering standards, but making standards that the team can catch.

For example, you can say:

Here, state and permissions are mixed together, which will be harder to maintain later. It will be more stable if we separate them.

Instead of saying:

This design is terrible.

You can say:

This requirement still has a few unconfirmed boundary conditions. I'm worried there will be operational support pressure after launch.

Instead of saying:

Your product team hasn't thought this through again.

You can say:

This solution is feasible short-term, but if we onboard more clients next quarter, we need to leave extension points in advance.

Instead of saying:

This solution is bound to fail sooner or later.

The same judgment, expressed differently, yields completely different results.

Sharpness can cut through problems, but excessive sharpness cuts through relationships.

True maturity for a technical person is not lacking an edge, but knowing when the edge should be revealed and when it should be retracted.

"A hall full of gold and jade" in products: The more features, the harder to guard the experience

"A hall full of gold and jade cannot be guarded."

Gold and jade piled to the ceiling — no one can guard it forever.

Placed in the context of products, this statement almost directly describes feature bloat.

Many products, as they grow, eventually become a "hall full of gold and jade":

Every single thing had a reason at the time.

This entry point was for conversion.
This configuration was for flexibility.
This pop-up was for a campaign.
This metric was for analysis.
This process was to accommodate a client.

But when things pile up, what cannot be guarded is not the features themselves, but the overall experience.

Users don't know where to start.
Operations don't know how configurations affect each other.
Customer service doesn't know exactly where the user got stuck.
R&D doesn't know which logic can still be deleted.
Product managers don't know which features anyone still actually uses.

Once a product becomes a "hall full of gold and jade," a very subtle phenomenon appears:

Each feature individually seems valuable, but together they lack order.

At this point, what a product manager should do most is not to continue finding new additions, but to subtract.

Which entry points can be merged?
Which configurations can be taken offline?
Which extremely rare scenarios can no longer be supported?
Which processes can be simplified?
Which metrics are just noise?
Which features exist only because no one dares to delete them?

Deleting features is harder than adding them.

Because adding features feels like creation; deleting features feels like offending people.

But if a product only ever adds and never deletes, sooner or later it will be crushed by its own "gold and jade."

A truly good product manager must have the ability to guard the main thread.

It's not about making the product have the most things, but about making the product always clear on what its most important value is.

A team running at full capacity long-term is not dedication; it's risk

"Holding and filling" also applies particularly well to teams.

Many managers like to pack the team's schedule full.

It looks like there is no waste.

But a team running at full capacity long-term is very fragile.

Everyone is delivering, but the team is not getting stronger.

Worse, full capacity causes the team to gradually lose honest feedback.

Because once everyone is very busy, people are unwilling to expose problems.

Product dares not say the requirements haven't been thought through, for fear of affecting the schedule.
R&D dares not say the technical plan has risks, for fear of being seen as uncooperative.
Testing dares not say coverage is insufficient, because the launch date is already set.
Managers dare not say the goals are overloaded, because higher-ups are still demanding results.

Finally, the system appears to be running on the surface, but internally it is stretched to the limit.

One online incident, one personnel change, one requirement change, and the entire team could collapse.

A good manager must be wary of this "fullness."

A team needs delivery, but it also needs to breathe.

Leave buffers in the schedule.
Leave recovery time for key members.
Leave windows for handling technical debt.
Leave growth space for newcomers.
Leave time for retrospectives and consolidation.

These don't look like direct output, but they are guarding the team's long-term capability.

If a manager only knows how to squeeze the team full, they might win in the short term, but they will certainly lose in the long term.

"Wealth, honor, and arrogance": After success, it's easiest to make mistakes

"Wealth, honor, and arrogance bring calamity upon oneself."

Arrogance after wealth and honor — the calamity is self-inflicted.

This statement, placed in the workplace, is very accurate.

Many people don't make big mistakes during downturns, but during tailwinds.

After a project succeeds, they stop listening to differing opinions.
After business grows, they assume all their judgments are correct.
After a technical solution works, they are unwilling to acknowledge debt.
After the team achieves results, they start looking down on other teams.
After an individual gets promoted, they start treating their position as their ability.

Success easily creates an illusion:

Since the result was good, it means I was always right.

But a good result can have many causes.

Maybe the timing was good.
Maybe the team was strong.
Maybe it was a market window.
Maybe upstream cooperation was good.
Maybe user demand just happened to explode.
Maybe luck was good, and no risks were triggered.

If a person attributes all success to themselves, it becomes very dangerous.

Because they will find it increasingly hard to hear honest feedback.

A programmer might think:

I understand this system best; don't casually offer opinions.

A product manager might think:

My judgment was right last version, so follow my lead this time too.

A manager might think:

I built this team, so my methods are fine.

A leader might think:

This succeeded in the past, so it can be replicated in the future.

This is "wealth, honor, and arrogance."

The real problem with arrogance is not the bad attitude, but that it cuts off learning.

Once learning stops, problems begin to accumulate.

"When the work is done, withdraw": After achieving, remove yourself from the center

"When the work is done, withdraw — this is the Way of Heaven."

After something is accomplished, knowing to step back — this is the Way of Heaven.

This statement does not mean quitting after finishing a task, nor does it mean not taking subsequent responsibility.

It means: when things have entered a stable phase, do not continue to occupy the center.

Many projects need strong pushing during the startup phase.

Someone needs to make decisions.
Someone needs to coordinate resources.
Someone needs to withstand pressure.
Someone needs to make quick decisions.

But after the project is running, the management style should change.

If the person in charge remains stuck in the strong control of the startup phase, the team cannot grow.

On the surface, this looks very responsible, but in reality, it prevents the system from maturing.

The modern version of "when the work is done, withdraw" is:

When the system can run, turn individual pushing into mechanism operation; when the team can bear it, turn individual decisions into team capability.

For example, after a tech lead completes a core platform, they must gradually:

Instead of forever letting all problems return to themselves.

After a product manager completes a core feature, they must also shift from "launch" to "operation and validation":

After a manager builds a team, they must also gradually shift from "personally pushing" to "building systems":

Withdrawing is not irresponsibility.

Withdrawing is making it so things no longer depend on you alone to be responsible.

Final words

The true difficulty of Chapter 9 is not "doing," but knowing when to stop piling on more.

When the system is full, make space; when the team is tight, restore rhythm; after success, hand individual pushing back to mechanisms. Being able to charge forward is certainly a capability, but being able to pull back before the critical point arrives, and making the results no longer dependent on oneself, is another, rarer form of maturity.