Allan Sun is a software and systems engineer at Apple, where he works on real-time system software and infrastructure for Apple’s in-house 5G modem silicon platforms (C1X), one of the company’s most technically complex systems, used in its latest iPhone models. His work focuses on building measurement-driven systems that improve reliability, coordination, and failure diagnosis in production-scale environments where mistakes are costly and ambiguity is unacceptable.

Before joining Apple, Sun spent several years in a UC San Diego neuroengineering lab developing real-time software systems for brain-computer-interface (BCI) research. His work helped translate raw neural signals into actionable data during live experiments—systems that push the frontier of science toward restoring mobility and independence for people with disabilities through direct neural control of assistive technologies.

Related: ‘We’re Very Open’: Apple CEO Tim Cook Says He Wants to Buy Startups. Could Your Company Be Next?

Across both scientific research and large-scale production systems, the underlying problem has always been the same: how to convert complexity into clarity. 

Whether the system involves neurons or silicon, success depends on rigorous design, precise measurement, and disciplined iteration. The same principles that keep real-time systems reliable under microsecond deadlines also apply to building resilient teams, products, and companies.

This is the approach Sun is known for internally—a measurement-first, systems-level loop that scales from research labs to production silicon.

7-Step Problem-Solving Method

1. Define the system problem and the stakeholder.

Sun starts by identifying which part of the system is under stress, who depends on it, and what failure actually looks like in practice. “In complex systems, vague problem statements lead to fragile solutions,” he says. “I aim to define success in concrete, observable terms that everyone can agree on.”

In real-time system engineering, that might mean missed deadlines, dropped messages, or incorrect coordination. In a business context, it could mean customer churn, operational bottlenecks, or slow decision-making.

Takeaway: If you can’t clearly define the problem and who it affects, you’re probably solving the wrong thing.

Related: Gen. McChrystal Says You Need a Risk-Taking Mindset to Succeed: ‘If You’re Not Failing a Certain Percentage of the Time, You’re Not Doing Enough’

2. Understand existing solutions—and where they break down.

Before proposing anything new, he studies how the system currently behaves. In software systems, this means understanding how components communicate, where timing assumptions exist, and where coordination breaks down.

In academia, this looks like a literature review. In industry, it’s architectural analysis: existing frameworks, industry-standard designs, implicit assumptions, and known bottlenecks.

“The goal isn’t to criticize what exists, but to understand why it fails under real-world conditions,” he says.

Takeaway: Real insight comes from studying why current solutions fail—not just why they succeed.

3. Know the constraints.

“Before building, I invest heavily in design,” Sun explains. “That means explicitly identifying constraints—timing guarantees, ordering requirements, hardware resource limits, and long-term maintainability—and defining clean interfaces between components.”

Correctness is often about coordination rather than individual lines of code in real-time systems. Measuring assumptions early prevents expensive rework later, when changes are harder and riskier.

Takeaway: Slow down early. Decisions made without measurement get paid for later—with interest. Measure many times, cut once.

4. Build a focused proof-of-concept.

Sun first builds a minimal prototype that stresses the hardest parts of the system: message passing, synchronization, timing behavior, and failure handling. The goal isn’t completeness, he notes, it’s validation.

“A good prototype surfaces hidden assumptions while changes are still cheap. It shouldn’t prove what’s easy — it should prove what could break everything,” he clarifies.

Takeaway: Prototype to test your assumptions, not to confirm your optimism.

5. Iterate through refinement and review.

As the system evolves, Sun says he relies on real behavior—not intuition—to guide refinement: “I seek early feedback from other engineers and domain experts, and I start testing as soon as possible.”

Unexpected results aren’t treated as mistakes; they’re data points that reveal gaps in the mental model of the system. “When something goes wrong, I want it to fail fast, fail early, and fail loudly—so the issue is easy to observe, diagnose, and fix,” he says.

Takeaway: Fast, clear feedback turns failure into progress.

Related: The Framework Google Uses to Solve Its Hardest Problems Can Work for Anyone. Here’s What to Do.

6. Harden the system and verify its contracts.

Once the design stabilizes, his focus shifts to consistency. Communication paths must behave predictably, deadlines must be respected, and the system must remain understandable as complexity grows.

“This is where production-scale rigor matters most,” Sun notes. “Reliability isn’t flashy, but it’s what allows teams, customers, and partners to trust the system—and to build on top of it with confidence.”

Takeaway: If it’s going to scale, it has to work predictably—not just once, but always.

7. Operate, observe, and evolve.

“Shipping a system isn’t the end of the work—it’s the beginning of learning,” says Sun. Real-world usage exposes edge cases, new requirements, and opportunities for improvement that no design phase can fully anticipate.

Some changes are incremental. Others point toward the next major architectural shift. “The best systems—and the best organizations—treat evolution as a feature, not a failure,” he points out.

Takeaway: Shipping is the start of learning, not the finish line.