Welcome to Making Data Matter, where we have practical conversations about data and leadership
at mission-driven organizations with practical insights into the intersection of nonprofits,
mission strategy, data. And I'm your host Sawyer Nyquist.
And I'm your co-host Troy Dueck.
And today we're joined by guests.
Us.
Us, yeah, nobody.
So this is a Sawyer and Troy solo episode, solo duo episode, no guests today.
But the guest is the experiences that we're doing. So Sawyer, you got started doing another cohort
for data leaders three weeks ago. And I finished up the dataengineer.io boot camp that Zach Wilson
puts on. And I finished that a couple months ago. So we got some great topics that we're going to
cover to sort of compare and contrast those experiences and talk about just that intersection
with our work with nonprofits and mission-driven orgs. So just you're in the thick of your
cohort right now. Tell me how it's been going. Just high level. What do you do there?
Maybe, you know, conceptually or categorically, who's in the group this time? Tell me a little
bit about that. Yeah. So it's called the technical and strategic data leader. And that's probably a
mouthful, but we call it the TSDL cohort. And it's a group of people who are in leadership roles
over data teams. So we've got, there's seven people in the cohort and there's three mentors
who are kind of leading the cohort. And so there's a head of data, there's a director of data,
BI supervisors, VP of business intelligence. Those types of roles and titles are the people
who are in the cohort. And the goal is to think about the bridging the gap between the strategic
side of being in a leadership function in data and the technical side of being over data, which is
fundamentally also a technical discipline. And how do we get data leaders and how do we equip
data leaders to do a good job of both of those skillsets of business, strategic thinking,
as well as technical and architectural thinking as they lead their team. So all of these people
in the cohort are leaders of a team or leaders of teams of people, leaders of leaders of teams of
people. And we really, it's really a really diverse group, which is fun. We've got people,
we span nine time zones in our group. We've got people from Europe all the way to Pacific coast
of the US. People at small organizations of a couple hundred people, people at a fortune 50
organization. So just massive in terms of like team sizes and organizational complexities in
politics. And then people, a couple of specific people in the cohort are in government and then
in like nonprofit healthcare and Medicare related services. And so it spans both the for-profit
world as well as the nonprofit world. So I don't know, that's a little bit about like how the
cohort is and who's in it. And it's a different sort of learning experience than we've seen
anywhere else, which is why we thought about, which is why me and the other mentors got together to
put this together, because there's a combination of both content of delivering and talking through
what's happening with data architectures and technologies and strategy, as well as lots of
conversations and community building that we try to invest in. So because it's a small group
and there's only 10 of us, we've got a really kind of intimate conversation space and dialogue
space. People feel safe to really share and engage with their challenges that they're facing.
And then there's also some like core content that they're getting in a synchronous format as well.
So there's what the cohort looks like at a high level. And I'm interested now, like let's flip
this around because we're going to talk about how you learn with data and how you grow your data
career in a couple of different ways. So the cohort is kind of like one model we've talked
about. I'm curious about, and we can go more to that later. Troy, tell me a bit about your experience
with a data engineering bootcamp, because that was quite a bit different than what I was just describing.
Yeah, definitely parallels. You're talking about big organizations represented in the people that
are the students in the cohort. Some are data leaders, but it was more geared towards practitioners.
And so it's those who really want to take their data game, technically speaking, to the next level.
And so this was the fourth version of the bootcamp that Zach Wilson has put together. And,
you know, for those of you who don't know, he has worked at Facebook, at Netflix, and has dealt with
big data. You know, we're talking about maybe hundreds of terabytes of data that were being
moved over an hour or two. So I can't think of a better definition for big data than some of the
stuff that he was dealing with. And so it got very technical. You're coding. So you've got VS code
open. You're doing stuff with SQL. You're using DBT, learning Kafka, Flink, Apache Spark. I mean,
just really nerdy kind of stuff. And so... Yeah, we should have had a nerd warning at the beginning
of this episode, because it sounds like we're going to be stepping our toe into the nerdy waters.
Well, we might. We might. I'm just naming them off. And I want to get at, okay, so what does
that matter for someone who's dealing with smaller data sets? You know, I'm thinking about my own
experience and some of the biggest data sets I'm dealing with is only a few hundred million rows.
And so, you know, that's not big data yet. That's still, by and large, manageable with certain
small practices that you can do with data. It's not 200 terabytes in an hour or something like
that. So a very different world. Now, a little bit about this group of students is there was
a hundred and forty or so that had originally signed up for this bootcamp. Now, I think it
kind of whittled down to a core group of 70 or 80 that were regularly active. And even that group
of students was split between those who were really thinking of a career move. They either
wanted to really break into data engineering. Maybe they were a data analyst or a BI person.
Maybe they were even a program manager and they just wanted to get into data from more technical
perspective. And so they were really making a huge career move into going further upstream and doing
the real data engineering, setting some pipelines. You've got your DAGs to, you know, in airflow to
orchestrate your jobs. And so it was all the nuts and bolts they hadn't played with in their former
experience. That was one group of students. Then you had a second group of students that were the
current data engineers who wanted to fill in their knowledge gaps. They wanted to learn some
new SQL patterns. They wanted to just sort of see end-to-end solutions and think at a higher level
of how can I do data engineering with best practices and industry standards, not just the
duct tape and bailing wire ways that I've put things together over time. And so I think the
group that was doing the career moves were maybe a little more invested in the community. And so
that was one of the things that they really promoted throughout the course was here's a
platform that you can use to share ideas with one another, troubleshoot your code together,
work in groups and pairs and learn that way. There was also the utilization of LLM auto grading in
the assignments that we would submit. And so using GitHub classroom, we would submit our code and
then we'd get the automated grading feedback from the LLM that they had instituted. So really neat to
see a real live use case of some cool tech on my homework. At the same time, it didn't give you as
much of a personalized grading experience. So it's a little bit more the bigger, not as much of a
cohort experience that I think you're talking about where you get to know these people, you get
to have a relationship with these people and talk about very specific use cases that they're facing
in the business. So that's just some of the, I guess, I don't know, culture or experience that
might've been similar and different to what you're talking about in the cohort. So I don't know,
what questions do you have about parallels between that cohort and the bootcamp?
Yeah. Well, I think it's interesting. So for listeners here, we're not really promoting
either of these things. We're really just talking about different ways that Troy and I have
experienced this summer for learning and growing and expanding our skill sets as data people.
And so one, Troy's bootcamp experience, mine's a cohort leadership experience. And so these are
two different ways that we spent our summers with data. The thing that I'm curious about is really
the learning experience. And maybe for you, Troy, as a learner, you've also worked in education in
the past too. So I'm curious to poke at like, and you've also taught classes online. I'm curious
about from a learning perspective, what are the things about that cohort? You had a lot of homework,
you had some live instruction, you had pair programming options, talk about which parts of
learning experience best equipped you to gain new skills. You got exposed to a lot of new technologies
too in this. So you were learning lots of new stuff. What learning experiences were most
influential for you? That's a great question. I'll camp on two particular nuggets that I took away
from the bootcamp. And the first was just filling in gaps on my SQL knowledge. And so seeing patterns
that were repeatable was helpful for me. One of those was the cumulative table design. I'm already
familiar with slowly changing dimensions, the type two, which is the kind of the gold standard,
I guess, of those slowly changing dimensions. And yet the cumulative table design was how can you
not do truncate this entire table and reload from the database every single night on a schedule?
How can you incrementally load this table? And what's the SQL pattern that'll enable you to get
there? And you can use that on almost any data set. And so it's a pattern that you can continue
to iterate on. And you don't have to get highly technical using some kind of change data capture
function that the database has available to you or delta files to try to find all the change logs
and do it that way. It was a much simpler way within SQL to still get at the same idea of
incrementally loading this table rather than truncating the entire thing and loading it nightly
kind of thing. And so that was a really helpful pattern to see. Sorry, you're going to ask a
question. That's part of the content that you received in. Were there lectures about that?
Or was that also part of your hands-on homework, was building some cumulative?
Right. It was both. And so most of the lectures were, there was option for live,
and Zach Wilson would usually do an hour lecture with an hour lab. And so it was usually a two-hour,
and it was almost nightly. I think it was four nights a week were basically mandatory for you
to be involved. So it was about eight to 10 hours that you were watching or attending live. And then
there was another eight to 10 hours that you would be investing in homework. So it is a boot camp. I
mean, you are really spending 20 plus hours a week, depending on your skill level, working on this
stuff. And so you'd watch Zach go through some of his examples, and then he would give you similar
examples with some data sets that he made available through his learning platform. And so they're using
a Trino database, and there's a web UI that you can go to to write your queries right there,
test them against the actual data sets. So you're actually coding in this thing. You're actually
running that query, getting the results set back, looking at, did I do it right? And then you submit
your code. Again, you can do it in VS code, submit it through GitHub, and then the autograder would
come back at you. So that one particular pattern was a lecture that just really stuck with me, is
looking at that SQL pattern to be able to continue to use that. I've already utilized it three or
four times in my work day-to-day experience. So that was a really great nugget of learning.
The other learning that I enjoyed was the optional learning, which was interviews that Zach would
have with other practitioners. There was even something he had done a few years ago that he
makes available in his learning platform, where he interviewed Bill Inman. And that was just a
really neat conversation to hear Zach asking one of the fathers of data warehouses, Zach,
data warehousing, how data has changed over the decades and what does the horizon look like.
And so similar types of interviews he tried to have throughout the course, somewhere past that
you could go and look at recorded, or he had some live ones where you could participate asking
questions of these other data leaders and practitioners that are out there, well-known
personalities. So that was part of that learning experience. And so whether it was the more
technical learning the nuggets over here or getting those interviews of what's happening
in the landscape, lots of exposure to technologies. And here's the one takeaway that was good for me,
but it was maybe both a, it was a bittersweet thing that I realized. And it's a lot of these
tools are intended for big tech. And so unless you're going to be doing some really crazy
things with digital analytics, low latency data, these large data sets that are coming
from streaming data of some kind, you probably aren't going to use these tools. You're not going
to have to dig into Flink and Kafka and even Apache Spark as powerful as it is, might be
overkill for the small job you're trying to accomplish. And so it was helpful for me as
someone who's not worked in large data sets, but I've got over a decade of experience working with
data to recognize that just because it's cool, new, shiny, really powerful, doesn't mean that
it's the right tool for the job. And so that was a good, again, bittersweet thing. Like I love
learning new tech. I love learning new skills and recognizing that. So the use cases, I think,
at nonprofit for some of these really cool, new, shiny tools is that they're intended for big tech.
And so unless you're going to be utilizing large data sets, you're going to be doing low latency
data, or you're going to be trying to mash up tons and tons of data, the tool's just too big,
too powerful for what you're trying to do. And the amount of time invested learning and growing in
that may not actually reap a benefit for the organization that you work with. And so it was
just a bittersweet realization that I came to, where it's like, oh, man, as much as I'd love to
keep growing in some of these tools, I don't currently have that use case. And this is after
having a decade of experience working for three relatively large nonprofit organizations and
recognizing that's just not where they're at from a data maturity perspective. There's other things
that they need to solve today. And the SQL patterns became more important and relevant for
that work today. These other tools, they may have that use case down the road as data maturity grows
and gets better at these organizations.
Yeah, that's a really interesting call out to think about the buzz and the hype cycle that happens
around these, or like the big sexy tools that the big tech uses, or that you see that it's
got, or that Facebook or wherever, or those tools were oftentimes built at those places, and now
they become commonplace. But the hype cycle doesn't apply well across all industries or across all
sides of organizations. And we see this with LLMs as well, like it's super exciting, like let's go
build your custom LLM model. And that doesn't work or really make sense or is practical for the vast
majority of organizations out there. And so I guess you got exposed to a lot of new tools that
were probably really interesting and fun to learn about. Tell me what were like, practically though,
how would you look to apply those frameworks? Is this just like good to know those tools exist
and what's out there? Are there any some takeaways for even like understanding the open source tools,
Spark, Flink, Kafka, et cetera?
Yeah, that's a great question. I think exposure is always a great thing to just know what tools are
out there that you could put in your tool belt and have at your fingertips when needed. And so
it's, to think of these things as either ors is always pretty dangerous. You end up getting siloed
and that can have its own detriment. At the same time, and it's going to sound like I'm talking
out of both sides of my mouth, there's so many of them. So how do you stay abreast of everything
that's going on and know how to use that tool in that particular use case in a way that's
it's a challenge. And so I think you have to find that sweet spot of I've got enough exposure
to know what's out there, to know when I should look deeper into this and need to use it. But
for the current day to day, more helpful is maybe just the end to end of thinking through processing.
Medallion architecture, I think, has got a lot of hype around it. And it also can be a bit confusing,
like, well, what do you put the bronze layer? What do you put in silver? What do you put in gold? And
everybody might do something a little bit different there. And so to see a more technical end to end
and not the categorical end to end was helpful. Oh, you first need to go to the source. You need to
set up a pipeline. You need to know how you're going to orchestrate that. And you're going to
need to think through the priority of your jobs. Well, I haven't even hit bronze yet. I'm just
thinking about the nuts and bolts of getting that data extracted before I do something with it.
And so just being able to break down those pieces further into the technical, what's happening here,
here, here, and here with the different tools was helpful to just think from a maybe architectural
standpoint that's a little more detailed than the, well, that's bronze, that's silver, that's gold.
That didn't tell me very much. I got to learn a lot more of that in seeing it with different tools.
And open source lets you play. Open source lets you dabble without getting into having to
raise the cost unnecessarily just to learn something new.
Yeah. Yeah. So like the patterns or like the more the framework and the wiring of how it all fits
together is going to be useful even when you swap out different tools, because you're still
thinking through the same sorts of problems about data ingestion. We're getting out of
these source systems. We're landing it into a new place. Like what are the different configurations,
requirements, and patterns that we want on ingestion? Same thing as you move through the
different maybe layers of an architecture. And that looks the same whether you're using
an open source project or whether you're using like a SaaS tool that's like plug and play or
GUI drop interface. And you can configure, you still want to think through the same patterns
and the same considerations come into play. Some of that gets easier when you don't have
to configure it all manually in code. But I think that sounds like probably the thinking
through the problems or understanding how it's wired together at a really like root code level
helps you a lot more when you are working at a more abstract level or more user friendly tool set level.
Yeah. Yeah. Now I want to ask you about your cohort. And I'm curious to hear,
is I'm thinking from a practitioner standpoint, I need to know how to, you know, do this technical
thing over here. But what are the problems that nonprofit data leaders or mission driven org data
leaders are trying to solve? And so I'm curious as you're in this leadership cohort, what are the
kinds of problems that you hear are coming to the surface that even as you're looking at all the
different businesses represented, the different levels within the organization, what commonalities
are there when you're hearing about problems that they're trying to solve from a data perspective?
Yeah, I like that. Because this is one thing you said earlier, when you talked about one of the
helpful things for you is pattern recognition or getting reusable patterns. And that was fitting
with something I was thinking about when I was reflecting on the cohort is one of the useful
pieces of gathering in a room with other leaders is patterns and hearing and getting like,
honestly, like empathy of like, I see that too, or I deal with that too. And you start to see
patterns, you start to see similar frameworks, and you're just getting validation for like,
oh, this is how it looks over here. That maps to my experience over here. Being in a leadership role
over a team, usually there's not a lot of data leaders at a company, maybe there's one person
who's responsible for business intelligence, maybe one person is responsible for like data
engineering, maybe not even multiple people, maybe it's just one person. Anyways, there's not a lot
of peers you have internally at a company. And so the space to get into a room with other data
leaders who have similar experiences to you, and to share patterns and to see commonalities is one
of the more powerful parts of this, of getting validation of, yes, that issue I'm encountering,
the cohort that we're talking through a lot is the decisions and the challenges are a little bit
higher level. So it's questions about, so making technology decisions, like, hey, we're trying to
decide, we're moving to the cloud, and we're trying to think about, are we moving to Databricks? Are we
doing to Azure, AWS? Are we using Tableau or Power BI? And these are large, big picture questions
around technology choices. That's something that's come up a lot as companies feel like,
as leaders feel like they're in transition between legacy data stacks and moving to new data stacks.
So we talk about technology choices and considerations and how do you even make those
choices. The other common patterns that we talk through is skill sets and staffing of teams.
And so how you weight your team around maybe more technical data engineers or database administrators,
and then more business focused analysts, and then all the different little skill sets that maybe fall
in between there, and how you have a team that's well equipped to bridge the full gap that is data
in a source system to business intelligence for a business user. And so there's lots of different
ways that gets configured based on the size of the org and the size of the team of who's supposed to
do what. And your tools play into that as well. Some tools allow users to build all that maybe
in one place. Some tools require that's multiple roles or different functions handling those
different parts of the data value chain. But that's another common question and the common
consideration we've had. As well as this pattern has surfaced as well, one of the main hats that
a data leader wears is their interaction with the rest of the business organization that they serve
and the stakeholders that they interact with. And how do they interact with those organizations?
And how do they measure the success of their interactions with those other organizations?
And so it's like, hey, we're a data team and we're pumping out reports and we're delivering data
products to finance and to operations and to donor relations and all those different sorts of things
and government affairs. And so there's lots of different business units that they interact with.
And how do they know if they're doing a good job at that? Or how do they measure or gauge
the interaction? Because the goal is they are a trustworthy source of data and they want to be a
partner and they want to be analytical advisors and really help them make strategic decisions.
And how do they not just become ticket takers and report just viewed as like somebody who pumps out
reports and respond to my data request. And so there's some good conversations here about how
you show up as a data team and a data leader in relation to those business teams. And so how do
you do things like NPS score surveys and different ways of collecting? Are we doing a good job?
What do they think of us? And are we responding well to their needs? Are we meeting their needs
well? So I found those conversations really because every data leader is kind of like homegrown,
a different way of thinking about that and different way of managing that and trying to assess
their success relation to other teams. And so sharing the cross learnings there has been also
really useful. This makes me curious about one of the most maybe elusive things that I've seen
within my data career is the importance of data modeling. That was something that we spent two of
six weeks discussing in this bootcamp. So if it's one third of the entire bootcamp is how do you do
data modeling and how do you do data modeling well? Clearly that was an important topic for
data engineers. And yet in my experience, I've seen data engineers think of themselves as the
pipeline gurus. They're more interested in their ingestion pipelines and not as interested in
modeling the data for the business use and the business analytics. So what role does data modeling
play in your cohort? And does that get more technical than you typically intend for this
leadership cohort? So I'm curious, what does it look like to talk about that? Maybe elusive thing,
because data modeling can mean so many things to so many different people.
Sure. So just to give you an outline of the course real quick. So this is the way we tackle topics.
There's myself and then two other mentors who do some lectures and content and kind of lead this
thing. So I do a couple of weeks on foundations of great data teams. And so the first one's
kind of like purpose and strategy. And then the second one that I do around foundations of great
data teams is more technical and functional behaviors. And so what those technical and
functional behaviors look like in addition to data governance and kind of like developer
processes or change control or CI CD, those are two of them. The third one is data modeling,
as well as so great data teams have like the functional and technical patterns and behaviors
and data modeling is one of those core ones. And then we spent a couple of weeks on data architecture
and a couple of weeks on power BI and administration governance strategy, managing power BI developers.
And then there's a bonus week on LLMs. But the point is like probably like week four is when we
get to these technical and functional behaviors of data modeling, data governance and CI CD or like
good developer practices. And so data modeling really fits into this, the main gap that I hear
and the pain points that I hear from data leaders usually comes down to, I usually end up back
talking about data modeling because they talk about all the data landing into a data lake.
And it's basically just a copy of, you know, copy of source systems. And then they remodel
and reintegrate the data every single time they build a report. And so it's like, they're probably
really good modelers. The fact is they just do it every single time they build a report
and it becomes really burdensome and it takes a long time to deliver reports and it's not
unified. The reports may not be modeled the same way every time and the logic may not be the same.
So data modeling becomes an important pain point there. Another person was talking about how this
ends up being like in the BI tool. In the BI tool, they're calculating measures and they're calculating
relationships between these data sets, integrating these data sets for every single time they're
building the reports. Sometimes it's happening in the database, sometimes it's happening in a
BI tool, but there's a lack of data modeling. And that pain point shows up when it takes them
a long time to respond to report requests. And they realize that they're building the same logic
every single time because they haven't thought through and they haven't done the work yet to
design a business data model, like a model that represents how the business functions and is
structured. And so this comes back to the conversation that I've been having with them around
how do you interact with the business teams and how do you show up with empathy and appreciation
for the business problems and challenges that they have. And those are the conversations that
allow you to do data modeling. Once I can understand and empathize with the challenges and
opportunities that they're facing, I can start to think about mapping their business process into a
data model that represents the business. And it creates then a shared language between technical
world and business world. Where now when we talk about a customer or when we talk about
revenue or when we talk about events or operations, we have some similar language because we've
designed data and we've constrained data and we've manufactured data to look like the entities we
want it to represent. So I think about it as a shared language now between business and data.
And anybody who's worked in the data field knows that that's the biggest breakdown that always
occurs is we don't have a shared way to talk about stuff. And so the business person will say one
thing over here, data person will say one thing over here, and there's a giant chasm in between.
A data model bridges that gap. So that was a long way to way of saying, yeah, data model comes up in
like all of the pain points that they're talking about usually. It's like, well, let's fix our data
modeling problem first. Yeah. Oh, that's great. That's great. The shared language I think is so
important because even if you're getting technical and you're trying to just determine what's the
what's the best name for this column in the BI tool. Well, that's a good indicator if you're
close to sharing that language with the business, because if you name it something and the business
is like, oh, I didn't use that column because I didn't know what it was, you've missed it. Like
that's poor data modeling because you didn't have enough conversations with the business users to
determine what should that column really be named for them to get value out of it. It even reminds
me a little bit about data lineage. And I was thinking about this the other day in like, you
know, what would a baby computer call its father? Oh, no, I know what this is. Okay, I don't know,
Troy. Go ahead. Data. Oh, that's like so perfect. And
had to get my dad. You had a data lineage and I thought we were headed somewhere super productive,
Troy. Okay. I think data lineage is also important, but not in the context of a baby, a dad joke.
Troy, so tell me about the tech stack you're currently working with and the tech stack that
you learned and maybe parallel or compare and contrast those two pros and cons that you're
seeing between the different tech stocks that you've encountered in your day to day and then in this
bootcamp. Yeah, yeah. Great question. So, you know, my day to day has been Microsoft stack. I have
experience with both Google, BigQuery, Oracle products, PeopleSoft, you know, some of these other
big organizations that are out there. But right now day to day is the Microsoft stack. And
the difference there is in order for this bootcamp to function, it was mainly open source tools. And
so you get a very different feel when you're using the proprietary low code citizen developer
type feel of a tech stack that your enterprise has purchased and is invested in. And so Microsoft
is very much that it makes it easier to do things at just the click of a button. At the same time,
you might find it limiting, like you're almost you have your hands tied behind your back because
you can't do something you know it could do. If you just could get behind that gooey and actually
punch something in the way you want it to. And so that was the big differences. Right now, I'm
trying to think through a way of integrating dbt, dbt core, I should say, which is the free open
source version and trying to get that integrated within the Microsoft stack and use it effectively.
And I'm just struggling because now I'm trying to take an open source tool that's, you know,
code heavy. And that's just not my experience. I am not a coder by trade. And so how do I get that
to plug into Microsoft environment well and work seamlessly where I can have a better just way of
building models efficiently, quickly with version control, using Git, all those kinds of things
that I'd like to be doing. And I'm just not there yet. So I learned some things I'm really excited
about, and I'm struggling now to plug them into my particular experience. So I think that
I think the context around like using more SaaS tools or like abstracted tools versus like using
low level open source tools is your access to the knobs and switches under the covers.
And you're always doing a trade off of ease of use, and fewer knobs and switches available.
And so for smaller organizations with less technical skills or just less technical
capacity, fewer people, you probably opt for fewer switches and easier use cases.
For large organizations with more complex requirements and use cases and heavier technical
skills and capacity, hey, give me more knobs and switches. I want to configure things at a detailed
level. Let me ask you this, Joy, would you recommend a data engineering boot camp to somebody?
Or what types of, was this boot camp worth it? Are there other boot camps you consider that you'd recommend to people?
That's a great question. And with many things in life, it depends, right? And so, you know,
I thought I had a great experience. Does that mean that everything was perfect? No, there was always
a little bit of bumps along the way. But if you're looking to grow in the technical side of it, as
you've heard in this conversation here, I would highly recommend the boot camp by Zach Wilson.
I think he's doing a great job, always iterating, always making it better. And so there's some great
content there. And Sawyer, of course, I know you're going to toot your own horn on the cohort here,
but, you know, share one testimonial that you've heard from someone in this current boot camp in
terms of what they're thinking and how they might recommend just something off the top of your head
that you've got. Sure. I was about to say, like, we're not getting paid to say this stuff, but like,
and we're not getting paid to promote Zach's boot camp, that's for sure. That's right. But it is
part of my business, this community. So the cohort, yeah, one of the things that someone shared with
me at the end of the last cohort, this is the second one we've run, is, hey, they feel like they
got a lot of empathy and community for the first time as a data leader. They have their team and
they have their bosses. But the first time they're like, I know some other data leaders, and I'm
going to keep these relationships for a long time. And so that was super validating because that was
one of our goals. We hoped it would happen. And at the end of the first seven weeks of this, it
seemed like it did. And that was a big takeaway for one of the cohort people participants for the
first time. And it seems like it's shaping up that way during the second cohort as well.
That's great. That's cool. Yeah, of course, if anybody wants to chat more with me about
my experience in the boot camp, of course, I'm happy to respond to any questions that people have
and they can just reach out via my information. I think we have somewhere there on the website.
And so we can do that for sure. All right. Well, this has been Making Data Matters. Thanks, everybody.