Making progress
a practice.

I pay attention to what happens when someone raises a problem. If I explain it away, defend the process or give the answer, I may resolve the immediate issue. I may also teach the team to wait for me next time.

I want to understand what happened at the process before deciding what to do. What was expected? What actually happened? What has the team already tried? That gives us something to coach from.

Clear expectations still matter. A missed target needs facts, an owner and a next step. It also needs a check that the team has the time, authority and support to act.

The easy part to lose is returning. If I ask for an experiment but never come back to look at the result, I have taught the team something too. What I follow up tells people which work deserves their attention.

A Kaizen event creates time and attention that are hard to find during a normal week. People can test changes together and resolve problems that have been passed between functions.

After the report-out, the conditions change. Production pressure returns. Another shift takes over. An experienced operator is absent. This is where we find out whether the method works without the people who designed it standing beside the process.

I check whether people use the method, whether it makes the work more reliable and whether the expected effect shows up in the process and the KPI. An approved standard and a closed action do not answer those questions.

When the result slips, I want to understand why. Training may be missing, the method may be too complicated or a dependency may still be unresolved. Those are different problems. Asking the team to comply harder will not fix all three.

I would start with a task people already understand. Searching for information, comparing documents or preparing material can be useful places to look. Put a small first version in the hands of the person doing the work and compare it with the current method.

Measure the whole task. A draft produced in seconds can still take longer overall if someone has to check every line, repair the output and explain the errors. The relevant question is whether the work reaches a usable result sooner.

Keep the target, baseline and owner clear. Test under normal conditions, adjust and look for repeatability before scaling. Access, confidentiality and responsibility for decisions need to be settled as part of that work.

I also want to know why the task exists. If we can remove a handover or improve the source information, we may solve the problem before we need AI. A quick win is more useful when we understand why it worked and can reuse that knowledge elsewhere.

Strategy can look clear in a presentation while the improvement funnel keeps growing. We end up with more projects than capacity and a plausible strategic link attached to each one.

I want the connection to be specific. Which performance gap are we closing? What should change in the process? What would we expect to see before the final KPI moves? If we cannot explain that, the activity may be useful, but its contribution to the priority is still an assumption.

The funnel should help us choose and sequence the work around constraints. The process owner owns the result. Business system support can coach and provide structure, but taking over that ownership makes the improvement dependent on the support function.

Some problems belong with the team because they affect today's flow. Others need site-level attention because they cross functions. Calling everything strategic blurs that distinction and competes for the same limited resources.