Micro frontends aren't primarily a technical pattern—they're an organizational one. This talk reframes the micro frontend conversation for engineering leaders who need to decide whether splitting their frontend aligns with their business reality, not just their technical ideals.

We'll explore why most micro frontend discussions miss the point by focusing on implementation details rather than organizational structure. Drawing from experience managing frontend architecture serving 2+ million users across distributed teams, I'll demonstrate how to decompose applications using business-driven design principles that align with how your teams actually operate and deliver value.

You'll learn to identify the organizational signals that indicate micro frontends might solve real problems—and the red flags that suggest you're solving the wrong problem with the wrong tool. We'll examine the critical difference between domain-driven and business-driven decomposition strategies, and why the latter often better serves enterprise reality where team boundaries, budget constraints, and product ownership matter more than perfect technical domains.

By anchoring architectural decisions in organizational structure rather than technical purity, leaders will gain a framework for evaluating whether micro frontends address their actual constraints: team autonomy, deployment independence, and reducing coordination overhead.

## Learning Outcomes

Attendees will be able to:

1. **Assess organizational readiness** for micro frontends by identifying specific team structure patterns and pain points that micro frontends actually solve

2. **Distinguish between business-driven and domain-driven decomposition** strategies and select the approach that matches their organizational reality

3. **Evaluate the true cost** of micro frontends beyond technical complexity—including organizational coordination, governance overhead, and team cognitive load

4. **Apply a decision framework** that balances technical architecture with team autonomy, product ownership boundaries, and business delivery needs

5. **Recognize anti-patterns** where micro frontends create more organizational friction than they resolve