FEATURE – Performance issues are normally addressed as process problems, but in many cases, the root cause lies elsewhere. The author reflects on a recurring yet often ignored problem.

Words: Rémi Pigeol

A few years ago, I was running a reconditioning plant operating on two shifts—morning and afternoon. Both teams were engaged, with committed team leaders and operators actively taking part in kaizen activities, and problem solving was part of daily work. And yet, progress remained limited. Something wasn’t working. Results were okay, but they seemed to have plateaued. The factory was running, but it wasn’t really moving forward.

To address the situation, we investigated the process: vehicle mix, production leveling, adherence to standards. We spent time observing the work, often standing right behind workstations, watching the flow and talking with the teams at the gemba.

We didn’t find any major issues in the process. So, the question remained: why wasn’t a system with engaged teams improving? Nothing really explained what we were seeing.

When we finally decided to shift our focus and began to pay closer attention to how the teams worked, something else emerged. The two team leaders weren’t really working together. There were no open conflicts, no arguments, but there was no real cooperation either. Each team leader focused on their own team—something that, over time, created a subtle form of competition.

Each team wanted to show better results. On the board, people naturally looked first at their own column. The other one became an informal ranking, with behaviors slipping as a result. Easier vehicles were sometimes preferred, the planned leveling was not always respected, and good solutions devised by one team were not shared with the other.

Little by little, the collective mindset had eroded. The two teams started behaving like separate groups and the company’s shared objective—serving the customer—faded into the background. We thought we had a process problem; in reality, we had a team problem.

From that moment on, we changed our approach and addressed how teams worked together. And that’s when things started to shift.

At first, it wasn’t easy. People remained attached to their own team and results. Discussions were sometimes tense, and it was clear that rebuilding trust would take time. I remember one situation where we had recurring delays on vehicles that required longer mechanical interventions. These jobs were often started during the morning shift but were not completed before the afternoon team took over.

The problem wasn’t the complexity of the jobs, but the handover. The morning team would stop at a certain point, but the exact status of the vehicle, the difficulties encountered, and the next critical steps were not always shared with the colleagues working the afternoon shift. As a result, the afternoon team often had to spend time re-understanding the situation—sometimes even repeating checks, “just to be sure”—before they could continue working.

As we tried to establish cooperation between the two teams, we introduced a simple practice. Before the shift change, the team leader and an operator from the morning team would briefly take the afternoon team through the status of unfinished jobs, focusing on what had been done and what remained critical.

Very quickly, we saw the impact of this: the afternoon team could resume work without hesitation, avoid unnecessary rework, and complete more vehicles within their shift. This resulted in an output increase of about 5%, without adding any capacity.

Gradually, competition gave way to cooperation and, without fundamentally changing the process, performance started improving again.

This experience stayed with me because it revealed something essential. In industry, we spend a lot of time improving processes, flows, standards, operations but system performance also depends on something much more fragile: the team’s collective intelligence.

When teams work together, over time they develop a deep understanding of their work. They know where problems tend to appear, recognize early warning signs, and build shared reflexes to respond quickly. This knowledge isn’t always written in standards. It lives in the work itself, in the form of gestures, interactions, and accumulated experience.

I’ve come to see an industrial system like an orchestra. The musicians can be talented, but unless they play together, the music won’t sound good. A factory is no different: standards are the score, machines are the instruments, but what makes the system work is the team’s ability to play together. When that coordination exists, the work flows; when it disappears, even a good score isn’t enough.

Looking back at my time in that organization, I’ve seen this same pattern appear in different forms—sometimes as a lack of coordination, sometimes as a lack of alignment, and sometimes as decisions that seemed logical but came too early.

When launching a new plant, for example, we were under strong pressure to ramp up quickly. The company had made a significant investment, and reaching break-even fast was a clear priority. As volumes increased, we decided to launch a second shift. On paper, this made perfect sense; on the shop floor, however, it didn’t, because the first team was not yet stable. Some key skills were still unevenly distributed, unusual situations were not always handled correctly, and the basics (5S, problem-solving, TPM, etc.) were not consistently applied.

By launching the second team, we hadn’t accelerated performance. We had amplified the instability. This became painfully obvious during gemba walks. The same problems would appear in both teams, sometimes in slightly different ways. Instead of having one team learning and improving, now we had two teams struggling in parallel. It took us time to understand that we had skipped a critical step. Before scaling, we should have stabilized the team.

Sometimes you can have a method in place and an improvement already made, and things still don’t work. In one plant, we had worked on the complex operation of replacing a timing belt. Through a kaizen effort, we had successfully reduced the operation time from around six hours to about two. The method was defined and documented, and people were trained.

In theory, the problem was solved, but on the shop floor, the results told a different story. Some vehicles were completed close to the two-hour target, while others were still taking much longer. The flow remained unstable, and queues were building up in front of the station.

During a gemba walk, we observed the same operation being performed by different operators. The standard existed, but it was being interpreted differently: some steps were skipped, others were done in a different sequence, and small variations accumulated into significant delays.

The issue wasn’t the method itself. It was the lack of shared understanding of how to apply it. To address this, we brought the team together around the work. Operators started observing each other, discussing the differences they saw, and going back to the standard to clarify what really mattered. Step by step, they aligned on a common way of performing the operation—this time, not because it was written down in the standard, but because they had collectively understood it.

Sure enough, within a short time, performance became more consistent. Variation decreased, the flow improved, and the gains from the initial kaizen finally became visible at the system level. The technical solution had been there from the beginning; what was missing was the team’s alignment around it.

Over time, one idea became clear. Most of the time, we look for solutions in processes because they are visible, measurable, and easier to change. But behind every process, there is always a team who learns, shares, builds common reflexes, and develops collective intelligence.

When this dynamic works, the system is robust. Problems are detected earlier, solutions emerge faster, and performance improves consistently. When it doesn’t, even the best process becomes fragile.

Over time, I’ve learned to ask one question when performance starts to slip: is it really the process, or is it the team?

_THE AUTHOR