This project best reflects my experience operating in a large-scale real-time product while also stepping into leadership during a difficult delivery period. It shows how I handle ambiguity, cross-team execution, and complex live-streaming state management under pressure.

The biggest challenge was implementing Battle Mode with almost no reliable example to follow. Two independent streamers needed to see and hear each other, while both groups of viewers also needed to share the same live chat during the battle. In a more typical live-streaming setup, each streamer and audience remain in separate RTC and RTM channels. Our design direction was different: during Battle Mode, both audiences temporarily shared the same RTM messaging space, then had to return cleanly to their original channels when the battle ended. That created a large number of timing issues, edge cases, and state-transition bugs.

The hardest problem was making the transition between solo mode and Battle Mode reliable. The feature involved two broadcasters, two audience groups, RTC audio and video state, RTM channel membership, and UI state all changing together in a coordinated way. Small timing differences could leave users in the wrong channel, show the wrong messages, or create inconsistent session state. At the same time, the team was behind schedule, the original team lead had just left, and a new iOS developer had only recently joined and was not yet familiar with the codebase. I had to step in as the new lead, take ownership of the implementation, and create a workable solution path for the team.

• Stepped into the iOS team lead role after the original lead left during a critical phase of delivery.
• Designed and implemented most of the Battle Mode flow on iOS.
• Handled the RTC and RTM coordination required to merge two live sessions temporarily and restore users to their original channels afterward.
• Took on most of the core implementation work while also helping a newer iOS developer ramp up in a complex codebase.

• Reduced the feature into a clearer set of state transitions instead of treating it as only a UI problem.
• Used trial and error to validate the Battle Mode flow in Agora-based live-streaming logic, since there was no direct example that matched our product requirements.
• Focused first on getting a reliable end-to-end iOS implementation working so the team could evaluate a concrete solution rather than debate abstractions.
• Paid close attention to timing-sensitive events around joining, leaving, channel switching, and session restoration after Battle Mode ended.
• Kept the implementation practical and understandable so it could be supported by the team under schedule pressure.

• Worked with design and product to turn an ambitious live-streaming concept into a shippable implementation plan.
• Presented a working iOS demo to management once the core Battle Mode flow was stable enough to prove the approach.
• Helped the Android team align after they had difficulty finding a working implementation on their side.
• Explained my implementation decisions in detail and helped debug several cross-platform compatibility issues so iOS and Android could converge on the same behavior.

• Prioritized a working and understandable implementation over trying to invent a perfectly abstract architecture too early.
• Accepted that early iterations would be somewhat experimental because the feature had many unknowns and no proven blueprint.
• Focused first on correctness in the core session-transition flow before polishing less critical edge cases.
• Balanced delivery speed with the need to make the feature stable enough for cross-platform release.

• Unblocked Battle Mode by producing the first working implementation path on iOS.
• Provided a concrete demo that helped management and the broader team align on a viable direction.
• Helped the Android team adopt the same overall approach, reducing cross-platform inconsistency and moving the project forward.
• Stabilized a complex real-time feature during a period of schedule pressure and team transition.

• When a feature has no clear precedent, a working prototype is often more valuable than extended debate about the ideal design.
• In real-time systems, reliability depends heavily on making state transitions explicit and understandable.
• Leadership under pressure often means creating clarity for the rest of the team when the path forward is still messy.
• Cross-platform features become much easier to ship when one team can demonstrate a concrete, working model that others can align to.

• I would formalize the Battle Mode state machine earlier so transitions and edge cases are even easier to reason about.
• I would add stronger internal debugging tools and event logging around RTC and RTM state changes to diagnose timing issues faster.
• I would document the cross-platform channel and messaging contract earlier so iOS and Android can align sooner.