Interview: Ben Mehling (Part 1) – The stage was the first stage

Ben Mehling, VP of Technology at Crossover Health, joined the company in 2016 and has been central to the development of the first Crossover practice portal. He ensures the operational integrity of our technology infrastructure, and is a key to the success of our development team as they build out our visionary new software platform. Like so many of the interesting leaders at Crossover, his path to healthcare and the company started in a highly unlikely place, but his life’s experiences certainly predisposed him to his current role. Part 1 of 2. 

What’s your background?

I grew up in Calabasas, on the edge of the San Fernando Valley, in Los Angeles County. My father was a firefighter his whole life, including his time in the Air Force,  and ended up retiring as the Fire Chief of Burbank. By contrast, my mom was “just” a mom, in her “spare time” she co-authored five books on acupressure, taught classes on the subject, and produced a creative/guided visualization CD, primarily focused on helping arm children with techniques to reduce stress (beit during school tests or scary medical procedures). So, as I was growing up, my dad was very ordered and logical. And my mom was eastern medicine, meditation, and yoga. Yin and Yang. At this point in my life, I can look back and truly appreciate how they each contributed to who I became. 

I went to school for an entirely different thing. My degree is from a performing arts conservatory in technical theater and design, with a focus on lighting design and set design. It was an excellent program affiliated with three professional regional stages — very hands-on. For my final thesis, I wrote a mac application to help program manage a theater production’s lifecycle across all functions. In the end, I didn’t feel the industry was the right place for me. It just didn’t fit my personality. So right out of school, I got a job doing support for enterprise storage systems. I did that for a bit then ended up working at the University of California at Irvine in the graduate school of management.

I spent almost ten years there, doing everything from running a large-scale student laptop program (one or two in the US at the time) to managing the development team—I was even the interim CIO for a bit. We were the second school in the country to develop a custom application, which today would be referred to as a Learning Management System or LMS. We saw some work that Harvard had done and we thought we could build something ourselves. We “productized” the application and sold it to the Haas School at Berkeley and The Krannert School at Purdue. The application was awarded “Intranet of the Year” (yes, apparently that was a thing) by CIO magazine.

How did you get into healthcare?

One of the developers who worked on the LMS product with me was Steve Shreeve. In 2002, Steve and Scott Shreeve were starting Medsphere and asked me to join them; I was able to split my time between the university and Medsphere for a couple of years. Then in 2005, they landed their first client and we were building more products, so I joined the company full time.

That was really my first experience in healthcare (and in a startup) and I just loved it. I stayed with Medsphere until about 2010, at which time I started working with a series of startups. The first was a joint venture between Johns Hopkins and Harris Corp, building open source cloud-based diagnostic imaging infrastructure. I then moved on to Mirth Corporation, a data interoperability and health data repository company. I was part of the integration team when Mirth was acquired by NextGen Healthcare. When the acquisition was finished, the CTO asked me to lead the teams building their next generation cloud-based EHR and Practice management SaaS service. I was tasked with growing the team to 175 product managers, designers,  software engineers, and QA testers. I learned a lot about managing engineering organizations at scale with teams in Orange County, Austin, Atlanta, and Bangalore. However, I came to realize that too little of my time was spent building the product — I was too far from what I loved doing. As great as my teams were, I was tired of managing and wanted to build again. When all the travel finally caught up with me and my family, the decision was easy.

I took a CTO role with a San Diego startup that was doing remote telehealth for physical therapy. The product used a 3D sensor to track motion, while using a game engine to create a “gamified” interface and a virtual physical therapist that coached the patient through their home exercise plan. The PT’s used a web application to prescribe and manage the patient’s HEPs, deploy screening tools, and track their patient’s progress.  After about a year, the commute to San Diego on the train caught up with me. My wife and I considered moving South, but we didn’t think the  schools in San Diego were a good fit for our younger son. I had a good relationship with the CEO, and we talked candidly through some potential exit scenarios that would be mutually acceptable and maintain stability while they looked for my replacement. 

With this trajectory, how did you end up at Crossover?

Right around that time (around the summer of 2016), Scott called me out of the blue. It had been about ten years since we last talked and he said, “Hey, could you do some consulting for me? I want to evaluate where we are from a tech and development perspective.” I did that for a couple of months, delivered a report with my recommendations, and then he called back. He asked me to join Crossover and the timing worked out well. I was finishing my transition out of my current role and I was seriously considering making a transition at that point anyway.

I had been in the software vendor world for so long, where the customers are disconnected from you. This seemed like an interesting opportunity to have your customer—your only customer—directly connected to the product development and what you’re building. And also, as a non-provider, being part of Crossover got me as close as I’d ever been to individual patient care. My father had been a paramedic as well as a firefighter, and had helped people all his life, and my mom had spent many years treating people too. It just felt like a real opportunity to be close to primary care and really change how patients experience care..

What do you think the role of technology is for care delivery?

From the provider perspective, it should assistive—designed to help remind, nudge, and manage the details, while giving the provider’s time and focus back to the patient. That’s one of the unique things about Crossover, given that we’re not part of the fee-for-service system, providers don’t have to collect data in order to bill, or focus on anything other than taking care of the patient. 

I’ve been working for close to twenty years in the healthcare system and still my family encounters continual frustration. It’s frustrating and impossible to navigate the disconnectedness of the system — and I know how it works. I cannot imagine how others feel as they get pinballed around. There’s this absurdity about how hard it is to move data, understand quality and pricing, or simply communicate with your provider. 

We can help our members find what they need instead of leaving them to flail around in the system — which is what most people end up doing. People are just used to what healthcare has always been, and to some degree, they accept the friction. It’s too hard to struggle and fight. Healthcare is looked at as something to be avoided, which is a great starting place for disruption.

What do you think technology’s role is in disrupting perceptions of what healthcare should be?

I think the asynchronous work at Crossover will be very disruptive. You couldn’t do it in the current fee-for-service environment in the US, and that’s one of the great things about the model we’ve built. It gives us the freedom to invest,  innovate, and iterate on what helps our members, not just what’s billable. Crossover has coined the phrase “Digital First and Strategically In Person” which is a real differentiator and a huge win for providers and members alike.

The other role technology plays is to address expectations about convenience, how the consumer is going to be treated, and how the experience is designed with them in the middle. We encounter this in many other areas of our lives and people are beginning to expect the same of Healthcare. Crossover’s care delivery  should be empowering and convenient. Everything seamless, everything connected. And this goes back to my original point—the technology isn’t the thing, the care model is the thing. We will have done our jobs well when what our team is producing is “in the background,” is incredibly simple, and enables the core care model for both providers and members.

You started as VP of Technology when you joined. What is your role now and how has it evolved?

When I joined we had a very small development team, a couple of consultants, and a couple of developers in-house working on the legacy product, our member engagement portal. As early as 2018, we acknowledged our existing in-person care model needed to evolve—in order to impact more members, we needed greater reach. We couldn’t be tethered to our physical centers and needed a strategy to develop a virtual service offering. At that point, with a lot of support from Scott, we started to build a development team to align with our objectives.

When Jay joined, the intent was always to transfer the product team to him. When Crossover and Jay began discussing our shared vision for care, Jay and I invested time in understanding how we’d work together. It’s super important that the engineering and product leaders see eye to eye—we need to be in sync. We bring different skills and experiences to the table and that diversity makes the overall process and product better.

Product’s process starts with the user interface design, and a little bit of the user interaction design. Then they take these designs and decompose them down into the detailed requirements that the development team builds from. They’re in the form of what we call “user stories,” a key component of the agile methodology. We have worked over the last six months to educate our medical group and clinical operations stakeholders on product development so they can directly contribute to the product vision. We are fortunate to have our “customers” on the team, building right alongside us. 

Agile development includes tight feedback processes, where the engineering team will ask questions about the user stories, collaborate with product on refinements, and estimate the feature or enhancement (a process we call “pointing”). The work is prioritized and planned into development sprints. These sprints are short, three week efforts to produce and ship business value in small increments that build upon themselves. 

We have also had to develop a process whereby we can break stalemates or make decisions when there are two equally viable approaches. Understandably, this decision-making process has been something we have had to work at—across our medical group, operations, product, and engineering there is a lot of experience and vision. We have been working to build a process and prioritization rubric that reflects the Crossover culture and vision and have begun to hit our stride as a cross-functional team. It has been a team effort and we anticipate we will continuously improve the approach. 

In Part 2 of our conversation with Ben, he speaks about our new asynchronous care technology, the impact of the pandemic, the powerful role Crossover’s values play in his own approach, and how his team works together to deliver innovation.