How journey teams transformed IT at Ochsner Health

New Orleans-based nonprofit Ochsner Health has reimagined its technology organization by shifting from a traditional siloed IT structure to an innovative journey teams model. Under the leadership of CIO Amy Trainor, this transformation focuses on delivering seamless experiences rather than managing specific technologies. By organizing teams around user journeys instead of applications, Ochsner has created a more responsive and effective healthcare tech organization to provide better service.

At Ochsner, you shifted a technology structured IT team to a journey teams model. What was the driver behind this change?

It started with our recognition that we needed clearer accountability, faster decision making, and a focus on experience more than technology. In the past, when people had technical issues, our team was so specialized in hardware, presentation software, or [electronic health record system] Epic that nobody understood the big picture. A ticket would move through 10 rounds of “That’s not my area” before it’d be resolved.

This was really evident during go-live events, where workflows that crossed departments would require multiple teams. I started thinking about how we could rethink teams based on the experiences we want to deliver, not by their technologies.

Why were journey teams the solution to this fragmentation?

The journey model allows healthcare technology teams, which have traditionally prioritized applications over experiences, to shift focus to providers, patients, and employees. Regardless of application areas, journey teams are responsible for the user experience, which includes everything from the icons on their desktop, workflows, log in, and  the applications they use.

This journey team is also charged with prioritizing investments, deciding on the technology we’re going to use, and the roadmap to build and deploy. The new focus on prioritization is the real win. A traditional healthcare IT department never gets to prioritize, because everything is always considered a top priority. The focus on prioritization drives a more strategic mindset than just moving through a list of projects.

How did you structure the teams?

We knew the hardest part of this transformation would be helping people understand their new roles and stay in their lane. So we were very careful about defining the core roles. Who makes the key decisions? Who builds the roadmap? Who needs to be at the table to ensure success? These questions led us to define five different roles: solution architect, IT leader, product manager, scrum masters, and business leader. In our provider journey team, for example, the business leader is our associate chief medical information officer.

The five key journey team members know the work that needs to be done, work that’s coming in, and how to design scrum teams to manage that work. These scrum teams don’t report to the journey teams; they might be in telecoms, a revenue cycle apps person, and a third-party clinical systems expert. They’re all assigned to this journey, and while they don’t formally report to a journey team member, all of their work comes from the journey team.

The only new roles we funded were product managers. Some roles were changed as part of the process change. Our traditional waterfall project managers, for example, took scrum master training and stepped into that position. This has been a great career growth opportunity.

What benefits are you seeing from the journey team model?

Our focus on metrics is where I see the biggest wins. In the past, we’d complete a project, move on to the next one, and then the next. Journey teams work differently. They evaluate the results of the project: How many defects did we have? How many tickets did we get? Are we getting the ROI we expected from doing these new things? There’s enormous value in having a product manager take an objective approach to the data and the roadmap.

When you work on a project for a long time, it becomes very personal, and that can make it difficult to maintain perspective to see the big picture, to see when things don’t go as expected. Probably the biggest value of the journey teams is they can step back and look objectively at the project, including the stats, story, user feedback, and where we need to go next.

With a greater understanding of the goals at the beginning of the project, we’re getting projects done more quickly and in a more organized fashion. Our roadmapping has improved, as well. In the past, we roadmapped at the application level, but now we do it at the journey level. For example, rather than talk about the roadmap for clinical applications, we talk about the physician roadmap for 2025.

Our physician engagement is better as well. Our physicians help to develop our roadmaps for managed care, patient, and provider journeys. They have a seat at the table to prioritize and work through roadmaps, and in turn, develop buy in to the plan.

What’s your advice for CIOs who want to move to a journey team model?

Define the roles and resources very carefully. Have real conversations with your leadership team about why you’re doing this and how their jobs will change from leading a tech team to leading a cross-functional team. They’re no longer tech subject matter experts; they’re leaders of people.

Once you have the team set, find a small area where you can have a win, and then they can tell the story for you. We started with our managed care group because their user base is smaller than other areas. Once we were successful with managed care, they told the story to everyone else.  The teams start buying in to the approach by observing and asking their peers, which is much more effective than hearing the why from their CIO.

I’d also focus on empowerment. Your journey team of five must be empowered to make decisions. When there’s conflict on a journey team and it bubbles up to me, as CIO, I tell them this is a democracy, and they all have a seat at the table. They’re empowered to resolve the problem among themselves. It’s important we remove barriers for them, but that the decision-making power continues within the journey team.

On that note, we created decision-making guiding principles, like “give clinicians time to care” or “we have a standard source of truth” so when new employees come into the organization, we train on these principles and empower even the newest employees to make their own decisions.

What’s the primary skill you use as CIO to make these journey teams work?

I consider myself perfecting skills in sales. Our executive team members need real-life examples of experience and impact so they can understand the transformation. I pride myself in being relatable. I can bring the most advanced technology to our leadership team and translate what it means to them. Whether the topic is cloud migration, private cloud, or phishing, my job is not to be an expert in technology. I have senior teams for that. My job is to take highly technical subject matter and synthesize it into something people can understand and get behind. Another way to say it, in addition to sales, is I’m opening their minds to things they weren’t thinking through before, and I’m giving them very specific guardrails, action items, and takeaways.