Early Influence: Driving Modern Front-End Adoption

Context

Front-end development across FAS lacked a unified approach to modern JavaScript frameworks. Teams were making independent decisions, which created fragmented implementations, inconsistent developer experience, and a ceiling on how far any one team could scale. The division had also settled into a comfort zone with legacy stacks (Teamsite, Angular), so anything new came with real organizational drag.

My role

I acted as the early technical influencer and decision shaper. The point wasn’t “Vue is better”, it was figuring out how a modern framework could land at FAS without isolating the team that picked it up.

What I did

Positioned Vue as part of a component-driven architecture shift, not a stack swap. The framing was about how UI was built, not which framework owned the runtime. That made it easier for skeptical teams to engage on first principles.

Embedded Vue into the platform, not into a single team. Vue became a supported runtime inside AXS alongside Angular and AEM, with a shared component library (axs-vue) and a dedicated Vue Storybook setup inside the AXS monorepo. Adoption became a configuration choice instead of a rewrite.

Operationalized through tooling, not advocacy. A scaffold + Storybook + tokens setup that any team could pick up. Repeatable, reviewable, and supported by the same shared service that owned the rest of the system.

Resistance

Three patterns showed up.

Pressure to fragment ownership. There were repeated proposals to introduce externally-owned components into AXS, components built by other teams but living in the same library. I pushed back hard. Mixed ownership models fragment a design system; you can have one source of truth or you can have many; you cannot have both.

Competing technical directions. Pushes to adopt alternative component frameworks before the current architecture had landed. I held the line on evaluating changes in the context of scale, shared service responsibilities, and delivery speed, not on technical novelty.

Cross-team alignment friction. Other teams questioned how AXS worked across Vue, AEM, and design workflows simultaneously. I addressed it by articulating the model clearly and repeatedly: one component system, Storybook for discoverability, Figma alignment with design.

How I handled it

Direct and decisive. I didn’t allow ambiguity about what was in and out of scope for the platform. I anchored every decision in business outcome, avoiding fragmentation, maintaining delivery speed, reducing long-term dependency risk, and I encouraged knowledge sharing across teams while enforcing clear architectural boundaries. Collaboration without compromise of the platform.

Outcome

• Vue is now an enterprise-supported framework inside AXS, with shared libraries and tooling.
• Ownership of the design system stayed cohesive, no externally-owned drift, no fragmented dependencies.
• Teams can build with Vue against shared components and centralized standards.
• The framework-agnostic architecture that followed (Chapter 3) was only possible because the platform foundation was protected during the Vue adoption phase.

Why it matters

This case isn’t about Vue. It’s about establishing architectural discipline under organizational pressure, saying yes to innovation while deciding how it fits into a system that has to outlast any individual framework choice.

The work demonstrates the through-line of the rest of the chapters: introduce the right thing at the right time, and protect the system around it so the thing you introduced can compound.