I Used to Manage My Team Too Tightly

When I was managing teams at a large company, I had a very strong belief about what good management should look like:

Everything should be under control.

In my mind, an ideal team worked like a train running on rails.

The schedule should be precise. Architecture and detailed design should be planned in advance. Implementation should follow the agreed direction. Ideally, very little should happen outside the plan.

At the time, I thought this was what responsibility looked like.

I had experience, so I felt I should pass as much of that experience as possible to the team. If I could help people avoid mistakes, why wouldn’t I?

Looking back, I was managing too tightly.

And it was only after I left that company, reflected on how I had managed people, and spent more time studying Taoist thought that I began to see some of the problems clearly.

There were three in particular.

1. I believed that if I managed every detail, things would not go wrong

I used to care a lot about progress.

The team had a complete project management system, and everyone’s tasks, progress, and milestones were tracked closely. Even a small delay would quickly become visible.

To keep projects on schedule, I sometimes had three or four project managers involved in tracking the team.

I liked seeing progress every day.

What was done today?

What would be done tomorrow?

How far were we from the deadline?

I wanted these things to be clear.

The same was true on the technical side.

Before implementing a feature, people were expected to prepare detailed design diagrams.

Then we would review them.

Architecture was reviewed.

Detailed design was reviewed.

Sometimes I would get involved in something as specific as how a thread should be controlled.

Code review was also taken very seriously.

If I did not have time to look myself, I would ask senior engineers to review other people’s code carefully, often line by line.

Product demos were similar.

I wanted the whole result shown clearly.

We would go through details together.

And as deadlines got closer, I became noticeably more tense.

If progress did not match the plan, or if the demo result did not match what I expected, I found it difficult to stay relaxed about it.

My logic was simple:

The more I checked, the lower the risk.

The more completely I planned things in advance, the fewer mistakes the team would make.

But the real outcome was not that simple.

Some people on the team eventually felt that they had become my hands and feet.

I thought, and they executed.

Over time, they had less room to make their own judgments.

They also became increasingly afraid of mistakes.

If progress slipped a little, people became nervous.

If the result looked different from what I expected, they became nervous.

From the outside, the team looked very organized.

There were schedules, meetings, documents, reviews, and people tracking progress.

But the whole team was tense.

I was tired too.

And the strange thing was that the work did not actually become more controllable.

Real projects do not move along a fixed railway line.

Requirements change.

Technical problems appear.

People have good days and bad days.

External conditions change.

I liked to make plans very full.

Every stage was connected tightly to the next one.

So when something unexpected happened, the effect often spread through the whole plan.

I thought I was building a train that would never leave the tracks.

What I actually built was a system that did not handle disruption very well.

Later, I started to feel that a team needs more room

After studying Taoist thought, my understanding of wu wei gradually changed.

At first, “non-action” can sound like doing less or not managing.

But when I looked back at my own management experience, I began to understand it differently.

For me, one practical lesson is this:

Some things simply do not need to be done by the manager.

The goal should be clear.

Important milestones should be checked.

If a real risk can seriously affect the outcome, the manager should step in.

But many implementation details can be left to the people actually doing the work.

Sometimes a manager only needs to ask one or two important questions.

For example:

Where is the biggest risk in this approach?

Or:

If this part fails, what is the worst outcome?

Then stop talking for a moment.

Let the person think.

In many cases, they are capable of solving the problem themselves.

And if they never get the chance to solve those problems, they do not really grow.

Looking back, one of my biggest mistakes was giving my own answer too quickly.

2. I spent too much time on details that were not actually that important

I was very afraid of missing problems.

So code reviews could become extremely detailed.

Critical code and high-risk modules absolutely deserve careful review.

But I did not always distinguish between critical areas and ordinary ones.

Even normal code could receive a lot of attention.

Senior engineers ended up spending a great deal of time checking other people’s work in detail.

Later, I began to accept something fairly simple.

If someone was hired as a qualified engineer, most ordinary code should be within their ability to handle.

And even if something goes wrong, not every mistake is a disaster.

Many parts of a system have a high tolerance for error.

A bug can be found and fixed.

If senior people spend too much time trying to prevent every small mistake in advance, the team may avoid some errors, but it also loses many opportunities to discover and solve problems on its own.

I had the same problem during product demos.

I could easily get pulled into small UI or interaction details.

Should this button be here?

Why does this interaction work differently from what I expected?

Why is there one extra step in this flow?

Meanwhile, there were often bigger questions that deserved more attention.

Does this product actually solve the user’s real problem?

Does the core flow make sense?

Why would someone want to use this?

Those questions matter much more.

But when you are focused on making everything feel “complete,” small details can easily consume your attention.

Later, I started asking one more question: Is this really a problem, or is it simply different from how I would do it?

This question changed a lot for me.

In the past, if someone used a method different from mine, my first reaction was often:

This should be changed.

Now I try to stop for a moment.

If the approach solves the problem and the risk is acceptable, does it really matter that it is different from mine?

This is also part of how I personally came to understand the Taoist idea of knowing when to stop.

You need to know when something needs more work and when it is already good enough to move forward.

I often use a phrase of my own now:

Say seven parts. Do seven parts. Leave three parts open.

This is not a line from the Tao Te Ching.

It is simply a management habit I gradually formed.

If the manager says everything, the team is left with execution.

If every step is already designed, there is very little room for other people to contribute their own judgment.

Leaving some things open gives people room to think.

And yes, that means they will sometimes make mistakes.

If the cost of those mistakes is acceptable, I now think those mistakes are part of how people develop.

3. I did not realize that my mood was also something the team had to manage

This is one of the things I understood much later.

I remember one time when someone on the team wrote a product proposal that I thought was poor.

I criticized it quite heavily.

The person ended up crying.

But at other times, I enjoyed teaching people.

I would run internal training sessions and share what I knew.

During those moments, I was probably easy to talk to and approachable.

So from the team’s point of view, I was not always predictable.

When a project was going well, I could be relaxed.

When something went wrong, especially near a deadline, my attitude could change completely.

Looking back, I remember that some people were very careful when they came to me with a new idea.

They would choose their words cautiously.

They were afraid of saying the wrong thing.

At the time, I may have thought:

I just have high standards.

Now I see that they had to think about two things.

First:

How should I solve this problem?

And second:

How is my manager going to react today?

That second question creates a real management cost.

If someone has to read the manager’s mood before expressing an idea, they naturally become more cautious.

Over time, they may stop sharing ideas that are still immature.

Saying less feels safer.

A team can become more “obedient” that way.

But that is not necessarily a good thing.

People start spending energy judging the manager instead of judging the work itself.

I later started thinking that a team also needs its own “Tao”

This is something I gradually developed after leaving that role and reflecting on Taoist ideas.

When I say a team should have its own “Tao,” this is my modern interpretation. I am not saying the Tao Te Ching was written as a guide to modern corporate management.

What I mean is that a team needs a stable way of operating.

For example:

What does this team truly care about?

How do we make judgments when people disagree?

What kinds of mistakes are acceptable?

What boundaries should not be crossed?

When something goes wrong, do we first look for someone to blame, or do we first solve the problem?

When should the manager step in?

When can team members make their own decisions?

If these things keep changing, people get tired.

Something is acceptable today.

Tomorrow, the same thing becomes unacceptable because the manager is in a different mood.

Over time, people lose a stable standard for judgment.

But if these principles stay relatively consistent, the team gradually learns how things work.

People begin to understand:

This is how we make decisions here.

The manager no longer needs to stand next to every task and give instructions.

A lot of things begin to run through shared habits and shared judgment.

This is why I increasingly feel that:

The Tao matters more than the technique.

Project management systems, daily reports, meetings, performance systems, and code review processes are all tools.

They can all be useful.

But if the principles underneath them keep changing, those tools mostly make the organization look busy.

If the underlying way of judging and working becomes stable, many things become easier.

I now think one of a manager’s most important jobs is to build that stable way of operating together with the team.

It should not exist only in the manager’s head.

Everyone should gradually understand it.

I still fall back into my old habits

None of this means I have completely changed.

As a founder, I still push for progress.

When things move slowly, I still get frustrated.

When someone does something differently from the way I would do it, my first reaction is sometimes still:

Why didn’t you do it this way?

Reading the Tao Te Ching did not suddenly remove those habits.

The difference is that now, sometimes, I notice earlier when I am becoming too tight again.

Then I ask myself a few questions:

Will this detail really affect the result?

Is this actually risky, or is it simply different from my preferred way?

If I do not step in now, can the team solve it themselves?

Is the cost of this mistake really too high to accept?

Am I intervening because the situation is dangerous, or because I feel anxious?

Sometimes I ask these questions and still decide that I need to get involved.

Sometimes I decide to wait.

And sometimes, one day later, the problem that looked serious yesterday has already been solved by the team.

A team needs room to breathe

I used to value precision very highly.

I wanted plans to be full.

I wanted progress to be exact.

Now I almost prefer a plan that leaves some space.

A team made of people will never operate like a machine.

People make mistakes.

They have their own ideas.

Their energy changes.

And the environment keeps changing.

If a team only works when everything goes according to plan, that team is actually fragile.

A more resilient team should be able to absorb some deviation.

When something goes wrong, someone can respond.

When the plan changes, people know how to adjust.

When the manager is not standing there watching, the work still moves forward.

If I had to summarize how my view has changed, I would put it this way:

Keep the direction clear. Keep the principles stable. Hold on to the critical points. Leave the rest a little looser.

I used to want everyone to stay on the track I had designed.

Now I am more willing to believe that a team can gradually develop its own way of operating.

The manager’s job is to help the team find that way, build it together, and then avoid changing it every day.

Sources and Notes

This article is based on the author’s own experience managing technical and product teams, together with reflections developed later through the study of Taoist thought.

Primary classical source:

• The commonly circulated Wang Bi edition of the Tao Te Ching

Concepts discussed in this article, including wu wei, knowing when to stop, and the Taoist image of water, are interpreted through the author’s own study and experience.

The discussion of project management, code review, team autonomy, emotional consistency, and a “team’s Tao” is a modern application and personal interpretation. These management ideas are not presented as management theories directly stated in the Tao Te Ching.

The phrase:

“Say seven parts. Do seven parts. Leave three parts open.”

is also the author’s own expression, not a quotation from the Tao Te Ching.

We try to keep three layers separate:

Classical text → Our interpretation → Modern application

As the content system behind The Inward Pioneer continues to develop, we will keep improving and expanding the sources and references used in our work.