What to Do When You Inherit a Broken Process

Within the first week or two of any new management role, you spot it. The process that does not make sense. The form everyone fills out and nobody reads. The meeting that happens every Tuesday because it always has. The closing routine that takes twice as long as it should. You think: I will fix this.

And often, that is the right instinct. The previous manager either created the process for a reason that no longer applies, or never created it at all and just inherited it from someone else. The accumulated weight of these "we have always done it this way" routines is one of the biggest drags on small businesses.

But fixing them too fast is a mistake almost as common as not fixing them at all. The first time a new manager rips out a long-standing process, half the team is relieved and the other half panics. The panic side has reasons you may not understand yet.

Ask Why It Exists Before You Change It

The single most useful question with any inherited process is: why are we doing this? Ask everyone who touches it.

Sometimes the answer is "I do not know, the previous manager started it." That is a clear signal you can probably retire the process.

Sometimes the answer is "because three years ago a customer sued us for X, and this is the documentation that protects us." That is a different story entirely. The process looks pointless because the original need is no longer visible.

The number of times a brand-new manager kills a process and then re-creates a worse version of it six months later, after the original problem comes back, is higher than anyone admits.

Watch the Process Run Before You Touch It

For two or three weeks, do not change anything structural. Watch. Sit in on the meeting you find pointless. Read the form you think nobody reads. Observe the closing routine you want to streamline.

You will learn three things:

• Which parts of the process actually produce value
• Which parts of the process produce no value but are emotionally important to someone
• Which parts of the process produce no value and could be eliminated cleanly

The middle category is where most new managers get in trouble. A process can be operationally useless and still matter to the team because it is a ritual, a moment of recognition, a sense of order. Killing it for efficiency reasons damages something you did not realize was there.

Talk to the Person Who Cares About It Most

Most broken processes have a guardian. The longtime employee who started the form, who has been running the Tuesday meeting since 2018, who owns the closing routine. Find that person. Have a real conversation.

Not "we are getting rid of this." Instead: "Help me understand what this is for and what would make it better."

Sometimes the guardian, given a real conversation, will be the one to propose the change. They knew it was broken; they were just stuck inside it. Other times they will tell you exactly why touching it is a bad idea.

Either way, you have an ally instead of an opponent.

Change Small Pieces First

When you do start changing, change small. The form gets shortened from 12 fields to 6 before it gets eliminated entirely. The meeting gets cut from 60 minutes to 30 before it gets replaced with a written update. The closing routine gets a 30-second time-trial review before the entire sequence gets reordered.

Small changes have small consequences. If something goes wrong, you can reverse without drama. Large changes have large consequences, both good and bad. Save them for processes you actually understand.

Pilot Before You Roll Out

If you are going to make a meaningful change, run it on one shift, one team, or one day of the week before applying it across the whole operation. The pilot will surface problems you did not see in the design phase. Adjust based on what the pilot reveals. Then roll out to everyone.

A change rolled out to the whole team on day one is a change you cannot recover from gracefully when it fails.

Tell People Why You Are Changing It

The team will accept change much more easily when they understand the reason. "We are dropping the Tuesday morning meeting because the same information is in the daily task system, and the meeting is taking time away from the floor." That is a reason.

"We are changing some things" is not a reason. The team interprets that as "the new manager is making changes to look busy," which is sometimes true.

Acknowledge What Was Working

The previous manager was not a fool. The team that operated the process is not stupid. Some of what they built is good. Acknowledge it publicly.

"We are keeping the Friday recap because it works, and shrinking the Tuesday huddle because the daily checklist now covers what it used to do." That sentence treats the team with respect. It says: I am paying attention to what is good, not just looking for what is broken.

Wait Before the Second Change

After the first change, wait at least two or three weeks before starting the next one. A team can absorb one change at a time. Stacking changes on top of changes creates fatigue, mistakes, and resentment.

The exception is when two changes are directly linked and only make sense together. In that case, treat them as one change, but be honest with the team about the scope.

How MyTeamTasks Helps

A digital task system makes broken processes visible. The task that nobody completes on time. The handoff that always falls between two people. The routine that takes 90 minutes when the schedule allowed for 30. The data is in the system, and the manager can use it to make changes that are based on what is actually happening, not what someone remembers from the team meeting. That makes change easier to justify and easier to measure.