November 5, 2024 • 35 mins
In this episode of Making Data Matter, we are joined by Jessi Smith - Business Intelligence Manager at CareOregon.
This conversation offers you insights about:
- Data cloud migration wins and roadblocks
- Managing Expectations with stakeholders
- All the moving pieces required for successful data governance
and more.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
Welcome to Making Data Matter, where we have conversations about data leadership at mission-driven organizations
(00:06):
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,
(00:27):
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
(00:47):
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
(01:13):
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.
(01:33):
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
(01:55):
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
(02:19):
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
(02:42):
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
(03:03):
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
(03:24):
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
(03:47):
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.
(04:09):
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
(04:32):
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
(04:58):
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
(05:20):
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
(05:42):
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
(06:03):
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
(06:25):
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,
(06:49):
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
(07:10):
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
(07:34):
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
(08:00):
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
(08:20):
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
(08:45):
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
(09:09):
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
(09:29):
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
(09:55):
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
(10:20):
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
(10:43):
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
(11:09):
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
(11:31):
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
(11:51):
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
(12:13):
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
(12:36):
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
(12:59):
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
(13:22):
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,
(13:45):
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
(14:07):
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
(14:28):
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
(14:49):
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
(15:14):
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
(15:38):
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
(15:59):
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
(16:21):
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.
(16:44):
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
(17:04):
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
(17:25):
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
(17:51):
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
(18:14):
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
(18:36):
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
(18:59):
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
(19:25):
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
(19:46):
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
(20:07):
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
(20:28):
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
(20:49):
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
(21:10):
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
(21:33):
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
(21:54):
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
(22:15):
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
(22:37):
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
(23:00):
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
(23:22):
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
(23:46):
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
(24:08):
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
(24:30):
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
(24:56):
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
(25:21):
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
(25:46):
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
(26:11):
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
(26:33):
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
(26:59):
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
(27:20):
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
(27:42):
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
(28:05):
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
(28:29):
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
(28:54):
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
(29:17):
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
(29:37):
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
(30:01):
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
(30:24):
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
(30:45):
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
(31:10):
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.
(31:37):
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
(32:00):
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
(32:22):
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
(32:48):
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
(33:12):
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
(33:34):
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
(33:55):
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
(34:18):
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
(34:45):
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
(35:08):
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.
Welcome to Making Data Matter, where we have conversations about data leadership at mission-driven organizations
(00:06):
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,
(00:27):
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
(00:47):
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
(01:13):
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.
(01:33):
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
(01:55):
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
(02:19):
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
(02:42):
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
(03:03):
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
(03:24):
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
(03:47):
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.
(04:09):
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
(04:32):
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
(04:58):
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
(05:20):
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
(05:42):
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
(06:03):
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
(06:25):
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,
(06:49):
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
(07:10):
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
(07:34):
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
(08:00):
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
(08:20):
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
(08:45):
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
(09:09):
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
(09:29):
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
(09:55):
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
(10:20):
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
(10:43):
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
(11:09):
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
(11:31):
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
(11:51):
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
(12:13):
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
(12:36):
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
(12:59):
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
(13:22):
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,
(13:45):
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
(14:07):
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
(14:28):
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
(14:49):
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
(15:14):
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
(15:38):
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
(15:59):
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
(16:21):
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.
(16:44):
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
(17:04):
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
(17:25):
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
(17:51):
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
(18:14):
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
(18:36):
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
(18:59):
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
(19:25):
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
(19:46):
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
(20:07):
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
(20:28):
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
(20:49):
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
(21:10):
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
(21:33):
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
(21:54):
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
(22:15):
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
(22:37):
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
(23:00):
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
(23:22):
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
(23:46):
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
(24:08):
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
(24:30):
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
(24:56):
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
(25:21):
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
(25:46):
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
(26:11):
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
(26:33):
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
(26:59):
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
(27:20):
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
(27:42):
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
(28:05):
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
(28:29):
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
(28:54):
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
(29:17):
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
(29:37):
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
(30:01):
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
(30:24):
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
(30:45):
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
(31:10):
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.
(31:37):
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
(32:00):
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
(32:22):
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
(32:48):
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
(33:12):
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
(33:34):
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
(33:55):
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
(34:18):
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
(34:45):
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
(35:08):
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.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Special Summer Offer: Exclusively on Apple Podcasts, try our Dateline Premium subscription completely free for one month! With Dateline Premium, you get every episode ad-free plus exclusive bonus content.
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!