SRE Journey: Pushing Change to an Organization – The SRE Show EP 9

it I am welcome back to another episode of the SRE show. My name is Mitch Ashley mcto with Textron group and co-host with my friend and partner. Austin Parker.

Who's daddy? Right? Welcome Parker awesome part.

I keep saying Parker because every day it's fun things. I work with a Parker. Yes.

He's our headsdale. So he's always calling me about something right you there's a lot of Parker a lot of Parkers around there are and I have another person who I work with his last name is partner. So I'm just normally confused with Burgers.

So anyway Austin it's green space collisions, one of the hardest things to deal with in the software. They are it's a little bit of a context shift for me. So we have a great topic today.

We're gonna be talking about S3 adoption and particularly around the cultural and process and mindset changes, you know, it is one of those like, oh, yeah, let's do it just sort of fit soon. And I think we'll have some good experiences to share and and with the folks watching So hopefully when something from each other and share something that might be helpful with them. So have you taken off here?

Just a moment Austin, I'd love to have our guests introduce himself page which you introduce yourself. Sure. Hi everyone.

I'm Paige Cruz. I'm a senior Dev Advocate over at kronosphere and observability platform for all you Cloud native Folks at scale. Good deal observability another Hot Topic just like SRE so welcome glad to have you here and starlight.

Welcome industry yourself, please. Hey, I'm Starlight Romero. I'm a senior SRE at Flatiron Health.

We are a company standard on cancer Solutions my team mainly deals with all the fun Cloud SRE stuff. Oh, that's very stuff. Thank you.

Do along with Terre phone and kind of the infrastructure structure side of things too. It sounds like exactly great work you all are doing over there. Thank you.

You need all the help we can get back. Okay, it's oh Austin. I know you're passionate about this subject.

So Sure, that's gonna kick things off here about adopting SRE. Yeah, gosh, there's you know, I feel like I've been doing an awful lot of reading and thinking about this the past. Really month or two kind of coming?

through kubecon and then reinvent where it feels like you know people can't stop talking about platforms right like we've kind of moved into this phase of everyone is thinking about platforms and developer experience and I'm curious, you know one thing I've seen in my career is that SRE is often. you know you often come in, you know, you're often, you know, an SRE will be hired in to sort of develop this idea of like a platform internally and it's expected to provide things to other developers to their peers in a way that is pretty unique when you think about it, right because you know, if you're just out there and you're you know you go and you apply to become a software engineer somewhere and you get on board and you jump in and it's like what's your first thing? It's like oh, well, I need to go fix a bug or I'm gonna go start working on this feature you get integrated into a team you integrated into a process, but I feel like a lot of times sres get brought in and you're you're tasks like okay.

Here's this mess go go bring order to it. And I wonder you know Starlight page like is that track with you? All is that sort of how it feels to come in and be an SRE into place?

A lot of times I can jump in and say yes, I would say. A lot of the times it depends when it when you are a first SRE hire or you don't know that you're one but you think you go to a place and you find out you are establishing an SRE function versus walking into an org that set up it can be an uphill battle and that totally tracks without least my experiences. Yeah, I think change is really hard and it's we expect a lot out of sres more than I think is.

Sustainable writ large for the industry sres aren't super humans. We just happen to know a little bit about our operating systems and our infrastructure stack and some app Dev. We are just humans and it's a lot to pin on to one role Starlight.

I'm curious. What what you think. Yeah, I would definitely Echo what you have to say as far as like coming in and sort of being expected to solve these like major, you know institutional wide problems.

I think that it's it used to be you know, sort of there's a Dev in an Ops and then comes devops and now we're at this platform phase and the tooling that we're building is tooling that's very specific for our our users which are the developers. So it's it's pushing that knowledge still of hey, you have to deploy your own applications to the developers, but we're there kind of holding their hand every step of the way. So on that on that not our topic, I guess from that note.

Where do we you know, let's let's dig into it a little bit right because we want to really discuss like well, how do you solve this problem? How do you kind of help create this culture? Is there something that you can do as an SRE either, you know as a new SRE or maybe someone that's you know, you're a second or third or you're you're an organization that is kind of on their SRE Journey, you know.

How can you help? Actually the preface of another question. My kind of interpretation is a lot of times leadership is coming in there.

They're the ones that you know VP of engineering or a director of platforms or something. Like they're the ones that are hoping that those sres this individuals can help drive this change is that like the actual problem or is it you know, is that they're coming in saying like this is your problem to solve now. Versus something that sort of like bottom up right we're developers are asking for these platforms we built or they they want that change to happen.

And if that's the case do we need to flip it? Right? Like do we need to say like, okay first I have to go and get people to want this before it can actually happen versus the top down like we're going to do this and you are now my Agent of Change go.

Yeah, I got. I feel like it's tough because a lot of these these. infrastructure components developers may not even Know about or know what is optimal?

So it's tough because sometimes you as an SRE can see that this specific system in place needs that Improvement, but the developer themselves don't see that and then you have to work to get that buy-in in order to bring this change that you know is going to make everyone's life easier and for me, it's it's really about Trying to form like a symbiotic relationship where you're not just asking the developer to like up to their their infrastructure or always asking and asking it's like trying to to bring something to the table and make them kind of. Pivot to be able to understand your vision. Yeah, I think.

A lot of the times SRE roles come up and they have to be funded by somebody like, you know, a VPN up somebody is set aside budget for a title of a role SRE. Sometimes it's devops engineer, whatever but I always like to say how did we get to this role title? When did we decide that we needed this?

What was the role titled previously because there's a lot of SRE roles that are really just rebranded release engineer's that kind of stuff. I've seen where SRE owns from PR to production and also the underlying infrastructure, which is honestly a pretty big umbrella. That's the thing.

I would say is is most companies like to start experimenting with SRE slowly with a couple of folks but gosh You could be a lot better prepared. If you're only going to hire onesie twosies, if you have a trusting relationship with your devs, you're able to find out at least what the knowledge and the skill gaps are not that you don't work with talented devs, but we've moved to the cloud containers and kubernetes in the last what six ten years in Ops folks have been writing that wave. We haven't yet.

I think enabled our developers and educated them enough. I don't see questions about kubernetes or how you deploy in software engineering interviews yet. I know charity wrote a great post about that.

So I would say on the whole we're hiring folks and expecting the world of them and there is a disconnect between what leadership sees as SRE and the vision. I think we've sold them on the vision, but what we're gonna dive into and this talk is how do we get from almost zero to that vision and I've got some thoughts. I've tried some things.

All right, you've you've definitely been both of you been the trenches. I'd be how do you what's step one or what step zero even getting from like the vision to the reality. Communication for me as soon as possible if I can get in front of that engineering org to give an update on a project or hey, we're starting this thing or we're gonna compare vendors anytime you the one as the soul SRE can get in front of a crowd and scale your Communications.

I find that I find a survey a Polly and slack Google forms. If you have to just getting people talking and finding out what the problems are where the skeletons what's the stuff folks have been holding on to that they're tired of complaining about because they know it won't change. That's what I'm most interested in finding out in like my first exploration phase.

Yes, darling. Yeah, I I like a lot of what you saying because I try to do the same thing. I think also like bringing together different types of methods.

Like I I've come into companies where one team is is doing things one way another team is trying to accomplish the same goal but doing it completely different way and and really like honing these different like Ops practices into into like a golden path almost because then You really can can improve that path. One thing. I see of cross different companies that I've been at is trying to support to too many cases for slightly different things that that developers need without like unification and I think that's what really like hinders SRE from from reaching the full potential at a company because when you have all these different like small use cases that you have to fill up you can't really focus on making those improvements those make your improvements.

After and I'd love to jump into when we started SRE at techstrom. For me, you know as the leader of engineering I kind of recognize that the role of SRE solves the problems that we had in our infrastructure and one of them was straight into your platform comment earlier as getting on a common base of infrastructure and applications because just maintaining what we had was too easy for things to get out of sync and get old and also just making her life similar if we want to roll something out across multiple apps or sites or whatever and then start to work on some performance aspects. So kind of took one person who was our I'd say kind of Rover utility person who did a lot of infrastructure a lot of admin kind of things instead.

Let's establish that you as our first person and focus on this and meanwhile, there's some training and some books and to read about us we go kind of get on the same page. So that was a more of a top-down but trying to be informed and really do SRE and it's just not in the name. It's worked out really well.

So I'm hearing a variety of mixes right kind of how to get started. Yeah, I I want to Echo Pages point though. I think communication is sort of the the key to really every single stage of the SRE Journey.

But certainly when you're starting out is is one of the best ones. Let's actually take it a step further though. And let's let's assume you know that you you go in you do your listening to or anything's great and things are firing in all cylinders.

You've managed to get some nice standardization in place around tooling or processes and things are going swell, but now it's time to grow. and I wonder how we manage that growth right like One of the you know, it's hard to go from zero to one. But I think a lot of times it's hard to go from one to two when you you know, make that first and I think page you especially have lived this right being not the first higher but the second and having to Move from being that individual practitioner to being someone that is like either implicitly or explicitly leading a team of SRE and how do you you know divvy up work and responsibilities?

How do you actually start to embed that practice in other teams in the org be curious or your thoughts on that next step of the journey? Yeah, ah growing the SRE team. Stage it is the fruits of your labor you get to enjoy them because your team has been successful enough that the organizations decided to invest so it's always happy.

But I would say the way that I've approached. Growing teams, I think for sres onboarding. I mean for any engineer onboarding is essential for setting them up for Success specifically on call onboarding because we expect sres to know East-West north-south every cluster every environment and that can be a lot.

So I like to get folks confident for on-call knowing our processes our tooling our monitoring and observability infra and I start at the time that I have a team. That's when I start to get a little bit more formal with weekly meeting notes. I make sure that everyone on the team rotates to take notes because I don't want to be the blocker if I'm not there one day.

I don't want people to say, oh, I don't know how to take notes. I don't know where our project plan is XYZ. So I like to make sure sorry as independent as possible early on by facilitating meetings kind of throwing them into How to run things just giving people responsibility early on in a safe way and then on call onboarding is a whole other topic, but I would I think sres are really great to do an alert audit to come check out are there still dashboards that fresh eye to say I don't think we need this.

I personally delete so many muted forever alerts all delete dashboards that haven't been looked at. I like to clean up the crust because it's our shared Campground so to speak. So that's I try to do.

Yeah, I start to transition from Mostly. Just talking to folks to to writing things down when there's a second third fourth person. Definitely documentation big one hundred percent.

I also kind of just like the approach of throwing people in the fire, right? Yeah. Not not the Super Hot Fire.

It's the mildly hot miles salsa. Okay. So if you know new SRE coming on board, hey, there's all this like outdated infrastructure or things that need to be updated go figure out how all that works.

And if you come if you have questions, you know, feel free to come back and ask me but really like that Hands-On. Like okay. I need to update this.

This is referencing this other thing which is connected to this really gives you appreciation for the whole system for the code Etc. And for for the approach that I really like for onboarding on Call is Having having like a rotation of two so, you know always having like a secondary on call but when they're first really new just like a shadow just like I'm primary You're Gonna Come behind me. See what I'm doing.

And I think that's a really easy way to integrate it. And I like that well both what you said page it always seems like the we default the more data is better and usually what's the right metrics whatever we should be watching. What's we tried that but let's get rid of it.

It's not useful. Let's focus on this. It seems like a big part an important part of this role right that we're looking at whether it's the monitoring observerability or measuring performance or whatever process whatever it might be.

That's a great that sort of fresh ice is the second person like a real helpful role to say what's that? Do you use it? Why?

Okay, we try something else. Right. I really appreciate that.

Now paying back observability. That is one of my I would actually let me rephrase paying back monitoring debt is one of those things that Love doing I will walk in somewhere and say what if we just deleted all the paging alerts it seems like they're pretty noisy and they're not tuned and yeah, yeah so we can laugh in this meeting. But when I bring it up people are horrified and nobody's taking me up on it, but if anybody is please get in touch with me because I think that would be one of the quicker ways to get back alerts.

I thought of a similar thing but with infrastructure that's not like centrally managed. Like if we've had a infrastructure, you know through Chef or pop it or all these systems that no longer an active use. Let's just hey if it's not in terraform, it's just deleted just like, you know, those are my emotional support virtual machines names Austin.

Yes all back on those. Absolutely. That a great great insights though, I think.

And I think that's very range true. Right like you have to I really like this the theme we're building here right where your first step is sort of this communication and listening and then your second step is like, okay now we're recording everything. We're documenting.

What's our third? Right because I feel like In a lot of ways the third is actually the prop is an interesting problem to have which is a success. because most of the time I mean most the time you're either, you know, you you have that first accessory that comes in they build the practice the team grows because due to demand and now you're successful.

And now what do you do right because we don't. Really talk a lot about like what is this? You know, how are you actually?

you know, the fires are put out the the amount of water coming in the amount of water going out of the boat or maybe not even equalized. Maybe you're actually like making progress on it. What do you do with an SRE team?

That's all in success. What's the next step? That we're all thinking you maybe a little optimistic about how many SRE Transformations end up in success.

For they find successes and is part of the role, right? Hey the great thing you get to define success. However, you like keep a wish list of Areas, I'd like to Branch into that are net new for the company.

So introducing a new function like I will say chaos testing. I believe chaos testing is testing your monitoring. Did the great alerts go off.

If this thing couldn't be reached XYZ. I would like to see more of that. So that's I try and do that or if problems that I hear about that are recurring that stand in that way that critical path of pushing to prod local Dev if like tracing with cicd, I'm planning on using that this year to optimize pipelines and make sure our overall resource you should is efficient.

So I think once you've reached success mode that is your fun time to look at your big wish list of things people have asked for things that you keep hearing things that come up in surveys and really now that you've got that trusted relationship with developers incorporate them into your design process. If we want to do A, New Path or autoscaling or something or make it a one-click thing what format makes sense because developers and sres have different workflows my find on the whole sres are really comfortable at the commands line. But sometimes you get dropped into like a super nice Enterprise vendor tool and we're like whoa, give me back to a cube control like take me back to my terminal.

So that's where that communication you can build on it and just say hey. So and so let's talk about a day in your life or let's talk about the last deploy you did and let me watch it stuff like that. So I think the off the top of my head.

I mean yes service level objective setting figuring out local Dev load testing cicd Improvement and introducing something new like chaos. That would keep you pretty busy for a couple years. I'd say once you found success.

I like what you said about the the shadowing like I think it's important to kind of just like act sort of in the background. Just watching deploys happen watching. Devs trying to update infrastructure roll out a new service any of the above and just really like watch the pain points that they have and you know, you see them struggling don't even say anything just watch how they go through it and that really gives you insight to the processes that you need to improve.

I also just want to highlight chaos engineering because I'm a big proponent of chaos engineering. I I think that chaos engineering can happen both in sort of a metrics type of way. But I also like chaos engineering from the the human type of way.

Just you know, what if you know, what if a whole team is just out one day one week or whatever it may be and kind of you know, you can even simulate that you could say Hey, you know, we're gonna revoke your access temporarily to this thing and run this Market incident and you won't be able to touch it. Sounds like a little bit of a little movie scenario in there. It's for the heck or something like this out.

It's interesting to you know, an easy way to get into chaos Engineers. Just kind of break testing right? It's all and of course that's gonna improve reliability and and resiliency.

So that when those five years do happen, maybe we know either how to prevent them or we know what to do in case they do they do happen, right? It's good stuff, you know Parker Boston. I was thinking that you know, sometimes when you experience successes, it isn't everything that you're working on right or some things that are working really well, but you focused on and something that's useful to do is just kind of step back to it.

Just examine. Well, why is that working? Well, why did why did that become the thing that was successful?

And then what can we replicate or what mistakes that we made and we learned from two so you can build on that. Yeah and understand it. I think at some point like a big part of that.

Success finding is actually a very business thing which is being able to calculate Roi right? Because at some point, you know, I think one of the things that plagues a lot of initiatives like SRE is especially that people will try to get into the specific Roi calculations very early, like they'll try to put a lot of numbers around it, you know before they really got going and that tends to I think cripple cripple the program because you It's what's the aphorism right as soon as the metric becomes a measure it ceases to be both effective both. One thing I think is interesting is is this actual like these three things you put together here, you know this listening this learning and documenting and then you know, this funny success is actually this very common pattern outside of SRE.

There's a paper. I think it's called the actually have a notes Here life cycle of a silver bullet. It's talking about sort of the idea of a silver bullet in you know business where it's like we need have this big problem.

So we're gonna none of the existing Solutions work. So we're gonna go and we're gonna Silver Bullet bang Pixar problems. The Werewolf of organizational dysfunction I guess and that first three steps is actually like that's what works right leadership goes and says, okay.

We recognize we have a problem. Let's go to the people that are suffering from the problem. Let's go down to like the you know the workers and ask what it's the problem.

What what are your big problems? How can we fix them? What do you think and they listen and the the key thing is that they learn and they actually are receptive to the feedback, right they go and they say Okay, we understand that.

This is there's problem X Y and Z happening. Tell us about them. What do you think could solve it?

They listen to that feedback the Implement that feedback and what happens is that the problem gets solved, right? And where it gets into the lifecycle part is then everyone else that isn't kind of the same bucket says, oh, you know, they they go read the blog or they hear someone talk about like, oh, yeah, we saved like a billion dollars by doing SRE like, oh I got to get me some of that too. And now you get into this thing or it's like well, let's let's try to do what they did.

but We don't know the exact way. So we're just gonna kind of look at them. We're gonna talk to some of their people we're gonna do a little bit like it and then that duplicates that repeats and repeats and repeats.

And now you get people that just like we're gonna do SRE First Step go get the SRE book. And then read that and then do everything it says. Without really understanding or without doing that critical sort of listening and learning part.

so yeah, my question or my discussion point would be Most people are doing that I would argue right they're not going to ask are you from first principles are coming it to it because they read or they saw a talk. It's like someone said SRE is great. You got to do SRE.

And a lot of times that ends in Failure, so what do you do? If you are the unfortunate SRE that is kind of in this like we're just echoing whether people have done how do you try to salvage that how you know, can you Salvage it even? I would say Step Zero decide if it's worth salvaging and how much?

How much? realistically you can Have change at that org and how much will there is to change but setting that aside if you're going to do that, I think you're totally right. The practices don't transfer between companies necessarily and the way that I've addressed.

This is I call myself like an atlassian archaeologist. I like to look back at what were the last six months for this org? I also look at you know news reports where they're layoffs.

Were there new product announcements are is our team fatigued from pushing through Milestone Milestone Milestone. Did we have a bad year. I kind of look at what the What's that where the climate is and what the environment and morale has been because that helps me decide do I it helps tune my empathy meter basically do I need to be more caring and listening mode and know people have frustrations and recognize it's not about me.

It's kind of the the organization that's been set up or do I try and just say, hey, let's look at this. Is it safe enough to say let's look at this last incident replay it. Here's some things I notice.

I like to figure out who I can talk to and who like where the sore spots of the orgar because often that's what you want to fix but you do have to be a little bit delicate when going about it because it's not that most of the times it's not that people are Making crappy infrastructure making these horrible decisions. They're doing the best with what they could at the time and so I try to keep that in mind even when there are decisions where I'm like why how what were you thinking? I keep that dialogue internal.

So my external is just a receptive. I always want people to feel comfortable telling me about scary production things. Yeah.

Yeah, yeah, I would definitely say that. it needs to have that communication always open and in order in order for you to really like understand what problems. Your organization have has and how to solve them.

You could look to these other organizations for for cues, but you can't copy a one-to-one mayor of them I think more so if you're looking to copy things it should be the overarching ideas that that are are being brought through an SRE practice because once you get to the individual implementation that the developers that are that are working for your company are different where your company does it might be different from this other company and and as you were saying page just like the climate is different. So you have to tune all those things in order to get the maximum number of years listening to what you have to say and that really goes back to number one. The first step of communication and communication is in the first step, but it carries on through each step as well.

Ever so I'm curious tactically like if we look at an SRE practice like having embedded sres how if we were going to use that as an example. How would you evaluate whether or not trying embedding was something that that you wanted to do for an org or would make sense? Open question for anyone.

I think with something like that you are always looking at. historically how decisions get made right because ultimately I mean, there's more than two types of teams. There's more than two types of organizations, but I think quite broadly you can look at either sort of command to control type places where they are used to decisions being made.

through kind of a team proxy right where I if I need a widget if I need a foo, I go to the food team and I say one food please right or if I need some other service that I'm going. Through that other service team or they're very clear pipes connecting everyone. And if that's the kind of place that you're at then like I don't think that embedding works very well because that's just not how people are wired to operate.

You know, one thing I've learned is I mean to be You know catch more flies with honey than vinegar, right? Like you can try to change a place but you have to know where to push and where to pull and you have to know what part of the organ is gonna break when you do that like a huge part of SRE in general or just existing is understanding organizational Dynamics so that you can know how to be effective at trying to change the organization because sometimes you're going to push you push the wrong part the whole org is going to push back and you're going to Hurt your efforts now. If you are in a more flat sort of org, and there is more like individual or like, you know.

Individual teams have a lot of autonomy then you know, yeah, that's a good that that is a sign of embedding could where you were effective. The thing that contemplates complicates all this is sometimes you also need to be able to look at the flat place and say like well you actually need is a little more structure and you need like the central SRE team or the central observability team. It's gonna set rules of the road because you're too everyone's too ah, and sometimes the place it's very rigid and command control oriented needs the like no you all need to like push the boundaries a little bit more right like you.

Yeah, you don't have to do things the old way so I think that's the calculus you have to make as a your developing the practice. Yeah Starlight has this come up at Flatiron that combo of embedding. Yeah.

Yeah. I I like what you were saying Austin about the Honey's with vinegar applies has vinegar and honey slight detour. I I have a lot of flies and my place and the way that I catchflies the most is actually with a spray bottle and I pinpoint that I think that that could be actually translated into this is if you want to catch flies, you have to pinpoint one at a time.

I think if you try to necessarily go the two overarching route with either vinegar honey, it can't work in some scenarios, but The the way to get things off the ground more effectively is is with that pinpointing spray bottle one at a time and although it takes longer. It's going to ensure more success. So in that sense, if you want to try and bedding, it doesn't have to be like this all or nothing buy-in.

It's like let's experiment with the team or two and see how this goes and let's do it so that they have support from a platform seeing let's try it. Maybe one team does maybe one team doesn't have support from a platform see and just see how that goes and where things start to either Excel or deviate a negative ways. To that point like I think one place that's really useful usually tries stuff like that is on.

The kind of bring it all back the release engineering side of things right like you. Or cicd or to our Q, you know, QA whatever that looks like but find sort of things that are important but are not necessarily in that core. code writing part of the stlc because those are usually a little you know, you can usually go into those and There's more flexibility.

Yes, but there's also usually a lot of like low hanging fruit, you know people tend to not spend a lot of time thinking about like how slow are my tests? you know or how how long does release verification take or any innumerable other things that could have massive, you know efficiency impacts if you go and you know spend time and you look at them and you work on them. And then you can take those the successes there and use that as kind of the oh well.

let's Take this and expand it, right. I think a hundred percent if I was gonna experiment with anything like tracing I would start with my cicd tests. I would start with one team one person his passionate and Let it Grow from there.

My most successful attempts at my most successful teachings of these monitoring observability. How do I dashboard this XYZ has been sitting with someone for their first PR then or their first, you know walking through it. However, you set those up and then saying okay next time just send me a PR Oliver view it I'm still here for you and then letting them teach somebody on their team and then I'm like you're free go off and and teach teach the people the things that I have found works really well and it goes right to starlight's point of aiming this great bottle one at a time focused attention and letting that build on itself.

Well, I think we're actually getting close to time here. So yeah, we want to go around and like what's the one takeaway? I guess like if you had to just if you had Or yeah, I won't take away.

But like the one thing that we should have talked about when we didn't about how to really improve your SRE Journey. Start with Starlight. Yeah, I think the one thing we didn't talk about is is it really takes the the right sres for the company, you know, it's like we were talking about each company as a different culture.

You need the sres to support that. Mmm, okay, okay. while you're Looking for sres I hear recruiting SRS is the hardest people tear their hair out trying to find one.

Look at your interview questions as well. Are they all focused on Tech stock kubernetes XYZ. Where are you testing for communication skills cross-team dependency resolution.

I'd like to see more of that come up in SRE interview questions versus algorithms and data structures to be honest. That'd be my tip. Okay, Austin, how about how about you?

But what's here what actually no, I think honestly, we're I've been spending a lot of time playing around with chat GPT the latest and greatest. Yeah from openai and I'm fully convinced that if we the days of humans typing in yaml is quickly coming to a close. So yeah, no, we should definitely be I think the ability to communicate is I mean this isn't just SRE this is like anything in general right your ability to communicate with other human beings is going to be the real differentiator, you know in the future and even is today but being able to focus on building SRE teams and really building individuals up that can Help not only.

communicate about you know, hey, this is why this systems are doing this or that other this is why we're doing this technical thing that technical thing but helping, you know, trying to find people that can Elevate your rest of your engineering team right like my communication perspective. It's not you know SRE isn't just Slinging ammo it's not just like building terraform. It's helping to instill these values of you know, blamelessness and then trust and communication and openness and so finding people that can help.

Kind of sell that emotional state to the rest of your org is really important. Right? So it's not just that you know, it's how are you interviewing for EQ as well as IQ, right?

So yeah, actually excellent stuff. You know what I would add. is don't be afraid to Be proud and communicate successes to don't assume people know the progress that you've made.

Sometimes it's easy to laterally for folks that you work with every day to know what you what you've done accomplishments that you are the team has made but you know this kind of important that upper management your boss or maybe a little higher needs to know and we've had some good successes. Don't be afraid to tell your story now, you don't need to say it every second every time they talk to you but you know, that's how they know. You're doing good work too.

Sometimes it doesn't always make it to the right folks. So You know to assure your story if you will, well Austin's been fantastic. Thank you to you and the lightstep team or sponsoring the SRE show.

page and starlight amazing experiences along with with Austin's to share today, and I'm sure folks got a lot out of this. So please tune in. We're we have lots of episodes available.

We have some live Round Table that's coming up here. Check us out on Tech strong TV. com.

So Austin, thank you so much and thank you age and starlight great having you all. Take care.