SimX VR

I joined SimX in February 2022 as Head of Engineering. It was an unusual decision for me — I took the role not because of the technology stack or the compensation, but because of what the company was actually trying to do.

Why SimX

SimX builds Virtual Reality (VR) training simulations for medical professionals. The mission is straightforward: reduce medical errors by giving care providers a safe, realistic environment to practice high-stakes scenarios before they encounter them in real life. Whether it's a paramedic running a cardiac arrest simulation or an emergency room team working through a mass casualty event, SimX puts them through it in VR so that when the real thing happens, they're ready.

That mission resonated with me. I'd spent most of my career building games and entertainment software — genuinely enjoyable work — but the chance to build something that could directly improve patient outcomes was hard to pass up. When they told me the platform had already been used to train tens of thousands of healthcare workers across the US, that sealed it.

Growing the Team

When I arrived, SimX was at an inflection point — transitioning from an early-stage startup into a small to mid-sized company. The engineering team needed to grow quickly to support that transition, and my first year was largely dedicated to that.

By the end of 2022, the team had grown substantially. That kind of rapid hiring can easily go wrong. It often dilutes a team's culture or introduces friction that slows everything down. We avoided that by being deliberate about every hire.

Each new team member was evaluated on two things: technical skills and cultural fit. "Cultural fit" isn't corporate speak here — it meant people who communicated openly, took ownership of their work, gave honest feedback, and supported their teammates. During one interview cycle, I brought the existing team leads into final-round conversations so they could assess whether a candidate would mesh with how the team actually operated day-to-day, not just whether they could write good code. More often than not, the team leads spotted things I missed.

The result was a team that didn't just grow in size — it leveled up. Engineers who joined mid-year were making meaningful architectural decisions within a few months, not because I pushed them to, but because the environment made it natural.

Cross-Department Integration

Strong engineering teams don't operate in isolation. I made sure we were a genuine partner to Design and QA rather than a separate silo.

We introduced regular joint reviews with the design team early in each feature cycle, so engineers understood the intent behind what they were building — not just the specification. That context made a real difference. Engineers caught design edge cases that wouldn't have surfaced until QA, and designers got early feedback on what was technically straightforward versus what would require significant rework. It cut back-and-forth and built mutual respect between the teams.

With QA, we shifted toward a shared ownership model. Rather than bugs being handed off over a wall, engineers and QA worked from the same backlog. Issues got triaged faster, reproduction steps were clearer, and the adversarial "your bug / my bug" dynamic largely disappeared.

Hands-On Engineering

I've never been a manager who just manages. At SimX I stayed close to the codebase throughout — particularly the networking layer, which is critical for a multi-user VR application where timing and synchronization directly affect how believable a simulation feels.

Telemetry and analytics were an area I spent considerable time on. On the runtime side, we integrated Sentry across the platform to give us proper visibility into errors and performance issues in the field. VR applications running on standalone headsets are notoriously hard to debug remotely. With structured error tracking and performance monitoring in place, we could identify crash patterns proactively, spot regressions before they reached users at scale, and cut the time from issue reported to root cause identified significantly. For analytics, we built out a pipeline into Elasticsearch and surfaced it through Kibana, primarily for internal business intelligence. The dashboards gave leadership visibility into platform usage, customer engagement, session volumes, and feature adoption across accounts — the kind of data that informs product roadmap decisions and helps a growing company understand where its value is actually being delivered.

A Process That Worked

One of the things I'm proudest of at SimX was a practice we established early on: regular engineering meetings where the team proposed their own improvements before I weighed in with my view.

The thinking was simple — the people writing the code every day know where the problems are. They don't always get asked. I made sure we asked, and then I got out of the way. Beyond just fixing problems, the expectation was that engineers would actively propose innovations — new approaches, better tooling, product improvements — not wait to be told what to build. That expectation wasn't just cultural window dressing either; it was built into performance reviews. Engineers were assessed partly on the quality and impact of the improvements they initiated, which gave the practice real weight and made it something people took seriously rather than a box-ticking exercise.

In practice, this generated some of the best work we did. One engineer identified performance bottlenecks in the application startup flow and proposed targeted optimizations that meaningfully reduced load times — a real improvement for users putting on a headset and expecting the experience to feel immediate. Another engineer proposed tooling that allowed non-technical teams to create and manage content independently, without needing to involve engineering at all. That freed the engineering team to focus on the platform and gave other departments genuine ownership over their own work. Both ideas came from engineers who understood the wider business problem, not just their slice of the codebase.

Reflection

The SimX engineering team sits at the top of my list of teams I've built. Getting the culture right — where everyone had a voice, supported each other, and felt real ownership over what they were building — was more satisfying than any individual technical win.

It's also a reminder of why I joined in the first place. When you're building training tools for paramedics and emergency room teams, you're contributing to better patient outcomes. That's not something I take lightly.