Building a Cross-Department Culture of Shared Learning: Team Synergy Driven by an Internal MI Lead

Nitta DuPont is a specialist manufacturer of precision-polishing consumables used in producing semiconductor devices and silicon wafers. Our polishing pads, in particular, hold a very high market share and serve as an industry-standard specification.

Our key strength is that we develop and manufacture both the polishing pads and the slurries — the polishing agents — in-house, end to end. That integrated capability lets us tailor both products to each customer's needs and deliver them as a single total solution. We were the first in the industry to establish this approach.

A slurry is a liquid containing abrasive particles such as silica. The wafer — the semiconductor substrate — is pressed against the pad while slurry flows between them, combining chemical and mechanical actions to achieve high-precision polishing of the surface. Because our polishing pads are the industry standard, we are uniquely placed to recommend the optimal pairing of pad and slurry.

The starting point is that demands from the semiconductor market — where our products are used — keep getting more sophisticated and more complex year by year. The most familiar example of this evolution is the smartphone. Every step up in smartphone performance is driven by the underlying semiconductor, and that progress depends on shrinking the internal wiring. As feature sizes shrink and our customers move to new materials, the things we need to polish change too, and our products have to evolve with them.

Customers also want better yields, and that is another priority we have to address. Achieving it means making productive use of the outer edge of the wafer, which has traditionally been hard to use, and that in turn demands further evolution of the polishing pad itself. On top of that, we are being asked to push quality even higher — for example, getting the micro-scratches that occur during polishing as close to zero as possible.

To meet those market demands, the reality is that nearly every engineer is juggling multiple development projects at once. Given the nature of this industry, development cycles must be short. As a result, improving R&D efficiency has long been a major challenge for us.

On top of that, there were two further problems in our R&D work: the wide gap in knowledge and experience between new hires and veterans, and the fact that valuable know-how was tied up in individuals and never written down.

We had of course been using statistical methods such as Design of Experiments (DOE), but for projects where countless factors interact — pad-slurry compatibility, the equipment being used, and so on — classical methods alone often could not get us to the optimal solution. As a result, each engineer's experimental data stayed with that engineer and never became organisational knowledge. Putting that data on a proper, systematic footing was another major issue for us.

The Evaluation Technology Department I belong to provides technical support to the development and production-engineering teams. While my colleagues design experiments for customer proposals or run physical analyses of products, my own speciality has been analysis through numerical methods — work like numerical simulation.

Over time, my work gradually expanded into data analysis, and I was increasingly asked for advice across departments. That is how I ended up leading our MI initiative — as the person tasked with exploring what we could do with our data.

Three things tipped the balance for miHub®.

First, the developers themselves — the actual users — can work with the data directly. That lowers the wall between specialists and developers, makes communication with junior members in particular much easier, and we expected it to smooth out collaboration across R&D significantly.

Second, data is managed in one place and accumulates as reusable knowledge. With traditional DOE, data was scattered across individual PCs and the insights never connected. A single system that lets anyone arrive at the optimal solution through the same logic seemed essential to fixing our underlying problem.

Finally, on the practical side, multiple licences allowing the team to use the tool in parallel was an important requirement for adopting it organisation-wide.

As the person driving MI, the first thing I had to face was the honest reaction on the ground when we launched. For the people targeted to use it, this was pure additional work, and there was also genuine puzzlement — "how is this any different from the tools we already have?" It was not greeted with open arms. We really did start by feeling our way forward.

Given that situation, we started with a small group — members who were keen to give it a try, working on projects where results would come more readily. For the first year, the goal was not to deliver hard outcomes but simply to judge whether miHub® was genuinely useful for our kind of R&D. If we got a positive signal, we could use those early wins to roll it out more widely. We figured that even members who had been lukewarm at first would come around once they saw the value, and adoption would spread naturally across the organisation.

For the project selection, we asked every department to put forward the day-to-day R&D problems and improvement ideas they wanted to tackle. Ozeki then led the screening, asking things like "could we already handle this with existing tools?" From there we talked it over with the MI-6 team as well, examined feasibility from multiple angles, picked the final projects, and kicked them off. We were deliberate about this process because simply ordering people top-down to "go produce results with miHub®" would only put them under pressure. The real point is not to use a tool for its own sake but to develop the products we want to develop, efficiently — the tool is one option among several. So in the first year our goal was simply to start using it and to get comfortable with it; we did not rush for results. As it turned out, choosing projects where progress was easy to see and where members could feel real traction also worked in our favour.

We did run into difficulties along the way. The biggest one was a mindset shift, particularly for the slurry development members who were used to DOE: moving from "local optimization" — looking for the best answer within a narrow range — to "global optimization" thinking behind miHub®, which searches across a much wider design space. We see that trial and error as valuable experience in itself, part of getting comfortable with a new tool.

Early on, progress varied widely depending on individual motivation and how well each member took to the tool. We judged that we could not scale company-wide on that basis, so we adjusted course partway through. Concretely, we reshuffled the team — bringing in people who showed a stronger aptitude for the tool and looked likely to use it well.

The regular hands-on support we received from MI-6 was a particularly big help.

In the first year, even when a meeting was about one person's specific project, almost all users would join, so we could learn together — "how should we interpret this result?" and so on. With MI-6 walking alongside us in that setting, we as users were able to move forward together, step by step, out of what had been a complete fog. Getting through that year, encouraging each other as if running a marathon, has noticeably strengthened the team's sense of solidarity.

Speaking for myself as the person driving MI, this support setup was extremely helpful for the team. At the beginning, there were challenges in operating miHub® and reading unfamiliar graphs, but every time we brought a question to a support meeting they walked us through it with real care. Framing the problem well takes some experience, but going through this process drove home for us how important it is to just keep iterating — to keep running the cycle. And We are convinced that when the way you use it matches the project well, miHub® can be a very powerful tool.

There's no doubt our users' understanding of the tool deepened markedly through the ongoing conversations with the MI-6 team. With professional perspective in the mix, the resolution of our plans — the level of detail we were able to see and act on — kept getting sharper.

We've had some very interesting results on a first-year project that we originally expected to be tough. Materials development has historically leaned on each engineer's experience and intuition; after 25 experimental cycles, we can now simply enter information about a new material and get back a promising formulation that's close to practical-use level.

According to the engineer in charge, the process has cut the development effort to roughly 20-25% compared to conventional development approaches. Visible results are starting to come through on the projects we've stuck with.

It's only been a little over a year since we started using miHub®, but we have a real sense the projects are working, and we're steadily building up cases where it's clear development has been accelerated. We try not to put excessive pressure on our members. By continuing to remind them that this is one tool among many, we want them to keep a long-term view.

We've also seen a very welcome change: with Ozeki at the centre, users have started running regular meetings on their own initiative. They aren't just swapping useful features and tricks — pad and slurry members, whose development approaches normally differ, are coming to genuinely understand each other's perspectives and thinking. That kind of synergy goes beyond what we originally hoped for.

This grass-roots exchange between users is having a positive effect on the wider organisation. The clearest example is the review meeting we run roughly every four months. At those sessions, you see members who have got the hang of the tool spontaneously coaching the less experienced ones — "try it this way and you might get more out of it."

By sharing the upside of new development approaches through this exchange, we are starting to see miHub® throw up suggestions we wouldn't have anticipated. And these cases will, I think, serve as a healthy spur to other members — "we'd like to try building a new product with miHub® too."

Through the regular meetings we naturally started discussing things across departments, and unexpected ideas that solve real problems often come out of those conversations. Alongside that organisational shift, we've seen a big change in individuals too. When miHub® suggests a material combination no one expected, for instance, it sparks engineers' motivation to try new possibilities.

One notable change has been how proactive members have become. Their curiosity has been lit. "Let's try a feature we haven't used before," they'll say — and some have gone off to learn other statistical methods such as principal component analysis to deepen their interpretation. Others have started, on their own initiative, to figure out how to quantify information they had only ever captured qualitatively and feed it into miHub®. That kind of initiative is, I believe, what's really driving the project in a good direction.

As the team has grown, my own role has shifted too. At the start, I was the one teaching people how to operate the tool and how to read the output, but a year on, each member can use miHub® independently. The regular meetings are no longer tied to a specific tool either — they've become an open forum for discussing R&D issues more broadly, and I can really feel the team maturing.

Rather than just leaning on the tool, people now clearly view miHub® objectively, as one useful tool among several — and they actively combine the data-driven hints it provides with their own engineering knowledge and judgement as they push development forward.

We have two broad goals. The first is to widen the user base further and build a development culture where everyone — from junior members to veterans — can argue from data and logic, rather than relying on individual experience and gut feel alone. The second is to make sure the data we generate isn't one-shot, and to build a company-wide knowledge database that can be reused horizontally across other projects.

Getting there is anything but easy, of course — in practice it's a long stretch of unglamorous, hands-dirty work. We are continuing to explore how best to embed miHub® into daily operations. Even so, we genuinely feel we are moving forward, one step at a time.

Historically — for better or worse — our development style relied on each engineer's accumulated experience, and our internal databases were not really being put to full use. We see this MI initiative as an important first step toward a new stage: moving beyond that person-dependent style of R&D and driving development from accumulated data instead.

Building from this first step, what we ultimately want is to embed a development culture in which engineers actively choose the right tool for the project at hand. We want every developer to recognise miHub® clearly for what it is — a particularly useful option among the many means of making R&D more efficient.

One reason this initiative is heading in a good direction, I think, is the flexibility built into how we run the project itself. In my experience, the projects that fix their plans most rigidly are the ones that can't course-correct when something unexpected hits, and they end up stalling. Learning from that, we've adjusted our approach as circumstances changed, and I believe that's a big part of why we are where we are. The single most important takeaway is that our members have come to understand, in their bones, how important it is to keep running the cycle. In the past we tended to spend a lot of time on a small number of experiments and debate them at length. Going forward — whether or not miHub® is involved — the real payoff will be when the mindset of "shorten the cycle time, make data-driven decisions, and deliver better products faster" takes root as the culture of the team and ultimately of the whole company.