Welcome to Making Data Matter, where we have conversations about data leadership at mission-driven organizations with practical insights into the intersection between nonprofit mission strategy and data. I'm your host, Sawyer Nyquist. And I'm your co-host, Troy Dueck. And today we're joined by guest Jessie Smith. Jessie, welcome to the show. Hi, thank you.
Jessie, for our listeners who are hearing your name for the first time, can you tell us a little bit about who you are, where you work, what you do? Yes. So I work for Care Oregon, which provides a nonprofit that provides health insurance to low income Oregonians. We have Medicaid and we have a Medicare line of business. So we're serving just
the Oregon population and I am the business intelligence manager. So I've been working with Care Oregon for six years and I've really been able to kind of grow in my analytics career there. Now, tell me about first the nature of Care Oregon. Is that an organization that exists? I'm not familiar with that in my state, in Michigan. Is that an organization that exists in a lot of different flavors in different states or is that kind of something unique to Oregon?
It's very unique to Oregon, actually. So we have a model called the coordinated care model that is very specific to Oregon and the way that we can work with our network providers to provide care to our members. And so Care Oregon has two CCOs. We have Jackson Care Connect and Columbia Pacific. And then we also report up to another CCO, Health Share of Oregon. So we serve three different regions in the state of Oregon.
Very cool. And tell me about then your team and the type of work that you do with data at Care Oregon. So my team is the business intelligence team. We focus on reports and dashboards specifically at like operational reports and enterprise level dashboards because we do have department analysts throughout the entire organization that will also be doing reports and dashboards. So ours is more enterprise level, reoccurring dashboards or reoccurring reports. And then our
team is situated under the ITIS umbrella. So we just have access to a lot of the data. We're working with a lot of the technical teams, whereas some of the department analysts are really under a business umbrella. And if they're an analyst, they'll be working with data under that specific business umbrella department that they're in. That's great. And I want to jump in and ask Jesse a little bit about the handoff then between the
data pipeline people, I'll say it pretty broadly like that, to your team. So what point does that baton get passed over from those who are managing the databases, the servers, doing the data engineering, ETL kind of work, and when do you guys pick it up and run with it? I guess when their pipeline is complete. That's one of the things I try to tell people all the time when they're like, we need this dashboard updated. I'm like, okay, well, the assumption is
that it needs to be ingested and it needs to be transformed. It needs to be in the warehouse. It needs to be available. And then our team can pick it up and start to make updates. That was one of the things I was thinking of about kind of the culture of data that we do have a lot of leaders engaged and wanting data. But I think people really underestimate how long it can take to get data to where it needs to be to be usable. And so they think, well, it's there, put it in the
dashboard. And a lot of times I have to say there's three teams ahead of me that need to work this before it's going to get to my team. Okay. And don't stop there. Tell us maybe even if you want to go into your tech stack and talk a little bit about data architecture. What does that look like for Care Oregon? What are those three steps that have to happen before it gets to you? Yeah. So I would say ingestion, really getting it into our data warehouse, our enterprise data
warehouse, but there's levels there too. So there's kind of that it's just staged, just sitting there. Then do we need to maybe apply some business logic, get it to a more, a layer that's more at an analysis layer. So we refer to those different layers in our warehouse. It can be more raw and we can try to use that. It can be a little bit more structured, semi-structured. We can use that, but like the goal is to get everything into this analysis layer where we really have everything
defined and the business logic is there. When it gets to that analysis layer, then we want to share it with the whole company. So everyone in the organization, this is our highest quality source of truth data. And so yeah, just kind of getting it through those different layers. But what can be difficult is again, time, resources, but then also I think our biggest pain point is those of us in IES don't necessarily have all the business knowledge. And so we have to really work and
collaborate with the business who may not be very technical and data savvy. And so how, when we're speaking these two languages, we have to make that bridge and how to get this data that's going to be useful for the business. Okay. Couple of things you brought up there we need to spend some time on that language translation between business and IT. I want to get to that. I'm going to put that in the back burner right now, but the layers of kind of data or transformation needs to happen and
cleaning. I think sometimes if you're a data professional, you really take that for granted. Like, yes, we did to do all that. But I run into business leaders and nonprofit leaders regularly who don't see necessarily understand why that's necessary or just assume if the data is in the source systems, you can just go grab it and work with it. Tell me about the, like, what is the value for putting the data in a data warehouse or modeling it or doing that business logic?
Where do you see the value as opposed to, Jesse, why don't you just go to the source system and get it for me? I think sometimes the business folks, because they don't get, they're not working in that data. They always think of data at the end stage, which is modeled, which has quality, which has it's in a really good condition. And so when we say, oh, but this data over here is in raw stage or it's not structured, like they don't even know what that means. I think they kind of think
of like an Excel spreadsheet, there's columns, like, isn't that what all data looks like? And they don't understand that, you know, it cannot be structured and quite useful and have that quality. So it's definitely part of our job, I think, to teach the business that language and the importance of modeling it and improving the quality of it. And that's part of our data governance strategy,
too. I think that might be a fun topic to talk about that we're trying to really have more forums where we are sharing this information out to not only our analyst community, but leaders, business leaders who might have an analyst on their team, but they're not data people themselves, they just have a data analyst on their team. So teaching them about like what it takes to get modeled data, quality data, structured data that when it is in that source system. I mean, sometimes
the message is just simply clear for me, I go, I can't use that. That's all there is to it. You don't have to understand all the details. We can't use it at that stage. What are some of those data quality things that you run into? Because when I think about maybe data in my CRM or data in my patient care records or things like that, like, hey, that data is fine. What are like data quality issues that make it unusable from like a reporting or analytics perspective where you're at?
So sometimes we run into timeliness of data. In our warehouse, our data warehouse, there's a one-day lag in data, which is generally fine for most situations. But there are use cases where people need to know what that data is looking like right now in this instance, they need that live data. So timeliness can affect where we're pointing to what kind of report we're using, what the use case is. Sometimes I've seen the business wants live data, but that's not necessarily really needed or
required. They just want it. And so we kind of have to have conversations to negotiate that. Another quality aspect might be maybe some of the values in there, or I guess what I've seen is like process. So sometimes that can be the hardest to solve is where do I go for the right data? And part of it is, well, there's teams that are entering in this data and have processes. And if they're not selecting the right values, or there's not a clear process on where to go,
we might need to go to like three different places to get this value. And that's not really ideal, because that's really hard to code for. So some of it can just be business process that can create some of those issues. Other times it can be the model, the structure of the data. If we didn't have the right information in our requirements, again, that gap between business knowledge and IS, maybe we put something in there that we thought was useful. And then when people
start using it, they go, this doesn't seem right. Now that they're coming in from the business perspective, they're like, this doesn't seem right, this doesn't make sense. And that's just part of that critical feedback and the back and forth that needs to happen between us to get it to the right quality. Yeah, everything you're talking about so far, Jesse, sounds a lot like managing expectations, whether it's coming from high level leaders to the data analysts to the
people writing the pipelines, there's always this, how do you manage expectations? So as you're thinking about that, what is your process? Even feel free to give us an example of what it looks like for you to manage those expectations, whether it's upfront, and you're trying to be proactive and doing that, or whether it's reactive, you get that request coming in, it feels like it's out in the left field, or they're throwing you a curveball. How do you manage expectations? I personally try
to be proactive where I can. I think it can be difficult to manage expectations depending on the system that you're operating all these requests through. So previously, we just kind of had a request queue, and they were all coming in directly to my team if that was the right thing. And so I'm like managing, you know, a whole backlog of requests that come from all over the place. And plus, there's other projects coming in from our enterprise and from our department. And there wasn't a
resource transparency on that. It was just kind of like on me to say, I can or cannot do this. One of the things our company has done recently is really implement a resource planning perspective through
ServiceNow. And so now we're able to have a lot more transparency and to set these expectations and have really good dialogue about, you know, one, the business needs to be very clear about what they want, because there's times where they say, I want this, and I say, I can deliver it to you at this time, and then I deliver it, and they say, well, that's not quite it. So did I not deliver it, or were we not clear on what you wanted? So it's part of the business helping them figure out what they
want. But then also us, you know, there's never a dull moment in analytics and IS. There's always work to do. There's always data coming in. So when there's a thousand things to do, what are the 100 that we can do? And so I think having this system where we have our IS leaders and business leaders involved in having those transparent conversations about, well, this is how much it's really going to take if you want us to do this. And then if you want us to do this other thing, the question is
always, well, what are we going to have to not do in order to do this thing? So there's a little bit of a system in our organization that's helped us to really be more proactive in those conversations and to support outright saying, this is how much that's going to cost in time and resources. What do you want me to, what is the most important thing you want me to work on right now?
Yeah. Do you have an example of what that looked like for you on your team and a particular project maybe where, you know, you had this priority and another one came in and you wrestled through that and what the conversations were like, you know, putting the meat on the bones in terms of, you know, it's great to have a proactive approach in how we do this, but what's it look like in the real world when you finally get that request coming in and it's causing you to pivot and you have to think
through and actually follow that process? Luckily, sometimes the priorities are set for us. So, you know, when something comes up, sometimes it's, this is just the priority and that's what you pivot to and that can make it very clear. I think that comes from good leadership explaining what the priorities are. Whenever I'm confused, that's the question I ask and I get clear answers, which is important.
I think another thing that I'm thinking of here is helping the business understand a cutoff point. So, one example is we had like a project where we were implementing this new care coordination platform and so we had a new source of data and we had to update some reports. Now, being very clear about what's in scope in that project were these specific reports, but also it's new data and there's new logic and so you're kind of always iterating and evolving and we could do that for the rest of
the year. I mean, we could do this project for the entire year. I had to step in and kind of say, here's the stop line where we're doing a project. Yeah, exactly and it's my biggest priority and the rest of this is now going to become outside of the project and will be prioritized accordingly
to all the other things that are going on. So, sometimes that's part of the conversation is right now you are under an enterprise project and so you are the most important thing, but there's a stop point where now you just need to be prioritized among everything else because we have tons of other projects going on and the business has been receptive to that conversation, which makes my job easier. How large is the organization? Like how many stakeholders or
business units are you working with? It sounds like a larger organization with the amount of people coming through. So, tell me a little bit about the size of the number of stakeholders you're working with. I would say we're a medium-sized organization. I hope I get this number right, but I think our employees are about 1500 right now and then I would say, you know, we don't work with every department in the organization, but I would say probably 10 to
15 different departments. Some of those having lots of requests and some of those maybe we only have one request from them. So, I would say our operations, claims, enrollment, these certain like domains there are some of our biggest customers. Honestly, actually our biggest
customer is us, ourselves. We create a lot of work ourselves in IS and so, you know, right now we have a lot of migration work and tech debt that we're doing and updating things or new systems coming in and so again, I mean, my backlog, most of the work is coming from us, ourselves and the work that we need to do. Yeah, I mean 1500 employees though is a big enough organization where you are running into process challenges or data challenges that are more complex to solve than a couple
hundred employees. Yes, and one comment on that, I would say another added complexity is just again the unique way of our organization and the regulatory environment and that if our state says they we need to implement a new benefit in 2025, we need to implement a new benefit in 2025 and if Medicare says we need to start reporting in a certain way, we need to start reporting in a certain way and because these governing bodies are trying to improve and do better with health care
every year there's something new that we have to do and so I always tell people who are new that what kind of feels like a startup, you know, there's no resting. There's always a new project, there's a new benefit, there's a new population, there's a new report. Now we are growing and so we have new systems and that and so that makes your data change. It makes the report you did three years
ago you don't need to do because there's a new requirement to it this year. There's a new benefit so yeah, there's just lots of things that can kind of change the work in the direction that we focus on. Yeah and so you mentioned this earlier but that sounds like a challenge from a data governance perspective of keeping track of shifting products and shifting data sources as well as like the PII side of things and the sensitive data. So tell me about you said data governance initiative,
what kind of work or and where did that come out of? What was the need and and what kind of work are you doing now around data governance to make that effective? We do have a team, our analytics program services that's focused on data governance. It has really kind of all grown in-house, you know, as your data literacy scales, your data available scales, your governance has to scale so you can't have a really structured whole team program when you only have a few analysts. So it starts very
small and then we just had to build it out. Now we actually have a team and some more formal parts of it. So I would say the aspects of our data governance are we have training and trainers that actually support some of the like on-demand trainings or rolling out to our forums. Our forums being we have like a analytics skills community where just our analysts come to. We have a
community of practice where analysts and maybe their leaders might come to. We have a weekly email that goes out to the whole organization and now we have a little analytics corner there for updates. We have team chats that people can go to to kind of ask those questions like what's going on with this data source? Is there an issue? So lots of change management of like disseminating information out to everybody to know the tools to go to, to know where to go to get the information.
We have a reporting and analytics like SharePoint page, landing page with lots of references there. So what's your question about this data? What do I do if I if I have a concern about it? What's some more resources and learning on it? People can go there. Then we have like formal policies and things like that that are you know cataloged and registered in certain places. So I think a lot of it has just been the touch points to our analytics community of teaching them the technical terms,
how to think about data, data literacy. We do an annual survey to kind of get a pulse on this as well and measure against ourselves. So it's pretty cool I think. And really broad too like you just highlighted the well probably the reason a lot of data governance initiatives fail is because they involve so many different parts of the people and the process as well as some technology elements to be successful. Like how do we think about data holistically and stewarding it well and training
people to use it well and think about it well. And the scaling too. So we have a data catalog that we have implemented and we want people using it but we also need people using it to add the information to make it usable. But how do you get people to you know so it's like this catch-22. And so we've we're focused on like our glossary terms but we recently got feedback that people are like well we really want to know dictionary data dictionary definitions for the tables and that isn't something
we've been focused on. So we're at this point where like if we do not enhance this other aspect of the data catalog we've kind of hit our limit on people wanting to use it. But now we need to get the resources to get people to put that information in there. So you have issues like that where you need to balance scaling it. Earlier you mentioned tech debt and like a lot of migrations or initiatives happening and actually before the call you mentioned briefly you're doing a cloud
migration. So I'd love to hear about some of the challenges you face and even maybe why that seemed like a priority to do now. A lot of companies just stayed on on prem for a long time. What was was there a decision point that led to that and then what's that journey been like so far? I wasn't part of the conversations to make the decision but from what I've gathered it came to storage and cost. You know we just we've been around for 30 years. We have a lot of historical
data. We have data that comes from so many different places. We just have a lot of it. And so it costs you know we start hitting performance issues and cost issues for being on prem and so to see the trajectory and growth of our company it just made sense that it was time to go to the cloud. And then what's the other question kind of? Oh yeah what's the journey been like and yeah what kind of roadblocks have you hit or there's a big sigh for everybody now.
Yes. Why you gotta bring up roadblocks Sawyer? Come on. Sorry, sorry. I'm sure it's been smooth sailing. Basically I would summarize like it's just not as easy and as straightforward as you're going to plan and think for it to be. So we've had plan A and plan B and plan C. I think we're on plan E right now. Like I we were given I think one good thing is to set a like a cutoff date. Here's the
date we want you to be off this on-prem database and to be on the cloud database. We are had an initial date and had to move it six months out and I think we're close to meeting that but it might not be perfect either. So it's like good to have a plan A and it's good to have a date but if you're one of those leaders in there just know you're not going to make that date and you're not going to be
on plan A because there's just a lot of things that come up that are unanticipated. I think one thing from my perspective too is there are teams that are really focused on just that data warehouse migration but I'm the business intelligence team that has all the downstream impacts that okay now
my report that I use my reporting tool that I use isn't compatible. Now we have and then you have your kind of workaround plans where it's like this isn't ideal now we're going to do this well now there's a security risk so now we have to think about that then that's creating tech debt of things we'll have to clean up next year and okay so if we're going to use this tool you know now we're looking at a new tool we're going to go from SSRS to Power BI. What's the compatibility there? Do we
need another tool to do something there? So there's just been lots of like learning growth discovering and then teams looking at it from different perspectives and again like I said in order to meet a date you know there's sometimes kind of like well this is the path we need to take right now to get there it might not be ideal but it's the path we need to get there for right now.
And with a lot of migration efforts you have an opportunity to look at tech debt as it currently exists within your architecture and think okay are we going to do a true lift and shift and just plop our tech debt over here in a new environment or are we going to redesign a little bit are we going to find opportunity to enhance? Well those are now going to be in conflict with each other because you've got to migrate by a certain date but you've got all this vision for how much better
it'll be when it's finally over there but it requires the time to do that. So how do you determine between what points are true lift and shift? We're just going to take this and plop it over here and then here's the things that are non-negotiable we need to rewrite if we're going to go through this effort to go from on-prem to the cloud. What does that look like from your perspective in the BI knowing that some of that is more you just handling the consequences of the
migration not even necessarily involved in the migration. How do you argue for please change that if you're going to do this change that for me so by the time I'm connecting in my BI tool it's better than what it was before. So anything on that front, Jessie? Yeah I think that's a good point and I think that is definitely part of the journey as you start with this ideal vision of how it's going to be and then reality hits and you realize maybe that takes way too long to do and
so you do have to start pivoting to lift and shift. I think there's not a clear answer unfortunately
it's kind of case by case and the key is collaboration. So there's an example now that we're doing where we meet with our EDW team on a weekly basis because we do have these certain cases where does it make sense to lift and shift or rebuild or what are the options you know and it's like we have 20 different cases and the answer is going to be different for each scenario and so it's a matter of going through each scenario with all the right people involved our team the
BI team as well as the EDW team and going what makes sense here what's the purpose of this report what's the long-term thing what makes sense here do we have tables that we could use instead that might help this that we can repoint to a different data source sometimes I'm even having to log things like this is what we're going to do in the short term but we have stuff to clean up in 2025 so make sure we log all of that and try to start that next year. So it's definitely not always clear
and I think again key is just having good collaboration with other teams. One other thing we did is we have lots of databases but we're focused on migrating one specific database. Our vision is that everyone would go to EDW database and so that's really the only one we're focused on migrating which gives us a chance to kind of work on how do we want to clean up some of the other ones and again to the it's case by case on is this worth migrating or is this something that
is not used and so we don't migrate it over. I think we do the best I think there's definitely gray areas where you're migrating things that don't need to be migrated duplication happens at times it's just messy but we do the best we can to lift what we need to over there and if it's not
usable we don't move it over there. One thing one more note on that is having a date of not putting anything else on prem so we had a cutoff date now with all this new data it does not go on prem anymore so now it has to be on our cloud on Snowflake so that also helps that way you're not
continuing to build things on prem during a migration. I love the because the story that comes from the salespeople at Microsoft or AWS or Snowflake or wherever is about how clean and smooth and I've been in those meetings before about how easy a cloud migration can be with lots of tools and you know easy assistance or consulting firm will come in and tell you how smooth it is so I'm so glad we've got some reality here because there are lots of bumps
and challenges and trade-offs and varying degrees of payoff for different situations. Trade-off is a great word because that's definitely part of the conversation. I mean someone might think well if it's going to get so messy why have the date to migrate just push it off but you need to have a date you need to have a timeline and a goal to get there or you could push that timeline off forever so it is a trade-off for sure on how to get there.
Yeah how have you handled upskilling or changing the skill set of your team to adapt to different cloud tools or different tooling you mentioned maybe a shift to Power BI or Snowflake so tell me about the upskilling that you've had to approach and deal with. I think it helps to have a team that loves learning and loves technology and loves upskilling so that's good because they're genuinely interested. I think we usually try to take a few members of the team that's kind of a
pilot crew that can really give all their time onto learning those new tools. We work with the analytics program side and the trainers to document those best practices develop some of those trainings and work together there and then from there start to share that out with the rest of our team and then from there start to share that out with the whole analytics community.
That's cool just identifying those who are naturally curious and their inventors and saying I want to task you with the lion's share of trying to figure this out stitch it together and then you can promulgate that out through the rest of the organization that's cool.
Yes and then it kind of come back to collaboration again my team despite being in a remote environment is wonderful at being collaborative as well and so I think another thing they've done is they have a weekly water cooler is what they call it where they all just meet because they're remote and it becomes a sharing session so the three people that were starting to rewrite all their code into Snowflake start to share out there or at team meetings or in certain forums so that the whole
team can now see what they're doing and start to learn how to rewrite in Snowflake and then when we assign things for some of the newer members we partner them with the people who've already done it and so there's a lot of mentorship and collaboration of okay these two folks have done a lot of it now that we're getting three other folks into it you two need to meet together to kind of
work through those problems of rewriting it in Snowflake sequel. The theme of this episode has just been collaboration because I've been hearing like from the beginning of what it's like to deal with all these different voices and prioritization and then collaboration on tech migrations and then collaboration on upscaling. Yes so that's that's I love that theme and that
thread going through this. Jesse tell us a bit more about your background and how you landed in data work and maybe why you landed at CARE Oregon and what that what your journey has been like to
get to where you're at and why you're still here. Sure I think I kind of accidentally luckily ended up here I was not so a lot of my team are like people who studied computer science and computer engineering I'm a psychology major so I um I worked in social services for many years so I've worked in non-profit for a while and I worked with children and families and just kind of saw that I didn't
see the whole career trajectory going where I wanted it to be there. Also with psychology a lot of times when you're moving up in a psychology degree you're doing counseling and I did not want to do clinical work or counseling I was very sure about that so I ended up going back to school for a master's in psychology but it was a research degree not clinical and so I learned a lot about research methods quantitative statistics and that's kind of where I found the science math portion
but on people I love when my data is people and so then after that I got I got a job as a program evaluator and I started getting interested in being an analyst from the statistics work that I did.
So then I moved from Florida to Oregon and I just luckily got my job at Care Oregon and found it to be such a wonderful fit in the healthcare space because again we get the funding to scale and invest in our analytics because we're healthcare but the data is people which is something I can care about and uniquely in Oregon it can be a mission-centered organization a non-profit whereas in another state if I was working for a healthcare organization it would probably be
a for-profit healthcare organization with a Medicaid line of business to it so it's really special here in Oregon and so then we have a great culture at Care Oregon they really support the growth and support of our staff so I was a data specialist for a while then I became a data analyst then I became the BI supervisor and now I'm a BI manager so I've really grown in my analytics
career at Care Oregon. Yeah I love the merging of not just data and maybe research but people specifically and then how that's found a nice overlapping Venn diagram at Care Oregon that's great and Jesse as you look forward to the next call it six to twelve months what are you most excited about in your work with data or in what's happening at Care Oregon? So like next year? Yeah yeah we'll call it 2025 what are you looking forward to what's exciting for you on the horizon?
I haven't thought about next year very much because our migration deadline is the end of this year so I'm still very focused on this. I think what I'm a little excited about is some more kind of clean up and improvement projects. We do have a couple other databases that you know again we we've been around for a while our analytics teams have changed we have a database that was historically created
by a team 20-15 years ago that now we've inherited and it just needs to be updated. We don't need to point to certain sources it's hard to manage because it's reporting to these more source system databases rather than analysis tables so I've put in some requests for that project next year and to get the resourcing for that so I think that will be something I look forward to because it's also a project I want to do and it's not going to be you know some of the projects
leaders are choosing for us to do as they should but this is one that I'll personally feel invested in having my team work through and complete. Well I've got a completely different question for you I want to see if you know why did the data engineer order a thousand balloons? I don't know. Because he thought that was the best way to get the data in the cloud. Ordering a thousand balloons? This is like this is like up now the movie up yeah.
Oh the cloud that would make it easier cloud migration than some of the project plans I've seen. I mean we were talking about cloud migrations I had to sneak it in somewhere. Jesse this has been wonderful I love the practical nature of this conversation and yeah and how your work at CareOrgan has just meshed the people and the collaborative side of things with some more technical work. If people are interested in reaching out to you online or
find out more of CareOrgan where where's a good place to look for you? I would say my LinkedIn is probably the best. Excellent well thanks so much for joining us today. Thanks for being here Jesse. Yeah thank you Jesse and listeners thanks for joining us on this episode of Making Data Matter. We'll see you next time. Thank you.