Yeah, this is Ah, this is a fun story. I graduated with a degree in computer engineering A Z. I went through the degree. It's a mix of computer science and electrical engineering, and I decided that I liked the computer science more. I like the software side of things better than the, uh, design and math related to electrical engineering. Um and so when I actually, while I was still going to school, I started working for the school as a software developer. Um, just to start getting my feet wet. So I got two years of experience working full time for the school, and I worked closely with a a sys admin were Web developers. And I enjoyed some of the sys admin work that I got to dio and enjoyed talking to her about her experiences. And, um, I got her back story that she went from software to systems administration. And so whenever I graduated with my degree, I actually took a job as a systems administrator for about a year. And while I was there, my hiring manager was really good, awesome mentor. He helped kind of guide me into the Dev Ops world and That was something that I hadn't learned about and school wasn't anything I had heard about. So I was like, Well, this is neat. Like it marries the software with the kind of the systems. Um, unfortunately, that job didn't last very long, was only about a year. It was time to move on. And so I took my current job, which was listed as a Dev ops engineer role which, you know, come to find out in my journey and Dev Ops. That's glorified software engineer. But, uh, I, you know, because of that guidance because I took that job is a systems administrator. I ended up where I am now, where I am promoting Dev ops principles. Helping teams implement them on by helping our whole team are large are large technology team kind of move forward with those principles and it z exciting. It's slow when you work on trying to change and organization and things like that, especially when you're just this little person on a little team and you're trying to change a big organization. But it's a lot of fun, and I'm really glad that I've been guided to where I've come to

um, but when I applied health catalyst for this role, I had no idea about that. They were a work from home company already, at least the technology team. And so my work from home experience has been awesome because they're already set up for it. They gave me an equipment kit. Um, so I have monitors and all, you know, everything. They just gave it to me and my first, you know, my first day, essentially with my laptop. And Thor cowers. Health catalysts. It's a very flexible work environment. Um, we don't We have untracked PTO. We call it flexible PTO. Um, those kind of things I know. I'm going backwards. Here. Let Z, um, I for my travel. I only travel twice a year. Um, outside of a pandemic year, Um, we have a large technology meeting in the spring, and then again in the fall where we bring everyone in, it got co workers and other people on the technology team all over the us. So we all way all come into headquarters, which is in Salt Lake. Um, luckily for me, my travel just means I happen my car and drive down about half on hour. Um, and we all get together. We do planning. We plan releases of our software platform. We get the face to face time of with other teams. We do break out sessions kind of figure out what's happening across all the teams. Um, but that's about all the travel that ideo, um, and my responsibilities and the decisions that I like in my role. Um, specifically, my my team, my role were over the the release and installation of our software. We have a large software package, um, and so our team handles R release cycle, which is every three weeks for, you know, really seeing hot fixes and different things for the different versions of our software. S O R team handles the pipelines, The automation is that go into testing it all of that to make sure it's ready for release. Um, and then so that's those are kind of our responsibilities on that end. And then we also take it all the way to the clients. Once it's released. We have our client managers that come and they ask us, are scheduled time to, um, install the software. And so and then our team and my role. We handle that installations working directly with clients, strict directly with the client managers. Um, and sometimes that means we're opening breaking incidents. You know, Priority one incidents to other teams because the install goes south or things like that. So there's a lot of there's a lot of decision making their on. Hey, something broke. Is this something we fix, or is this something that we page a team on? Um, so there's decision making there and then also a Sfar, a czar, other responsibilities With the release, we make a lot of decisions about how we will do it the best. The best practice is the best things for our company to make it better faster to get code from the developers all the way out to clients. Eso we make a lot of decisions there and some of them are take a long time to implement. Some of them are quick little things that we could get in right away

So in a dev Ops engineer type role. Um, we do a lot of in between. So we live in between the software developers and we live in between kind of the client, the operations and how it's going toe act on dso we do a lot of scripting languages preparing things to be installed, preparing the environment to be installed ID um, things like that. So on our team, we specifically use power shell. We are a Windows company. So all of our everything we use the software teams use dot net. We use power shelter, take everything that's been built and bundle it and install it and configure the environment for it. Eso, um, software programs we again were are Windows Shop, where we use a lot of Microsoft tools. And so we specifically use Azure Dev ops on Do we use all the pipelines and release release pipelines, artifact storage? All of that happens within Azure Dev ops. That's where we track our work. Um and then we also are part of a ticketing system and we're transitioning to Jiro Service desk for that kind of client opens a ticket priority incident. So those they're just two of the kind of the main software programs that we use. Um What? Yeah, I think that's about it there.we do? A I forget what it's called. We run a conv onboard. Um, so I think I think all of the technology organizations we do some variation of agile. Um, some teams do scrum Andi the scrum methodology of it. Our team were less of a feature team, right? We're not spinning features. We're doing a lot of, um, improvements and other things. So we run with a combine style where we can just pull work. A zit comes up, but we still operate under the three week sprint. Um, that I guess other teams air on.