1
00:00:00,000 --> 00:00:06,040
Welcome to Making Data Matter, where we have conversations about data leadership at mission-driven organizations

2
00:00:06,520 --> 00:00:12,560
with practical insights into the intersection between nonprofit mission strategy and data.

3
00:00:12,560 --> 00:00:19,480
I'm your host, Sawyer Nyquist. And I'm your co-host, Troy Dueck. And today we're joined by guest

4
00:00:19,760 --> 00:00:23,240
Jessie Smith. Jessie, welcome to the show. Hi, thank you.

5
00:00:23,800 --> 00:00:27,080
Jessie, for our listeners who are hearing your name for the first time,

6
00:00:27,080 --> 00:00:30,320
can you tell us a little bit about who you are, where you work, what you do?

7
00:00:30,720 --> 00:00:37,720
Yes. So I work for Care Oregon, which provides a nonprofit that provides health insurance to low

8
00:00:37,720 --> 00:00:43,360
income Oregonians. We have Medicaid and we have a Medicare line of business. So we're serving just

9
00:00:43,360 --> 00:00:47,920
the Oregon population and I am the business intelligence manager. So I've been working with

10
00:00:47,920 --> 00:00:53,920
Care Oregon for six years and I've really been able to kind of grow in my analytics career there.

11
00:00:53,920 --> 00:01:00,200
Now, tell me about first the nature of Care Oregon. Is that an organization that exists?

12
00:01:00,200 --> 00:01:03,480
I'm not familiar with that in my state, in Michigan. Is that an organization that exists in a lot of

13
00:01:03,480 --> 00:01:07,320
different flavors in different states or is that kind of something unique to Oregon?

14
00:01:07,640 --> 00:01:13,240
It's very unique to Oregon, actually. So we have a model called the coordinated care model that is

15
00:01:13,240 --> 00:01:19,160
very specific to Oregon and the way that we can work with our network providers to provide care

16
00:01:19,160 --> 00:01:26,760
to our members. And so Care Oregon has two CCOs. We have Jackson Care Connect and Columbia Pacific.

17
00:01:26,760 --> 00:01:31,960
And then we also report up to another CCO, Health Share of Oregon. So we serve three different

18
00:01:31,960 --> 00:01:33,640
regions in the state of Oregon.

19
00:01:33,640 --> 00:01:42,760
Very cool. And tell me about then your team and the type of work that you do with data at Care Oregon.

20
00:01:42,760 --> 00:01:50,200
So my team is the business intelligence team. We focus on reports and dashboards specifically at

21
00:01:50,200 --> 00:01:55,880
like operational reports and enterprise level dashboards because we do have department

22
00:01:55,880 --> 00:02:01,960
analysts throughout the entire organization that will also be doing reports and dashboards. So

23
00:02:01,960 --> 00:02:08,440
ours is more enterprise level, reoccurring dashboards or reoccurring reports. And then our

24
00:02:08,440 --> 00:02:14,520
team is situated under the ITIS umbrella. So we just have access to a lot of the data. We're

25
00:02:14,520 --> 00:02:19,560
working with a lot of the technical teams, whereas some of the department analysts are really under a

26
00:02:19,560 --> 00:02:24,520
business umbrella. And if they're an analyst, they'll be working with data under that specific

27
00:02:24,520 --> 00:02:26,840
business umbrella department that they're in.

28
00:02:27,720 --> 00:02:35,160
That's great. And I want to jump in and ask Jesse a little bit about the handoff then between the

29
00:02:35,160 --> 00:02:42,840
data pipeline people, I'll say it pretty broadly like that, to your team. So what point does that

30
00:02:42,840 --> 00:02:49,720
baton get passed over from those who are managing the databases, the servers, doing the data

31
00:02:49,720 --> 00:02:53,960
engineering, ETL kind of work, and when do you guys pick it up and run with it?

32
00:02:54,760 --> 00:02:59,400
I guess when their pipeline is complete. That's one of the things I try to tell people all the

33
00:02:59,400 --> 00:03:03,480
time when they're like, we need this dashboard updated. I'm like, okay, well, the assumption is

34
00:03:03,480 --> 00:03:07,960
that it needs to be ingested and it needs to be transformed. It needs to be in the warehouse.

35
00:03:07,960 --> 00:03:13,080
It needs to be available. And then our team can pick it up and start to make updates.

36
00:03:13,720 --> 00:03:18,840
That was one of the things I was thinking of about kind of the culture of data that we do have a lot

37
00:03:18,840 --> 00:03:24,600
of leaders engaged and wanting data. But I think people really underestimate how long it can take

38
00:03:24,600 --> 00:03:30,600
to get data to where it needs to be to be usable. And so they think, well, it's there, put it in the

39
00:03:30,600 --> 00:03:35,960
dashboard. And a lot of times I have to say there's three teams ahead of me that need to work this

40
00:03:35,960 --> 00:03:41,240
before it's going to get to my team. Okay. And don't stop there. Tell us maybe even if you

41
00:03:41,240 --> 00:03:47,240
want to go into your tech stack and talk a little bit about data architecture. What does that look

42
00:03:47,240 --> 00:03:51,240
like for Care Oregon? What are those three steps that have to happen before it gets to you?

43
00:03:51,240 --> 00:04:03,080
Yeah. So I would say ingestion, really getting it into our data warehouse, our enterprise data

44
00:04:03,080 --> 00:04:09,240
warehouse, but there's levels there too. So there's kind of that it's just staged, just sitting there.

45
00:04:09,960 --> 00:04:16,280
Then do we need to maybe apply some business logic, get it to a more, a layer that's more

46
00:04:16,280 --> 00:04:22,760
at an analysis layer. So we refer to those different layers in our warehouse. It can be more raw and we

47
00:04:22,760 --> 00:04:27,720
can try to use that. It can be a little bit more structured, semi-structured. We can use that, but

48
00:04:27,720 --> 00:04:32,600
like the goal is to get everything into this analysis layer where we really have everything

49
00:04:32,600 --> 00:04:38,200
defined and the business logic is there. When it gets to that analysis layer, then we want to share

50
00:04:38,200 --> 00:04:43,480
it with the whole company. So everyone in the organization, this is our highest quality source

51
00:04:43,480 --> 00:04:49,240
of truth data. And so yeah, just kind of getting it through those different layers. But what can be

52
00:04:49,240 --> 00:04:58,280
difficult is again, time, resources, but then also I think our biggest pain point is those of us in

53
00:04:58,280 --> 00:05:03,320
IES don't necessarily have all the business knowledge. And so we have to really work and

54
00:05:03,320 --> 00:05:09,960
collaborate with the business who may not be very technical and data savvy. And so how, when we're

55
00:05:09,960 --> 00:05:15,400
speaking these two languages, we have to make that bridge and how to get this data that's going to

56
00:05:15,400 --> 00:05:20,840
be useful for the business. Okay. Couple of things you brought up there we need to spend some time on

57
00:05:20,840 --> 00:05:25,240
that language translation between business and IT. I want to get to that. I'm going to put that in

58
00:05:25,240 --> 00:05:32,200
the back burner right now, but the layers of kind of data or transformation needs to happen and

59
00:05:32,200 --> 00:05:36,040
cleaning. I think sometimes if you're a data professional, you really take that for granted.

60
00:05:36,040 --> 00:05:42,280
Like, yes, we did to do all that. But I run into business leaders and nonprofit leaders regularly

61
00:05:42,280 --> 00:05:47,480
who don't see necessarily understand why that's necessary or just assume if the data is in the

62
00:05:47,480 --> 00:05:53,160
source systems, you can just go grab it and work with it. Tell me about the, like, what is the value

63
00:05:54,280 --> 00:05:59,960
for putting the data in a data warehouse or modeling it or doing that business logic?

64
00:05:59,960 --> 00:06:03,000
Where do you see the value as opposed to, Jesse, why don't you just go to the source system and get

65
00:06:03,000 --> 00:06:09,000
it for me? I think sometimes the business folks, because they don't get, they're not working in

66
00:06:09,000 --> 00:06:14,520
that data. They always think of data at the end stage, which is modeled, which has quality,

67
00:06:14,520 --> 00:06:21,320
which has it's in a really good condition. And so when we say, oh, but this data over here is in raw

68
00:06:21,320 --> 00:06:25,640
stage or it's not structured, like they don't even know what that means. I think they kind of think

69
00:06:25,640 --> 00:06:30,920
of like an Excel spreadsheet, there's columns, like, isn't that what all data looks like? And

70
00:06:30,920 --> 00:06:35,960
they don't understand that, you know, it cannot be structured and quite useful and have that quality.

71
00:06:35,960 --> 00:06:43,160
So it's definitely part of our job, I think, to teach the business that language and the importance

72
00:06:43,160 --> 00:06:49,080
of modeling it and improving the quality of it. And that's part of our data governance strategy,

73
00:06:49,080 --> 00:06:55,000
too. I think that might be a fun topic to talk about that we're trying to really have more forums

74
00:06:55,000 --> 00:07:00,200
where we are sharing this information out to not only our analyst community, but leaders,

75
00:07:00,200 --> 00:07:04,760
business leaders who might have an analyst on their team, but they're not data people themselves,

76
00:07:04,760 --> 00:07:10,600
they just have a data analyst on their team. So teaching them about like what it takes to get

77
00:07:10,600 --> 00:07:16,360
modeled data, quality data, structured data that when it is in that source system. I mean, sometimes

78
00:07:16,360 --> 00:07:20,360
the message is just simply clear for me, I go, I can't use that. That's all there is to it. You

79
00:07:20,360 --> 00:07:28,120
don't have to understand all the details. We can't use it at that stage. What are some of those data

80
00:07:28,120 --> 00:07:33,720
quality things that you run into? Because when I think about maybe data in my CRM or data in my

81
00:07:34,920 --> 00:07:39,400
patient care records or things like that, like, hey, that data is fine. What are like data quality

82
00:07:39,400 --> 00:07:44,680
issues that make it unusable from like a reporting or analytics perspective where you're at?

83
00:07:45,320 --> 00:07:54,280
So sometimes we run into timeliness of data. In our warehouse, our data warehouse, there's a one-day

84
00:07:54,280 --> 00:08:00,600
lag in data, which is generally fine for most situations. But there are use cases where people

85
00:08:00,600 --> 00:08:05,960
need to know what that data is looking like right now in this instance, they need that live data. So

86
00:08:06,520 --> 00:08:12,840
timeliness can affect where we're pointing to what kind of report we're using, what the use case is.

87
00:08:13,800 --> 00:08:20,840
Sometimes I've seen the business wants live data, but that's not necessarily really needed or

88
00:08:20,840 --> 00:08:25,640
required. They just want it. And so we kind of have to have conversations to negotiate that.

89
00:08:26,600 --> 00:08:33,960
Another quality aspect might be maybe some of the values in there, or I guess what I've seen is like

90
00:08:33,960 --> 00:08:40,360
process. So sometimes that can be the hardest to solve is where do I go for the right data?

91
00:08:40,360 --> 00:08:45,560
And part of it is, well, there's teams that are entering in this data and have processes. And if

92
00:08:45,560 --> 00:08:49,400
they're not selecting the right values, or there's not a clear process on where to go,

93
00:08:49,400 --> 00:08:53,320
we might need to go to like three different places to get this value. And that's not really

94
00:08:53,320 --> 00:08:58,520
ideal, because that's really hard to code for. So some of it can just be business process that can

95
00:08:59,080 --> 00:09:04,360
create some of those issues. Other times it can be the model, the structure of the data.

96
00:09:04,840 --> 00:09:09,080
If we didn't have the right information in our requirements, again, that gap between business

97
00:09:09,080 --> 00:09:15,720
knowledge and IS, maybe we put something in there that we thought was useful. And then when people

98
00:09:15,720 --> 00:09:19,640
start using it, they go, this doesn't seem right. Now that they're coming in from the business

99
00:09:19,640 --> 00:09:23,960
perspective, they're like, this doesn't seem right, this doesn't make sense. And that's just

100
00:09:23,960 --> 00:09:29,560
part of that critical feedback and the back and forth that needs to happen between us to get it

101
00:09:29,560 --> 00:09:34,600
to the right quality. Yeah, everything you're talking about so far, Jesse, sounds a lot like

102
00:09:34,600 --> 00:09:42,520
managing expectations, whether it's coming from high level leaders to the data analysts to the

103
00:09:42,520 --> 00:09:48,520
people writing the pipelines, there's always this, how do you manage expectations? So as you're

104
00:09:48,520 --> 00:09:55,240
thinking about that, what is your process? Even feel free to give us an example of what it looks

105
00:09:55,240 --> 00:10:02,200
like for you to manage those expectations, whether it's upfront, and you're trying to be proactive

106
00:10:02,200 --> 00:10:07,640
and doing that, or whether it's reactive, you get that request coming in, it feels like it's out in

107
00:10:07,640 --> 00:10:15,000
the left field, or they're throwing you a curveball. How do you manage expectations? I personally try

108
00:10:15,000 --> 00:10:20,520
to be proactive where I can. I think it can be difficult to manage expectations depending on the

109
00:10:20,520 --> 00:10:27,720
system that you're operating all these requests through. So previously, we just kind of had a

110
00:10:27,720 --> 00:10:32,440
request queue, and they were all coming in directly to my team if that was the right thing. And so I'm

111
00:10:32,440 --> 00:10:38,360
like managing, you know, a whole backlog of requests that come from all over the place. And plus,

112
00:10:38,360 --> 00:10:43,480
there's other projects coming in from our enterprise and from our department. And there wasn't a

113
00:10:43,480 --> 00:10:50,360
resource transparency on that. It was just kind of like on me to say, I can or cannot do this. One of

114
00:10:50,360 --> 00:10:56,200
the things our company has done recently is really implement a resource planning perspective through

115
00:10:56,200 --> 00:11:03,000
ServiceNow. And so now we're able to have a lot more transparency and to set these expectations and

116
00:11:03,000 --> 00:11:09,320
have really good dialogue about, you know, one, the business needs to be very clear about what they

117
00:11:09,320 --> 00:11:13,320
want, because there's times where they say, I want this, and I say, I can deliver it to you at this

118
00:11:13,320 --> 00:11:19,080
time, and then I deliver it, and they say, well, that's not quite it. So did I not deliver it, or

119
00:11:19,080 --> 00:11:23,560
were we not clear on what you wanted? So it's part of the business helping them figure out what they

120
00:11:23,560 --> 00:11:31,160
want. But then also us, you know, there's never a dull moment in analytics and IS. There's always work

121
00:11:31,160 --> 00:11:37,720
to do. There's always data coming in. So when there's a thousand things to do, what are the 100 that

122
00:11:37,720 --> 00:11:46,200
we can do? And so I think having this system where we have our IS leaders and business leaders

123
00:11:46,200 --> 00:11:51,400
involved in having those transparent conversations about, well, this is how much it's really going to

124
00:11:51,400 --> 00:11:57,560
take if you want us to do this. And then if you want us to do this other thing, the question is

125
00:11:57,560 --> 00:12:02,280
always, well, what are we going to have to not do in order to do this thing? So there's a little bit

126
00:12:02,280 --> 00:12:07,800
of a system in our organization that's helped us to really be more proactive in those conversations

127
00:12:07,800 --> 00:12:13,960
and to support outright saying, this is how much that's going to cost in time and resources. What

128
00:12:13,960 --> 00:12:17,880
do you want me to, what is the most important thing you want me to work on right now?

129
00:12:17,880 --> 00:12:24,600
Yeah. Do you have an example of what that looked like for you on your team and a particular project

130
00:12:24,600 --> 00:12:30,760
maybe where, you know, you had this priority and another one came in and you wrestled through that

131
00:12:30,760 --> 00:12:36,120
and what the conversations were like, you know, putting the meat on the bones in terms of, you

132
00:12:36,120 --> 00:12:41,000
know, it's great to have a proactive approach in how we do this, but what's it look like in the real

133
00:12:41,000 --> 00:12:46,600
world when you finally get that request coming in and it's causing you to pivot and you have to think

134
00:12:46,600 --> 00:12:53,400
through and actually follow that process? Luckily, sometimes the priorities are set for us. So, you

135
00:12:53,400 --> 00:12:59,480
know, when something comes up, sometimes it's, this is just the priority and that's what you pivot to

136
00:12:59,480 --> 00:13:04,760
and that can make it very clear. I think that comes from good leadership explaining what the priorities

137
00:13:04,760 --> 00:13:09,960
are. Whenever I'm confused, that's the question I ask and I get clear answers, which is important.

138
00:13:10,840 --> 00:13:16,360
I think another thing that I'm thinking of here is helping the business understand a cutoff point.

139
00:13:16,360 --> 00:13:22,680
So, one example is we had like a project where we were implementing this new care coordination

140
00:13:22,680 --> 00:13:29,080
platform and so we had a new source of data and we had to update some reports. Now, being very clear

141
00:13:29,080 --> 00:13:35,560
about what's in scope in that project were these specific reports, but also it's new data and there's

142
00:13:35,560 --> 00:13:40,760
new logic and so you're kind of always iterating and evolving and we could do that for the rest of

143
00:13:40,760 --> 00:13:45,640
the year. I mean, we could do this project for the entire year. I had to step in and kind of say,

144
00:13:45,640 --> 00:13:52,520
here's the stop line where we're doing a project. Yeah, exactly and it's my biggest priority and the

145
00:13:52,520 --> 00:13:57,960
rest of this is now going to become outside of the project and will be prioritized accordingly

146
00:13:57,960 --> 00:14:02,280
to all the other things that are going on. So, sometimes that's part of the conversation is

147
00:14:03,000 --> 00:14:07,320
right now you are under an enterprise project and so you are the most important thing, but there's

148
00:14:07,320 --> 00:14:11,160
a stop point where now you just need to be prioritized among everything else because we

149
00:14:11,160 --> 00:14:15,960
have tons of other projects going on and the business has been receptive to that conversation,

150
00:14:15,960 --> 00:14:23,640
which makes my job easier. How large is the organization? Like how many stakeholders or

151
00:14:23,640 --> 00:14:28,920
business units are you working with? It sounds like a larger organization with the amount of

152
00:14:28,920 --> 00:14:32,280
people coming through. So, tell me a little bit about the size of the number of stakeholders

153
00:14:32,280 --> 00:14:36,600
you're working with. I would say we're a medium-sized organization. I hope I get this

154
00:14:36,600 --> 00:14:42,600
number right, but I think our employees are about 1500 right now and then I would say,

155
00:14:43,400 --> 00:14:49,000
you know, we don't work with every department in the organization, but I would say probably 10 to

156
00:14:49,000 --> 00:14:55,560
15 different departments. Some of those having lots of requests and some of those maybe we only

157
00:14:55,560 --> 00:15:02,520
have one request from them. So, I would say our operations, claims, enrollment, these certain

158
00:15:02,520 --> 00:15:07,400
like domains there are some of our biggest customers. Honestly, actually our biggest

159
00:15:07,400 --> 00:15:14,440
customer is us, ourselves. We create a lot of work ourselves in IS and so, you know, right now we

160
00:15:14,440 --> 00:15:19,240
have a lot of migration work and tech debt that we're doing and updating things or new systems

161
00:15:19,240 --> 00:15:24,520
coming in and so again, I mean, my backlog, most of the work is coming from us, ourselves and the

162
00:15:24,520 --> 00:15:32,520
work that we need to do. Yeah, I mean 1500 employees though is a big enough organization where you are

163
00:15:32,520 --> 00:15:38,440
running into process challenges or data challenges that are more complex to solve than a couple

164
00:15:38,440 --> 00:15:45,320
hundred employees. Yes, and one comment on that, I would say another added complexity is just again

165
00:15:45,320 --> 00:15:51,400
the unique way of our organization and the regulatory environment and that if our state

166
00:15:51,400 --> 00:15:59,240
says they we need to implement a new benefit in 2025, we need to implement a new benefit in 2025

167
00:15:59,240 --> 00:16:03,800
and if Medicare says we need to start reporting in a certain way, we need to start reporting in a

168
00:16:03,800 --> 00:16:10,600
certain way and because these governing bodies are trying to improve and do better with health care

169
00:16:11,240 --> 00:16:16,680
every year there's something new that we have to do and so I always tell people who are new that

170
00:16:16,680 --> 00:16:21,000
what kind of feels like a startup, you know, there's no resting. There's always a new project, there's

171
00:16:21,000 --> 00:16:28,040
a new benefit, there's a new population, there's a new report. Now we are growing and so we have new

172
00:16:28,040 --> 00:16:34,440
systems and that and so that makes your data change. It makes the report you did three years

173
00:16:34,440 --> 00:16:39,480
ago you don't need to do because there's a new requirement to it this year. There's a new benefit

174
00:16:39,480 --> 00:16:44,200
so yeah, there's just lots of things that can kind of change the work in the direction that we focus on.

175
00:16:44,200 --> 00:16:48,280
Yeah and so you mentioned this earlier but that sounds like a challenge from a data governance

176
00:16:48,280 --> 00:16:54,920
perspective of keeping track of shifting products and shifting data sources as well as like the PII

177
00:16:54,920 --> 00:16:59,880
side of things and the sensitive data. So tell me about you said data governance initiative,

178
00:16:59,880 --> 00:17:04,840
what kind of work or and where did that come out of? What was the need and and what kind of work

179
00:17:04,840 --> 00:17:11,480
are you doing now around data governance to make that effective? We do have a team, our analytics

180
00:17:11,480 --> 00:17:17,880
program services that's focused on data governance. It has really kind of all grown in-house, you know,

181
00:17:17,880 --> 00:17:25,800
as your data literacy scales, your data available scales, your governance has to scale so you can't

182
00:17:25,800 --> 00:17:32,520
have a really structured whole team program when you only have a few analysts. So it starts very

183
00:17:32,520 --> 00:17:37,560
small and then we just had to build it out. Now we actually have a team and some more formal parts

184
00:17:37,560 --> 00:17:45,240
of it. So I would say the aspects of our data governance are we have training and trainers that

185
00:17:45,240 --> 00:17:51,320
actually support some of the like on-demand trainings or rolling out to our forums. Our forums

186
00:17:51,320 --> 00:17:57,080
being we have like a analytics skills community where just our analysts come to. We have a

187
00:17:57,080 --> 00:18:03,640
community of practice where analysts and maybe their leaders might come to. We have a weekly

188
00:18:03,640 --> 00:18:08,520
email that goes out to the whole organization and now we have a little analytics corner there for

189
00:18:08,520 --> 00:18:14,680
updates. We have team chats that people can go to to kind of ask those questions like what's going

190
00:18:14,680 --> 00:18:19,640
on with this data source? Is there an issue? So lots of change management of like disseminating

191
00:18:19,640 --> 00:18:24,920
information out to everybody to know the tools to go to, to know where to go to get the information.

192
00:18:24,920 --> 00:18:30,600
We have a reporting and analytics like SharePoint page, landing page with lots of references there.

193
00:18:30,600 --> 00:18:36,360
So what's your question about this data? What do I do if I if I have a concern about it? What's some

194
00:18:36,360 --> 00:18:42,040
more resources and learning on it? People can go there. Then we have like formal policies and

195
00:18:42,040 --> 00:18:47,240
things like that that are you know cataloged and registered in certain places. So I think a lot of

196
00:18:47,240 --> 00:18:53,480
it has just been the touch points to our analytics community of teaching them the technical terms,

197
00:18:53,480 --> 00:18:59,400
how to think about data, data literacy. We do an annual survey to kind of get a pulse on this as

198
00:18:59,400 --> 00:19:07,720
well and measure against ourselves. So it's pretty cool I think. And really broad too like you just

199
00:19:07,720 --> 00:19:13,800
highlighted the well probably the reason a lot of data governance initiatives fail is because they

200
00:19:13,800 --> 00:19:19,400
involve so many different parts of the people and the process as well as some technology elements

201
00:19:19,400 --> 00:19:25,080
to be successful. Like how do we think about data holistically and stewarding it well and training

202
00:19:25,080 --> 00:19:31,640
people to use it well and think about it well. And the scaling too. So we have a data catalog that we

203
00:19:31,640 --> 00:19:39,320
have implemented and we want people using it but we also need people using it to add the information

204
00:19:39,320 --> 00:19:45,560
to make it usable. But how do you get people to you know so it's like this catch-22. And so we've

205
00:19:46,120 --> 00:19:51,240
we're focused on like our glossary terms but we recently got feedback that people are like well

206
00:19:51,240 --> 00:19:56,440
we really want to know dictionary data dictionary definitions for the tables and that isn't something

207
00:19:56,440 --> 00:20:01,960
we've been focused on. So we're at this point where like if we do not enhance this other aspect of the

208
00:20:01,960 --> 00:20:07,080
data catalog we've kind of hit our limit on people wanting to use it. But now we need to get the

209
00:20:07,080 --> 00:20:12,360
resources to get people to put that information in there. So you have issues like that where you

210
00:20:12,360 --> 00:20:18,840
need to balance scaling it. Earlier you mentioned tech debt and like a lot of migrations or

211
00:20:18,840 --> 00:20:22,600
initiatives happening and actually before the call you mentioned briefly you're doing a cloud

212
00:20:22,600 --> 00:20:28,600
migration. So I'd love to hear about some of the challenges you face and even maybe why that seemed

213
00:20:28,600 --> 00:20:33,800
like a priority to do now. A lot of companies just stayed on on prem for a long time. What was

214
00:20:33,800 --> 00:20:37,800
was there a decision point that led to that and then what's that journey been like so far?

215
00:20:37,800 --> 00:20:43,720
I wasn't part of the conversations to make the decision but from what I've gathered it came to

216
00:20:43,720 --> 00:20:49,160
storage and cost. You know we just we've been around for 30 years. We have a lot of historical

217
00:20:49,160 --> 00:20:53,480
data. We have data that comes from so many different places. We just have a lot of it.

218
00:20:54,280 --> 00:20:59,800
And so it costs you know we start hitting performance issues and cost issues for being on

219
00:20:59,800 --> 00:21:05,480
prem and so to see the trajectory and growth of our company it just made sense that it was time

220
00:21:05,480 --> 00:21:10,680
to go to the cloud. And then what's the other question kind of? Oh yeah what's the journey

221
00:21:10,680 --> 00:21:16,200
been like and yeah what kind of roadblocks have you hit or there's a big sigh for everybody now.

222
00:21:16,200 --> 00:21:23,240
Yes. Why you gotta bring up roadblocks Sawyer? Come on. Sorry, sorry. I'm sure it's been smooth sailing.

223
00:21:23,880 --> 00:21:33,400
Basically I would summarize like it's just not as easy and as straightforward as you're going to

224
00:21:33,400 --> 00:21:39,800
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

225
00:21:39,800 --> 00:21:48,200
E right now. Like I we were given I think one good thing is to set a like a cutoff date. Here's the

226
00:21:48,200 --> 00:21:54,440
date we want you to be off this on-prem database and to be on the cloud database. We are had an

227
00:21:54,440 --> 00:21:59,880
initial date and had to move it six months out and I think we're close to meeting that but it might

228
00:21:59,880 --> 00:22:05,320
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

229
00:22:05,320 --> 00:22:09,720
one of those leaders in there just know you're not going to make that date and you're not going to be

230
00:22:09,720 --> 00:22:15,400
on plan A because there's just a lot of things that come up that are unanticipated. I think one

231
00:22:15,400 --> 00:22:20,680
thing from my perspective too is there are teams that are really focused on just that data warehouse

232
00:22:20,680 --> 00:22:26,680
migration but I'm the business intelligence team that has all the downstream impacts that okay now

233
00:22:26,680 --> 00:22:32,920
my report that I use my reporting tool that I use isn't compatible. Now we have and then you have

234
00:22:32,920 --> 00:22:37,800
your kind of workaround plans where it's like this isn't ideal now we're going to do this well now

235
00:22:37,800 --> 00:22:42,600
there's a security risk so now we have to think about that then that's creating tech debt of things

236
00:22:42,600 --> 00:22:48,040
we'll have to clean up next year and okay so if we're going to use this tool you know now we're

237
00:22:48,040 --> 00:22:54,120
looking at a new tool we're going to go from SSRS to Power BI. What's the compatibility there? Do we

238
00:22:54,120 --> 00:23:00,760
need another tool to do something there? So there's just been lots of like learning growth discovering

239
00:23:00,760 --> 00:23:05,800
and then teams looking at it from different perspectives and again like I said in order to

240
00:23:05,800 --> 00:23:10,840
meet a date you know there's sometimes kind of like well this is the path we need to take right

241
00:23:10,840 --> 00:23:16,600
now to get there it might not be ideal but it's the path we need to get there for right now.

242
00:23:16,600 --> 00:23:22,440
And with a lot of migration efforts you have an opportunity to look at tech debt as it currently

243
00:23:22,440 --> 00:23:27,880
exists within your architecture and think okay are we going to do a true lift and shift and just

244
00:23:27,880 --> 00:23:33,400
plop our tech debt over here in a new environment or are we going to redesign a little bit are we

245
00:23:33,400 --> 00:23:39,880
going to find opportunity to enhance? Well those are now going to be in conflict with each other

246
00:23:39,880 --> 00:23:46,600
because you've got to migrate by a certain date but you've got all this vision for how much better

247
00:23:46,600 --> 00:23:51,880
it'll be when it's finally over there but it requires the time to do that. So how do you

248
00:23:51,880 --> 00:23:59,080
determine between what points are true lift and shift? We're just going to take this and plop it

249
00:23:59,080 --> 00:24:03,800
over here and then here's the things that are non-negotiable we need to rewrite if we're going

250
00:24:03,800 --> 00:24:08,920
to go through this effort to go from on-prem to the cloud. What does that look like from your

251
00:24:08,920 --> 00:24:15,160
perspective in the BI knowing that some of that is more you just handling the consequences of the

252
00:24:15,160 --> 00:24:20,600
migration not even necessarily involved in the migration. How do you argue for please change

253
00:24:20,600 --> 00:24:25,480
that if you're going to do this change that for me so by the time I'm connecting in my BI tool

254
00:24:25,480 --> 00:24:30,840
it's better than what it was before. So anything on that front, Jessie? Yeah I think that's a good

255
00:24:30,840 --> 00:24:36,600
point and I think that is definitely part of the journey as you start with this ideal vision of how

256
00:24:36,600 --> 00:24:42,840
it's going to be and then reality hits and you realize maybe that takes way too long to do and

257
00:24:42,840 --> 00:24:49,880
so you do have to start pivoting to lift and shift. I think there's not a clear answer unfortunately

258
00:24:49,880 --> 00:24:56,040
it's kind of case by case and the key is collaboration. So there's an example now

259
00:24:56,040 --> 00:25:02,760
that we're doing where we meet with our EDW team on a weekly basis because we do have these certain

260
00:25:02,760 --> 00:25:10,600
cases where does it make sense to lift and shift or rebuild or what are the options you know and

261
00:25:10,600 --> 00:25:15,240
it's like we have 20 different cases and the answer is going to be different for each scenario

262
00:25:15,240 --> 00:25:21,480
and so it's a matter of going through each scenario with all the right people involved our team the

263
00:25:21,480 --> 00:25:27,000
BI team as well as the EDW team and going what makes sense here what's the purpose of this report

264
00:25:27,000 --> 00:25:33,640
what's the long-term thing what makes sense here do we have tables that we could use instead that

265
00:25:33,640 --> 00:25:40,200
might help this that we can repoint to a different data source sometimes I'm even having to log things

266
00:25:40,200 --> 00:25:46,600
like this is what we're going to do in the short term but we have stuff to clean up in 2025 so

267
00:25:46,600 --> 00:25:53,640
make sure we log all of that and try to start that next year. So it's definitely not always clear

268
00:25:54,200 --> 00:26:00,680
and I think again key is just having good collaboration with other teams. One other

269
00:26:00,680 --> 00:26:05,960
thing we did is we have lots of databases but we're focused on migrating one specific database. Our

270
00:26:05,960 --> 00:26:11,880
vision is that everyone would go to EDW database and so that's really the only one we're focused

271
00:26:11,880 --> 00:26:16,200
on migrating which gives us a chance to kind of work on how do we want to clean up some of the

272
00:26:16,200 --> 00:26:21,800
other ones and again to the it's case by case on is this worth migrating or is this something that

273
00:26:21,800 --> 00:26:28,360
is not used and so we don't migrate it over. I think we do the best I think there's definitely

274
00:26:28,360 --> 00:26:33,400
gray areas where you're migrating things that don't need to be migrated duplication happens at

275
00:26:33,400 --> 00:26:40,760
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

276
00:26:40,760 --> 00:26:46,760
usable we don't move it over there. One thing one more note on that is having a date of not putting

277
00:26:46,760 --> 00:26:53,160
anything else on prem so we had a cutoff date now with all this new data it does not go on prem

278
00:26:53,160 --> 00:26:59,080
anymore so now it has to be on our cloud on Snowflake so that also helps that way you're not

279
00:26:59,080 --> 00:27:06,360
continuing to build things on prem during a migration. I love the because the story that

280
00:27:06,360 --> 00:27:12,280
comes from the salespeople at Microsoft or AWS or Snowflake or wherever is about how clean and

281
00:27:12,280 --> 00:27:16,920
smooth and I've been in those meetings before about how easy a cloud migration can be with

282
00:27:16,920 --> 00:27:20,520
lots of tools and you know easy assistance or consulting firm will come in and tell you how

283
00:27:20,520 --> 00:27:26,280
smooth it is so I'm so glad we've got some reality here because there are lots of bumps

284
00:27:26,280 --> 00:27:31,320
and challenges and trade-offs and varying degrees of payoff for different situations.

285
00:27:31,320 --> 00:27:35,720
Trade-off is a great word because that's definitely part of the conversation. I mean

286
00:27:36,600 --> 00:27:42,040
someone might think well if it's going to get so messy why have the date to migrate just push it

287
00:27:42,040 --> 00:27:46,680
off but you need to have a date you need to have a timeline and a goal to get there or you could

288
00:27:46,680 --> 00:27:53,000
push that timeline off forever so it is a trade-off for sure on how to get there.

289
00:27:53,000 --> 00:28:00,040
Yeah how have you handled upskilling or changing the skill set of your team to adapt to different

290
00:28:00,040 --> 00:28:05,880
cloud tools or different tooling you mentioned maybe a shift to Power BI or Snowflake so tell

291
00:28:05,880 --> 00:28:11,320
me about the upskilling that you've had to approach and deal with. I think it helps to have a team that

292
00:28:11,320 --> 00:28:18,280
loves learning and loves technology and loves upskilling so that's good because they're

293
00:28:18,280 --> 00:28:24,280
genuinely interested. I think we usually try to take a few members of the team that's kind of a

294
00:28:24,280 --> 00:28:29,960
pilot crew that can really give all their time onto learning those new tools. We work with the

295
00:28:29,960 --> 00:28:35,400
analytics program side and the trainers to document those best practices develop some of those

296
00:28:35,400 --> 00:28:42,680
trainings and work together there and then from there start to share that out with the rest of

297
00:28:42,680 --> 00:28:47,240
our team and then from there start to share that out with the whole analytics community.

298
00:28:47,240 --> 00:28:53,560
That's cool just identifying those who are naturally curious and their inventors and saying

299
00:28:54,200 --> 00:29:00,360
I want to task you with the lion's share of trying to figure this out stitch it together

300
00:29:00,360 --> 00:29:04,760
and then you can promulgate that out through the rest of the organization that's cool.

301
00:29:04,760 --> 00:29:10,920
Yes and then it kind of come back to collaboration again my team despite being in a remote environment

302
00:29:10,920 --> 00:29:17,080
is wonderful at being collaborative as well and so I think another thing they've done is they have

303
00:29:17,080 --> 00:29:22,680
a weekly water cooler is what they call it where they all just meet because they're remote and it

304
00:29:22,680 --> 00:29:27,160
becomes a sharing session so the three people that were starting to rewrite all their code into

305
00:29:27,160 --> 00:29:32,920
Snowflake start to share out there or at team meetings or in certain forums so that the whole

306
00:29:32,920 --> 00:29:37,720
team can now see what they're doing and start to learn how to rewrite in Snowflake and then when

307
00:29:37,720 --> 00:29:42,680
we assign things for some of the newer members we partner them with the people who've already done

308
00:29:42,680 --> 00:29:47,160
it and so there's a lot of mentorship and collaboration of okay these two folks have done a

309
00:29:47,160 --> 00:29:51,800
lot of it now that we're getting three other folks into it you two need to meet together to kind of

310
00:29:51,800 --> 00:29:56,280
work through those problems of rewriting it in Snowflake sequel. The theme of this episode has

311
00:29:56,280 --> 00:30:00,920
just been collaboration because I've been hearing like from the beginning of what it's like to

312
00:30:01,640 --> 00:30:05,560
deal with all these different voices and prioritization and then collaboration on

313
00:30:05,560 --> 00:30:11,960
tech migrations and then collaboration on upscaling. Yes so that's that's I love that theme and that

314
00:30:11,960 --> 00:30:19,240
thread going through this. Jesse tell us a bit more about your background and how you landed in

315
00:30:19,240 --> 00:30:24,600
data work and maybe why you landed at CARE Oregon and what that what your journey has been like to

316
00:30:24,600 --> 00:30:31,960
get to where you're at and why you're still here. Sure I think I kind of accidentally luckily ended

317
00:30:31,960 --> 00:30:37,320
up here I was not so a lot of my team are like people who studied computer science and computer

318
00:30:37,320 --> 00:30:45,640
engineering I'm a psychology major so I um I worked in social services for many years so I've worked

319
00:30:45,640 --> 00:30:52,040
in non-profit for a while and I worked with children and families and just kind of saw that I didn't

320
00:30:53,160 --> 00:30:59,400
see the whole career trajectory going where I wanted it to be there. Also with psychology a lot

321
00:30:59,400 --> 00:31:04,120
of times when you're moving up in a psychology degree you're doing counseling and I did not want

322
00:31:04,120 --> 00:31:10,840
to do clinical work or counseling I was very sure about that so I ended up going back to school for

323
00:31:10,840 --> 00:31:16,840
a master's in psychology but it was a research degree not clinical and so I learned a lot about

324
00:31:16,840 --> 00:31:23,400
research methods quantitative statistics and that's kind of where I found the science math portion

325
00:31:23,400 --> 00:31:30,520
but on people I love when my data is people and so then after that I got I got a job as a program

326
00:31:30,520 --> 00:31:36,280
evaluator and I started getting interested in being an analyst from the statistics work that I did.

327
00:31:37,160 --> 00:31:47,320
So then I moved from Florida to Oregon and I just luckily got my job at Care Oregon and found it to

328
00:31:47,320 --> 00:31:54,680
be such a wonderful fit in the healthcare space because again we get the funding to scale and

329
00:31:54,680 --> 00:32:00,440
invest in our analytics because we're healthcare but the data is people which is something I can

330
00:32:00,440 --> 00:32:06,200
care about and uniquely in Oregon it can be a mission-centered organization a non-profit

331
00:32:06,200 --> 00:32:10,520
whereas in another state if I was working for a healthcare organization it would probably be

332
00:32:10,520 --> 00:32:15,800
a for-profit healthcare organization with a Medicaid line of business to it so it's really

333
00:32:15,800 --> 00:32:22,120
special here in Oregon and so then we have a great culture at Care Oregon they really support the

334
00:32:22,120 --> 00:32:30,120
growth and support of our staff so I was a data specialist for a while then I became a data analyst

335
00:32:30,120 --> 00:32:35,400
then I became the BI supervisor and now I'm a BI manager so I've really grown in my analytics

336
00:32:35,400 --> 00:32:41,880
career at Care Oregon. Yeah I love the merging of not just data and maybe research but people

337
00:32:41,880 --> 00:32:48,520
specifically and then how that's found a nice overlapping Venn diagram at Care Oregon that's

338
00:32:48,520 --> 00:32:54,200
great and Jesse as you look forward to the next call it six to twelve months what are you most

339
00:32:54,200 --> 00:33:01,080
excited about in your work with data or in what's happening at Care Oregon? So like next year?

340
00:33:01,080 --> 00:33:05,560
Yeah yeah we'll call it 2025 what are you looking forward to what's exciting for you on the horizon?

341
00:33:05,560 --> 00:33:12,280
I haven't thought about next year very much because our migration deadline is the end of this year so

342
00:33:12,280 --> 00:33:21,720
I'm still very focused on this. I think what I'm a little excited about is some more kind of clean

343
00:33:21,720 --> 00:33:29,400
up and improvement projects. We do have a couple other databases that you know again we we've been

344
00:33:29,400 --> 00:33:34,600
around for a while our analytics teams have changed we have a database that was historically created

345
00:33:34,600 --> 00:33:42,200
by a team 20-15 years ago that now we've inherited and it just needs to be updated. We don't need to

346
00:33:42,200 --> 00:33:47,240
point to certain sources it's hard to manage because it's reporting to these more source

347
00:33:47,240 --> 00:33:55,960
system databases rather than analysis tables so I've put in some requests for that project next

348
00:33:55,960 --> 00:34:00,840
year and to get the resourcing for that so I think that will be something I look forward to

349
00:34:00,840 --> 00:34:06,120
because it's also a project I want to do and it's not going to be you know some of the projects

350
00:34:06,120 --> 00:34:11,880
leaders are choosing for us to do as they should but this is one that I'll personally feel invested

351
00:34:11,880 --> 00:34:18,120
in having my team work through and complete. Well I've got a completely different question for you

352
00:34:18,120 --> 00:34:23,560
I want to see if you know why did the data engineer order a thousand balloons?

353
00:34:25,160 --> 00:34:29,880
I don't know. Because he thought that was the best way to get the data in the cloud.

354
00:34:31,000 --> 00:34:35,320
Ordering a thousand balloons? This is like this is like up now the movie up yeah.

355
00:34:35,320 --> 00:34:45,640
Oh the cloud that would make it easier cloud migration than some of the project plans I've

356
00:34:45,640 --> 00:34:49,240
seen. I mean we were talking about cloud migrations I had to sneak it in somewhere.

357
00:34:52,600 --> 00:34:58,520
Jesse this has been wonderful I love the practical nature of this conversation and

358
00:34:59,240 --> 00:35:03,480
yeah and how your work at CareOrgan has just meshed the people and the collaborative side

359
00:35:03,480 --> 00:35:08,760
of things with some more technical work. If people are interested in reaching out to you online or

360
00:35:08,760 --> 00:35:13,880
find out more of CareOrgan where where's a good place to look for you? I would say my LinkedIn

361
00:35:13,880 --> 00:35:18,200
is probably the best. Excellent well thanks so much for joining us today. Thanks for being here Jesse.

362
00:35:19,240 --> 00:35:23,400
Yeah thank you Jesse and listeners thanks for joining us on this episode of Making Data Matter.

363
00:35:23,400 --> 00:35:34,120
We'll see you next time. Thank you.