Turn frontend practice into team training

Context

As ERP and MES frontend development continued, I gradually identified another problem.

Even with reusable UI patterns in place, if each engineer understood the following differently:

• How to split components
• How to manage state
• How data should flow
• Where shared capabilities should live
• How to think in React

the resulting code would still gradually diverge.

Many engineering problems were not caused by nobody knowing how to write the code, but by this:

everyone knew one way to implement it, but the team had no shared way to make the judgment.

My Decision & Action

In addition to developing features myself, I began organizing the frontend experience accumulated through real work into training material.

I did not want training to merely introduce APIs or framework syntax, but to break down questions commonly encountered in real projects:

Why do we split components this way? Why should data flow this way? What should be extracted into a shared capability? When does something look repetitive but not necessarily deserve abstraction?

I turned judgments that had existed in personal experience into development patterns other engineers could understand, discuss, and reuse.

Outcome

Frontend training became more than framework operating instructions; it became a way for the team to exchange engineering experience.

Practices previously learned only through code review or firsthand mistakes could be explained earlier, giving the team a more consistent basis for discussing ERP and MES development.

Reflection

This was the first time I clearly felt that:

Technical leadership is not only finding a better solution yourself, but enabling others to understand why that solution works.

If only you can use an approach, it remains merely an individual capability.

Only when it can be explained, discussed, and adopted by others does it begin to become a team capability.