How to Align Your Role and Grow as a Front‑End Engineer: 5 Key Lessons

Anniversary reflections are valuable—beyond personal summaries, last year's "Alibaba first‑year summary" still receives likes, adding extra value. Now, after two years, I share the most impactful tips I’ve gathered, hoping they help others.

1. Clarify Your Positioning

When I first joined, I heard a story about a senior engineer who, after promotion, received a low performance score because he failed to create new value. I wondered why the company would penalize a newly promoted talent. Later, as I took on management responsibilities, I kept swinging between "doing the work myself" and "leading others", realizing the core issue: if I keep doing the work, my teammates stay idle; if I let them do everything, what am I doing?

The root cause was a lack of clear positioning. Positioning has two aspects:

Self‑defined persona

Company’s expectations

In my case, I saw myself as a core technical developer on the front line, enjoying the feeling of solving problems directly. The company, however, expected me to lead a small team. In this combined positioning, team growth takes priority over personal frontline work. Continuing to work solo no longer matches the company’s expectations, so I had to adjust my role to align with both.

Such mismatches happen repeatedly throughout a career, especially during promotions or organizational changes, which bring new challenges that break existing habits. Adjusting proactively keeps you matched with expectations.

2. Forward Compatibility

Forward compatibility: a principle in software and standards that ensures new versions remain compatible with older ones. Here it means retaining the abilities of the previous stage after moving to the next.

For engineers aspiring to management, a common dilemma is that the company’s stated requirement is management, but the real requirement is output. Management alone does not guarantee output; a team must keep improving to produce results. Pure management without technical insight will not satisfy a competitive environment.

The solution is "forward compatibility": keep the skills of the previous (or several) stages while advancing. The diagram below illustrates that, although the proportion of technical implementation decreases over time, technical architecture never disappears and even grows in overall share.

Thus, when a problem arises, you can quickly adjust the architecture; when needed, you can decisively scale down and support the business.

3. Complex Solutions Often Stem from Bad Design

When faced with overly complex code logic, pause and consider whether the solution itself is flawed. Common reasons include:

Choosing the wrong approach

Ignoring critical link nodes

Not using appropriate technology

For example, trying to implement complex animations with JavaScript in a low‑performance WebView leads to lag, whereas switching to CSS animations often yields smooth results.

The essence of avoiding bad design is to read, think, and absorb continuously, so you have the right tools when a crisis hits.

4. Let Specialists Do Their Own Work

Last year a project required a complex SQL query on dirty data, which caused huge pain and delayed delivery. A data analyst could have completed it in minutes. Similarly, front‑end developers should not spend excessive time on tasks better suited for other specialists.

The principle is "let the right person handle the right job"—don’t challenge yourself in areas where you’re weak, and when needed, bring in experts.

5. Control Boundaries and Pursue Collaboration

The front‑end field has shifted from a blue‑sea to a red‑sea market. Building a framework comparable to React or Weex is no longer realistic, and pure business value is being squeezed out.

Now the landscape has moved from:

Territorial competition to multi‑platform collaboration

Solo development to specialized division of labor

General technical projects to business‑specific technical projects

Success now requires delivering valuable products while controlling personal scope and desires, collaborating across front‑end, back‑end, business, and operations teams, and uniting all available forces.

Future wheels will be complex, business‑specific, and will no longer accommodate half‑hearted contributors; rapid adapters will thrive.

Conclusion

The five insights above—clarifying positioning, maintaining forward compatibility, avoiding bad design, letting specialists focus, and balancing boundaries with collaboration—summarize my two‑year experience at Alibaba. Whether you’ve faced similar pains or not, I hope these lessons help you grow.