Selected work
Making complex systems visible and actionable.
A closer look at how I approach architecture, technical leadership, and operational problems where dependable feedback matters as much as the software itself.
- 01Systems thinking
- 02Technical leverage
- 03Transparent leadership
Case study 01
Engine quality infrastructure
From incomplete crash signals to an operational feedback loop
Designing an automated reporting system that turns failures in complex, cross-platform software into useful engineering decisions.
The challenge
Failures were visible to users before they were visible to engineering.
Crash investigation depended heavily on people noticing a failure, opening a reporter, and submitting enough context to make it reproducible. That left an incomplete picture of what was happening outside controlled environments and slowed the path from a regression to the team able to address it.
The surrounding system made the problem harder: failures could cross native and managed boundaries, behave differently across platforms, and produce large amounts of noisy diagnostic data. Any solution also had to remain lightweight enough not to compromise the product it was observing.
The approach
Build the shortest dependable path from failure to owner.
I shaped the system around four architectural decisions:
- Capture automatically. Collect useful diagnostic state at the point of failure with minimal runtime overhead and no required user action.
- Reuse proven infrastructure. Route events through an existing high-throughput path rather than spend months creating another operational platform.
- Keep the layers replaceable. Separate capture, transport, processing, and analysis so that one provider or interface could not become a permanent architectural constraint.
- Make ownership part of the pipeline. Normalize repeated failures into actionable groups and route them toward the engineering area most likely to understand and resolve them.
Changing direction
Urgency is not an excuse to hide architectural risk.
Under pressure, the first design coupled the client too closely to a downstream analysis service. A cross-team review exposed the long-term flexibility and cost risks of that choice after implementation had begun.
I brought the team together, acknowledged that I had approved a short-sighted constraint, explained what had changed, and reframed the problem: preserve the speed of the analysis experience while keeping control of the data path. The team adjusted the architecture without turning the correction into a search for blame.
The outcome
A faster, broader, and more durable feedback loop.
The resulting system gave engineering a much clearer view of failures in real-world use, reduced the delay between regression and investigation, and replaced streams of duplicate reports with prioritized issues. It also preserved the option to evolve the analysis layer without rebuilding the capture path.
The most important result was organizational: reliability signals became easier to act on because collection, grouping, and ownership were designed as one system.