Speaker 1: So, Warren, what's been your experience with SRI.
Speaker 2: That's quite the way of just jumping into the episode,
Speaker 2: and I was so unprepared because I'm not even the
Speaker 2: guest for today's episode, So I don't I don't have
Speaker 2: an answer to that question.
Speaker 1: Honestly, Yeah, for sure, Jillian, And what about your thoughts
Speaker 1: on SRA. You're just like, you're a contract not just
Speaker 1: a contractor. You're a contractor. You just light stuff on
Speaker 1: fire and then if they want to put out you
Speaker 1: bill them for it, right.
Speaker 3: I mean really like, I just need to make sure
Speaker 3: data doesn't get deleted because that's like a problem that
Speaker 3: is that is a problem, Okay, And that's really all
Speaker 3: that I worry about.
Speaker 1: It's a security reliability because you can't be exploited if
Speaker 1: there's no data left.
Speaker 3: I mean, that's true.
Speaker 2: I will say that there is. There is a book
Speaker 2: out there published by one of the hyperscalers. I believe
Speaker 2: that attempts to define it in their own terms, but
Speaker 2: I feel like, like a lot of things they do,
Speaker 2: it's used as a introduction into the topic rather than
Speaker 2: used as experts. So I'm really interested to hear what
Speaker 2: our guests today will be sharing with us.
Speaker 1: Well, yeah, which is a great segue because clearly we
Speaker 1: need some expert opinions on SRE, and so we've got
Speaker 1: Amy Night with us. Amy, Welcome to the show.
Speaker 4: Happy to be here.
Speaker 1: I'm excited to have you here. So tell us a
Speaker 1: little bit about your background and how you got to SRE.
Speaker 5: Yeah.
Speaker 6: I love SRI.
Speaker 4: It's a little bit of a love hate relationship. It
Speaker 4: can be very stressful at times, but I also love it.
Speaker 4: I feel like it is kind of when I when
Speaker 4: I and this, I'll get into kind of like my
Speaker 4: path into SRE, and it just it really suits. I
Speaker 4: feel like my engineering brain perfectly and the high level
Speaker 4: there is. I come from non traditional background, so self taught,
Speaker 4: did the whole boot camp thing twelve years ago now,
Speaker 4: which is insane to me.
Speaker 5: I'm really old, or feel really old.
Speaker 4: Like I saw someone on Twitter the other day talk
Speaker 4: about like, what did you use before GET and I
Speaker 4: was like, oh, my gosh, I'm really old now because
Speaker 4: my first job we use material, which I guess is
Speaker 4: it but at the same time like it.
Speaker 6: Yeah.
Speaker 4: So But anyways, so backing up, and I used to
Speaker 4: do JavaScript jobber, so I kind of started off in
Speaker 4: the JavaScript Land, did node.
Speaker 6: And all the front end.
Speaker 4: I kind of focused heavily on front end for a
Speaker 4: little while, did note as well, and then I think
Speaker 4: it was like twenty eighteen twenty nineteen, I went to
Speaker 4: work at NPM, which was like my dream job at
Speaker 4: the time until they got acquired, and you know, it's
Speaker 4: just a little bit of a bummer because it was
Speaker 4: very short lived. But when I was there, we did
Speaker 4: cross functional teams and my manager at the time was like,
Speaker 4: you seem really interested in like this platform s re
Speaker 4: work infrastructure. We can probably hire for a web developer
Speaker 4: more easily than we can hire for that role. Do
Speaker 4: you want to go over to that team? And I
Speaker 4: was like, yes, sign me out, like you want to,
Speaker 4: you know, if I have the opportunity to learn a
Speaker 4: new skill on the job, Like yes. So I did
Speaker 4: SRE at MPM for a while, and then I did
Speaker 4: most of my sr rework at Paramount Global, which is
Speaker 4: like the streaming application, and did two Super Bowls there well,
Speaker 4: the last last year's Super Bowl. And so that's kind
Speaker 4: of my journey into SRE And why I say it
Speaker 4: is like I feel like SRI is really like my
Speaker 4: my perfect niche in engineering and that is because coming
Speaker 4: from this non traditional background, I've always been the like
Speaker 4: the programmer who is like, sure that new tech is
Speaker 4: really fun and interesting, but like, shouldn't that be something
Speaker 4: we're working on, like on the weekends on our own time,
Speaker 4: Like isn't our job? Like I hate saying this because
Speaker 4: people hate me, but at the end of the day,
Speaker 4: like I'm just like I feel very fortunate to have
Speaker 4: a career in tech, and in the back of my mind,
Speaker 4: I'm always like my job, whether I like it or not,
Speaker 4: Like if I'm working hours, my job is to make
Speaker 4: this company profitable. And while I love programming for fun
Speaker 4: on my own, like, I have a responsibility to the
Speaker 4: business to make make the business profitable, keep it alive.
Speaker 6: Work doing a lot of startups, so I.
Speaker 4: Understand this, and that's where SRI really fits in because
Speaker 4: it's like a lot of roles. Yes, you're accountable to
Speaker 4: the business, but I feel like in an SR role
Speaker 4: through we can get into like slas, slis SLOs, but
Speaker 4: the slas like you are accountable to the business stakeholders
Speaker 4: and that is your overarching goal. So basically, in a nutshell,
Speaker 4: SA site reliability engineering. I also call it like production
Speaker 4: readiness engineering. It is your task to keep the application
Speaker 4: running optimally for as as much up time as possible.
Speaker 2: So what I heard was that you at MPM had
Speaker 2: so much work and we're doing such a great job
Speaker 2: that they're like, here's more work. Be responsible for the
Speaker 2: success of the business and not just solving tickets and
Speaker 2: pushing out futures.
Speaker 4: No, but honestly, truly, like my manager there, he was
Speaker 4: absolutely amazing, as were a lot of the people that
Speaker 4: I worked with, absolutely brilliant, talented people. And I don't know,
Speaker 4: I'm like distributed systems nerd. Like on the weekends, I
Speaker 4: like to watch YouTube videos of distributed systems interviews, Like
Speaker 4: I don't know why, this is very interesting to me,
Speaker 4: but I've always like just gravitated towards that sort of thing.
Speaker 2: So you don't have to shame yourself for that. I
Speaker 2: think lots of us on the weekend, Yeah, we're watching
Speaker 2: interviews and other tech things. Yeah, for sure.
Speaker 4: Whenever there's like a big outage of like a big
Speaker 4: tech company, I'm always like reading the post mortems and
Speaker 4: trying to talk to the like talk about them with
Speaker 4: my husband, and he was he's just like he tries
Speaker 4: to act interested, but he's just good for He's like,
Speaker 4: I love how nerdy you are, Like, okay, I'll just
Speaker 4: talk to myself that.
Speaker 1: You've got a really I think that's a super interesting
Speaker 1: point where you talked about you were working for working
Speaker 1: out on JavaScript development and then you went over to SRE,
Speaker 1: And I think that's really important skill to have for
Speaker 1: that because, like as the SRE, like it's not just
Speaker 1: about the infrastructure or the data dog metrics or whatever,
Speaker 1: like a lot of times you've got to dig into
Speaker 1: the code and discover like what's actually going on here?
Speaker 1: And so how how do you feel like those web
Speaker 1: development skills set you up for success as an SRE.
Speaker 4: Yeah, that's a really good question, and I it's a
Speaker 4: common question I get from people who are also interested
Speaker 4: in SRI because and I also feel like, you know,
Speaker 4: backing up a little bit SRE. I know, Warren mentioned
Speaker 4: like the Google sr book, but I also feel like
Speaker 4: this focus on SRI really came about via micro services buzzword.
Speaker 4: I hate saying them, but.
Speaker 1: It is what it is.
Speaker 4: But so to kind of answer your question there, I
Speaker 4: feel like the teams that I've been on not necessarily MPM,
Speaker 4: but paramount specifically, they had a lot of like systems engineers.
Speaker 4: Like the team was very system engineer heavy, so a
Speaker 4: lot of these people who like worked in data centers
Speaker 4: and those are all obviously very valuable skills as an SR,
Speaker 4: but where they were really lacking was like the programming
Speaker 4: side of things application development side of things. And I
Speaker 4: feel like to have a really good SRA team, you
Speaker 4: do need a mixture of both and you can really
Speaker 4: like learn from each other. So in the SR, like
Speaker 4: in SR roles that I've been in, I am doing
Speaker 4: some programming nuts. I mean, you need to be able
Speaker 4: to debug the program. You're also doing some programming in
Speaker 4: you're doing like scripting. A lot of SR, I don't
Speaker 4: think people realize is a lot of like cashing at
Speaker 4: the edge and so you're doing a lot of custom
Speaker 4: logic that gets deployed to your CDNs and things like that.
Speaker 4: So it might not be as intensive as like building
Speaker 4: out a future and stuff like that, you still need
Speaker 4: those programming concepts to write that kind of code and
Speaker 4: then also to work with the developers because you know,
Speaker 4: for better or worse, there is like that's like the
Speaker 4: that's the telltale like thing that people say about SRI
Speaker 4: is like that push and pull between the engineering department
Speaker 4: because they have a vested interest in getting their stuff
Speaker 4: out to production and then SRI has a vested interest
Speaker 4: in keeping the system healthy and functioning.
Speaker 2: Yeah for sure. I mean you did mention that it
Speaker 2: could be different in different places. So like from your experience,
Speaker 2: what has being an SRI really met? Like is there
Speaker 2: a standard day? And I know that's a terrible question
Speaker 2: for asking you know, any sort of engineering technical person,
Speaker 2: but you know some some expectations around what the role
Speaker 2: is that you were doing both at MPM and Paramount.
Speaker 6: Yeah.
Speaker 4: So MPM obviously like a very it was a relatively
Speaker 4: small team. We just we had the SR team and
Speaker 4: there was a lot of like I said, it was
Speaker 4: cross functional, so we're with building out features, but a
Speaker 4: team was like a cross functional team where we had
Speaker 4: a platform engineer, we had SR infrastructure engineer, we had
Speaker 4: a application developer, and all working together to get something
Speaker 4: out to production. And like the SR side of things,
Speaker 4: there would be like I was saying, I talk about
Speaker 4: SR in terms of like production readiness, so making sure
Speaker 4: that this feature is ready for production, if there are
Speaker 4: like dashboards that need to be made, making sure that
Speaker 4: those are in place so that we can properly monitor
Speaker 4: when it goes to production, making sure that you have
Speaker 4: the proper resources for the machines that it's going to
Speaker 4: be running on, things like that. At Paramount, you know,
Speaker 4: this is a much larger MPM, has a very large scale,
Speaker 4: but it was extremely bursty. And when I say like
Speaker 4: extremely bursty, like the traffic would spike, but it would
Speaker 4: be very short lived. At Paramount, similar but not quite
Speaker 4: to that extent like birsty, as in like you're going
Speaker 4: to see a high rush of traffic when a large
Speaker 4: event kicks off, It'll stay relatively high, but it kind
Speaker 4: of like starts to taper off as the events go
Speaker 4: down and things like that. But Paramount SRA like a
Speaker 4: larger SR teams, it's usually segmented into different departments. So
Speaker 4: you have like an infrastructure focused department, you would have
Speaker 4: like a devsec ops because there's a lot of security
Speaker 4: that goes into SRE, and you would.
Speaker 6: Have like an observability monitoring team.
Speaker 4: I feel like observability and monitoring is where you hear
Speaker 4: a lot of like focus on SRE for sure, but
Speaker 4: it is definitely like segmented into different teams, and it
Speaker 4: is very different at different places, so.
Speaker 2: You spend all your time looking at graphs.
Speaker 4: That's what I when I was more on the infrastructure
Speaker 4: side of things. But yes, like we were heavily with
Speaker 4: like observability team to make sure that the dashboards are
Speaker 4: in place and they have the data that you need
Speaker 4: and everything sod that properly.
Speaker 2: That sounds like the go between, like when get the
Speaker 2: application metrics into some place that different team owns, and
Speaker 2: then when that team exposes a problem, you're then have
Speaker 2: to ferry that back to the application team to tell
Speaker 2: them about the issue that they caused in production.
Speaker 5: Yeah, and that's.
Speaker 4: Where like what Forrest was saying, it's complicated what.
Speaker 3: So? Uh?
Speaker 2: Will and I had a little joke going on before
Speaker 2: the stream started, we forgot to end the joke, and
Speaker 2: the joke the joke basically ended where I decided to
Speaker 2: change his moniker in the in the stream that uh
Speaker 2: that that amy only only you can stream only you
Speaker 2: can see no one else, like none of the none,
Speaker 2: none of the audience will be able to see that. Will.
Speaker 5: It's Will, I'm so sorry.
Speaker 1: No, it's hilarious. It's great because well played Warren, well played.
Speaker 6: You look like a forest.
Speaker 1: But well, that is how the joke started, is because
Speaker 1: like Warren is asking me something and I was like, dude,
Speaker 1: I don't know. I just feel like Forrest Gump because
Speaker 1: I just wander around places in my life and great
Speaker 1: shit happens. And then people were like, how did you
Speaker 1: do that? And like I don't know. I was just
Speaker 1: standing there.
Speaker 4: Okay, Will, Will, I'm so sorry. I feel you got
Speaker 4: me good, thank you. And now I've lost my train
Speaker 4: of thought.
Speaker 6: A little bit.
Speaker 4: But too, I think what I was about to say
Speaker 4: is like there's a fine line because obviously it doesn't
Speaker 4: make sense for the SRI to be the person that
Speaker 4: debugs the code, but in a perfect scenario, ultimately, like
Speaker 4: the sort of thing that probably should happen is SRI is.
Speaker 4: Usually sometimes you have like a knock team who's kind
Speaker 4: of like the first line of defense that does like
Speaker 4: a smoke test, like, okay, we got an alert, we
Speaker 4: got paged?
Speaker 6: Is the application? Can I reach it?
Speaker 4: Like?
Speaker 5: Can I just go to my browser and reach it?
Speaker 6: Like is it up?
Speaker 5: Is it hard down?
Speaker 6: Or is it is latency?
Speaker 4: You know, starting to go down that sort of thing,
Speaker 4: And the knock team is usually the first line of
Speaker 4: defense there. If the KNOP team deems it like okay,
Speaker 4: something is awry here, then they'll usually.
Speaker 6: Page SRI team.
Speaker 4: So SRI team kind of usually you'll have like playbooks
Speaker 4: in place to do like a sanity check of like
Speaker 4: jump on one of the Kopernettes pods, you know, kind
Speaker 4: of see what's going on? Are these pods airing something
Speaker 4: like that. But ultimately what should happen is there should
Speaker 4: in my opinion anyways like a close relationship with SRI
Speaker 4: and the development team that it's clear like we have
Speaker 4: an environment in this micro services system where we can
Speaker 4: do a safe roll back, and so what typically would
Speaker 4: happen at least in my opinion, my role like I
Speaker 4: would deem like okay, and I have a rough understanding
Speaker 4: of like what the feature is, what's the impact because
Speaker 4: there could be a business impact of rolling back. Ultimately
Speaker 4: we want to make that would when I say business impact,
Speaker 4: like you have some sort of like feature for Black
Speaker 4: Friday and it's peak traffic and this feature is like
Speaker 4: driving revenue, so there's like a but it's also like
Speaker 4: causing issues for customers, So you need to kind of
Speaker 4: make the decision. And this is where the stress gets
Speaker 4: high of like what's the financial trade off ultimately here
Speaker 4: like to this business person, like is it honestly like
Speaker 4: it will bubble all the way up like through the
Speaker 4: organization to like the CEO of the company, and you
Speaker 4: need to make the decision of like what's the what's
Speaker 4: the lesser of the financial impacts here? But long winded
Speaker 4: answer like sorre should have confidence from the engineering team
Speaker 4: that it's safe to roll back and do like an
Speaker 4: instant roll back. And it's also then helpful as an
Speaker 4: sary if like, let's say, a lot of times you
Speaker 4: will get paged in the middle of the night, and
Speaker 4: it's a large organization and sometimes sometimes you have great
Speaker 4: engineers on your team who you can escalate too, and
Speaker 4: they usually have like a paging rotation also, but a
Speaker 4: lot of times I'm not gonna lie, I was on
Speaker 4: an SR team and it's the middle of the night
Speaker 4: and I page, you know, I'm looking at this pod
Speaker 4: that's crashing and I can see that it's like actually
Speaker 4: like an error in the code, and I page the
Speaker 4: engineering team and.
Speaker 6: What it crickets.
Speaker 3: Just like a group project, Like it's the same Actually
Speaker 3: I have page again in twenty minutes and crickets.
Speaker 4: So I've been in a state where like I am
Speaker 4: just rolling pods all night. When I say rolling pods,
Speaker 4: like restarting pods over and over and over again until
Speaker 4: someone wakes up in the morning.
Speaker 2: Wait, so you're when you say knock like network operations center?
Speaker 1: Is that?
Speaker 2: Is that mostly to manage the physical hardware.
Speaker 4: It's hard for me to say I didn't work. They
Speaker 4: were kind of like our first line of defense at
Speaker 4: some of my jobs, and it works super closely with them.
Speaker 6: But yeah, those are.
Speaker 4: Typically the people that were like the hard like they
Speaker 4: were working in the data center, and you know, the
Speaker 4: organization obviously sees like value and kind of transitioning them
Speaker 4: to different roles and things like that.
Speaker 2: So yeah, so you then have to look at a
Speaker 2: lot of application specific metrics, so more on the software
Speaker 2: validation side, and then be that that ferry that bridge
Speaker 2: back from Okay, there's a problem at the hardware level
Speaker 2: that's getting escalated and having to find the application team
Speaker 2: and of course they have no on call rotation ever,
Speaker 2: because they're not accountable for keeping the systems up and
Speaker 2: running right.
Speaker 1: They're just to shift code.
Speaker 4: Yeah, just ship it and hand it over you know,
Speaker 4: but that's where you know close relationship also, and like
Speaker 4: I say saying like I keep going back to this
Speaker 4: like production readiness in it should be that before the
Speaker 4: application team hands over something like if saying like, work
Speaker 4: with the s RE team in advance to make sure
Speaker 4: that if it's a mission critical service in your micro
Speaker 4: service architecture, like that the dashboards are in place, you
Speaker 4: understand the dependencies like a when I say dependencies too,
Speaker 4: like a lot of things that come up in SRE.
Speaker 4: And that's why I like this is just I say,
Speaker 4: nerd out on distributed system stuff. You can see one
Speaker 4: application starting to show some latency, but the actual impact
Speaker 4: is more so like a service downstream, and there are
Speaker 4: different ways of like understanding obviously, like if this part
Speaker 4: of the system is having this percentage of latency, then
Speaker 4: I need to understand that these downstream services are getting
Speaker 4: hit by this other service X number of times it's
Speaker 4: going to start like having this kind of latency. So
Speaker 4: you really have to understand like the entire system and
Speaker 4: understand those dependencies. That's where it helps, Like that's where
Speaker 4: s RE really comes in because when like these application
Speaker 4: teams are kind of like siloed working on their specific service.
Speaker 4: The SR team is more responsible for understanding like the
Speaker 4: trace of a request through the system and understanding those
Speaker 4: downstream effects.
Speaker 2: Well, I mean, you just got into some really deep
Speaker 2: topics there, Like there's a huge complexity with like queuing
Speaker 2: theory and window based you know, back offs there as
Speaker 2: well as like the system effect like actual systems, thinking
Speaker 2: of how one thing triggers another thing, which triggers another thing.
Speaker 2: And I don't remember ever seeing a boot camp that
Speaker 2: would have gone anyone prepared for handling this. And you
Speaker 2: got through this, and now I have I understand you
Speaker 2: were still like being on the spot to actually make
Speaker 2: a business impactful decision for the organization.
Speaker 4: Yes, that's where it gets very stressful. And that's where
Speaker 4: I just I feel like in this kind of role,
Speaker 4: you really need someone who cares and yes, because otherwise
Speaker 4: the company's revenue is on the line, whether that be
Speaker 4: not even like I was saying an example of like
Speaker 4: the Black Friday issue, where like you have to make
Speaker 4: the call of is this shopping cart feature more important
Speaker 4: than the fact that X number of other users can't
Speaker 4: do this other thing that they need to do, versus
Speaker 4: even understanding like the slas and is there like a
Speaker 4: financial obligation that I need to pay my customers if
Speaker 4: X number of things start to go down?
Speaker 2: So did you have like some sort of dashboard that
Speaker 2: listed out every single feature and like how much it
Speaker 2: was supposed to make for the company, and like how
Speaker 2: much the shopping I mean, I feel like NPM and
Speaker 2: paramoun are a little bit weird because it's not really
Speaker 2: like end user shopping car scenarios. I mean, I don't
Speaker 2: really understand paramounts, you know, end user pricing model. I
Speaker 2: know there's like plus right, but other than that, So
Speaker 2: I feel like it's it's even harder to really understand
Speaker 2: what the long term impact is for each one of
Speaker 2: those things that's breaking.
Speaker 4: You know, it's very different obviously at different places, Like
Speaker 4: so I keep going back to the shopping cart example.
Speaker 4: Like I worked at different startups in like the retail industry,
Speaker 4: and although I wasn't on the SR team there specifically
Speaker 4: as more in like an architectural role, so like kind
Speaker 4: of tasked with understanding that I'm working with the demops team.
Speaker 4: But yeah, like in a perfect world, you would have
Speaker 4: dashboard self you make those decisions, but you don't have
Speaker 4: that so you just you have to make the best
Speaker 4: call based on your understanding and you know, escalate to
Speaker 4: the right people if you can. And that's where I
Speaker 4: should really get into, you know, is maybe like shift
Speaker 4: the conversation too to like strategies besides just like reactive strategies,
Speaker 4: because we've talked about like a lot of like reactive
Speaker 4: approaches to things. But part of what SRI is tasked
Speaker 4: with is like how do we make this system more
Speaker 4: resilient by nature of things we can do?
Speaker 2: And I feel like you're in the perfect position to
Speaker 2: think about and sort of ide eight on that. But
Speaker 2: don't you end up with like a lot of pushback
Speaker 2: because that's sort of like a shift left approach in
Speaker 2: the organization with like oh, you know application product teams,
Speaker 2: you know this thing that you're doing that has like
Speaker 2: a high likelyhood that there's going to be a production impact,
Speaker 2: maybe you should do something different. How do you get
Speaker 2: that actually across those teams so they can like start
Speaker 2: making those actual changes because it's like a mindset or
Speaker 2: culture shift for them.
Speaker 4: Kind Of where I'm going with this is more so
Speaker 4: on like the redundancy side of things, like SRI team
Speaker 4: making the decision and it's you have to work with
Speaker 4: like the engineering management leadership to understand and like, you know,
Speaker 4: if we're running in like a Kupernettese environment making that
Speaker 4: do we either do we do multi cloud? Do we
Speaker 4: obviously we do multi region those sorts of decisions, And
Speaker 4: then that's where I get into I don't think a
Speaker 4: lot of people necessarily realize, like I was saying, how
Speaker 4: valuable like content delivery is in this because just by
Speaker 4: nature of having as much as you can cashed and
Speaker 4: distributed outside of like before the request even gets to
Speaker 4: whether it's like your physical data center or or a cloud,
Speaker 4: how can we like offload some of that traffic? Because
Speaker 4: I feel like a lot of these systems are just
Speaker 4: the fallover without that. And I know we mentioned it
Speaker 4: like at the beginning of the episode, and maybe I'll
Speaker 4: like touch on it more at the end. But one
Speaker 4: thing that's been very interesting for me to like sit
Speaker 4: back and watch is like Jenny I is.
Speaker 6: Saying that word it is, it.
Speaker 5: Is what it is like twofold.
Speaker 4: First off, like my heart goes out to s on
Speaker 4: their sres who work in environments where they have like
Speaker 4: developers that are just what this whole vibe coding thing, Like,
Speaker 4: I don't think people realize how much like these lms
Speaker 4: are hallucinating and producing like content that is just garbage,
Speaker 4: absolute garbage soup.
Speaker 1: Poor one out for the SR supporting vibe coding is
Speaker 1: what you're saying.
Speaker 2: Yeah, we did have some previous guests on the show
Speaker 2: who were like swearing to us that their lms didn't
Speaker 2: ever hallucinate.
Speaker 4: I literally was like, I think I won't say the
Speaker 4: LM because I'm going to get myself in trouble. But
Speaker 4: I was like asking, like going back and forth with
Speaker 4: one of them earlier this week, like writing stuff, and
Speaker 4: I asked it to revise it, and it started like
Speaker 4: putting all these like statistics in, and I was like, I.
Speaker 5: Was using a product that allowed me to.
Speaker 4: Incorporate a lot of basically like a rag guy, so
Speaker 4: I could incorporate like a bunch of external sources. And
Speaker 4: I was like, there's no way those statistics are in
Speaker 4: those sources, like because I know the data that I added.
Speaker 4: And I asked it, like where did you get these statistics?
Speaker 4: And it's like, you're right, I made them up. I'm sorry.
Speaker 2: At least you've got a conclusive answer there, because We're
Speaker 2: seeing this a lot more with seoed articles today, where
Speaker 2: not only are they being generated by llms, but the
Speaker 2: links that they go to do not back up whatever
Speaker 2: is in the article, and like so even if a
Speaker 2: human is writing it, it's just some fluff piece. And
Speaker 2: if you go there, it's like, oh, sixty percent of
Speaker 2: attacks are from this particular source, like email is the
Speaker 2: source of all attacks and security. And you go and
Speaker 2: you click on the link and it's just some completely
Speaker 2: made up garbage that's also not researched by some other
Speaker 2: company that nothing to do with the topic whatsoever. So
Speaker 2: can you blame the probabilistic you know, statistical engine that's
Speaker 2: just predicting the next word that is also going to
Speaker 2: pull out links that have nothing to do with the
Speaker 2: topic whatsoever.
Speaker 6: Yes, yeah, you.
Speaker 5: Can't blame it, but it's like it's on us to.
Speaker 4: You know, vet it. But what I wanted to touch on that.
Speaker 5: Very briefly was just basically, like I read.
Speaker 4: Something this morning, like the percentage like there's a direct
Speaker 4: correlation between these companies that are allowing like more AI
Speaker 4: assistive like developer stuff and outages. So my heart, there's
Speaker 4: I'd have to like I think I screenshotted it on LinkedIn,
Speaker 4: but there was like it was a lot, and it's
Speaker 4: just in the back of my mind.
Speaker 6: So there's that side of things.
Speaker 4: And then there's also just like these like you know,
Speaker 4: open Ai and all these companies like pushing out it's
Speaker 4: like a race to get stuff out to production faster,
Speaker 4: and there's like that. I think last year just the
Speaker 4: number of outages, like every time I would go to
Speaker 4: chat tipt I think like almost like a week, I
Speaker 4: was like half the time is down.
Speaker 2: I think the jury is really out on the numbers.
Speaker 2: I think we've concluded two things, and whether or not
Speaker 2: people are willing to listen to those is a separate topic.
Speaker 2: You are trading quality or speed. That is, that is
Speaker 2: the trade off, And so you know, I think there
Speaker 2: are a bunch of there are a bunch of good
Speaker 2: articles recently by people who work at some of these
Speaker 2: You say you don't like the word jen Ai. I
Speaker 2: really hate the word agentic. That's that's mine companies that
Speaker 2: they themselves are not using their own LM to produce
Speaker 2: the code, right, And so you know, I see these
Speaker 2: CEOs say oh yeah and stand up and be like, oh,
Speaker 2: our company like twenty five percent of all the source
Speaker 2: code we write is by you know, some sort of
Speaker 2: LM And I'm like, what do you what are you
Speaker 2: going to do about that risk? You know you're gonna
Speaker 2: decrease that in the future.
Speaker 4: Yeah, I should say, like I'm not opposed to these tools,
Speaker 4: but they need to be used responsibly and for better
Speaker 4: or worse, like humans, Like it's our nature. Like that's
Speaker 4: what like the famous like programming quote, like we're lazy,
Speaker 4: Like a lazy person makes a good programmer because they
Speaker 4: want to automate things. So like there's a lot of
Speaker 4: value in these tools, but you hands down need to
Speaker 4: use them responsibly and be able to use them, like
Speaker 4: with actual knowledge behind it. Like I mentor a lot
Speaker 4: of developers and like you know, they're just they're wanting
Speaker 4: to get so done. And I'll see like this code
Speaker 4: that they wrote, and I'm like that that I know
Speaker 4: where you gotta from.
Speaker 6: That's not right.
Speaker 4: I don't know why it's telling you to like install
Speaker 4: Python packages in.
Speaker 6: Your own application, but this is not right.
Speaker 4: Yeah anyways, Yeah, but.
Speaker 1: On a side note, I'm really admired that you got
Speaker 1: those Python packages to work inside of no js so.
Speaker 2: Well. It just comes to the foreign function interface and
Speaker 2: you know, you just shell out to that, no, no
Speaker 2: big deal, and your application, you know, just multiple programming language.
Speaker 2: You know, what's what's the big deal? It's all it's
Speaker 2: all simply under the.
Speaker 6: Hood, exactly. It's all one since but doesn't matter.
Speaker 2: Right for now, for now.
Speaker 1: So I want to come back to talking about playbooks,
Speaker 1: because you mentioned those and I got excited. But I
Speaker 1: think like an important thing to hang the playbook conversation
Speaker 1: on is at talking about being an sr AT scale,
Speaker 1: because like being an sr AT a small company versus
Speaker 1: being an sr AT an enterprise, I think are quite
Speaker 1: possibly two completely different career fields. And and so how
Speaker 1: did you address like the scale of of applications you
Speaker 1: were dealing with.
Speaker 4: That's a good question too. I think it really so
Speaker 4: like talking about this like micro service system where a
Speaker 4: lot of people usually are at right now, typically everything
Speaker 4: is like a trade off, and that's like a handwaybe answer,
Speaker 4: but it's true. And so like when we go back
Speaker 4: to like the production readiness stuff, I think it's like
Speaker 4: helpful to understand like a like a process of like
Speaker 4: kind of rating these micro services. Like it's just like
Speaker 4: tier one tier two, tier three, Like like an a
Speaker 4: system is probably going to be like a tier one system,
Speaker 4: whereas if you have like a recommendations engine that's running
Speaker 4: things in the background, that's more of like a tier
Speaker 4: three system because critical functionality still works. Check out is
Speaker 4: going to be obviously a tier one system something like that.
Speaker 4: But there's a lot of things to consider, Like I
Speaker 4: feel like, especially like for people that are getting into
Speaker 4: this kind of role, it's important to understand like the
Speaker 4: traffic patterns, Like if you're working in like a small startup,
Speaker 4: you're accountable to your customers, like maybe just during like
Speaker 4: business hours, like a banking application or something like that
Speaker 4: is not going to be as critical as an application
Speaker 4: that's used internationally. Things like that, those are like does
Speaker 4: that kind of answer your question?
Speaker 6: Like things to consider, Yeah, for sure.
Speaker 1: And then tying it back to playbooks, like there's a
Speaker 1: certain level of scale where you just can't be familiar
Speaker 1: with all of these systems and you have to rely
Speaker 1: on playbooks. So what are some of the strategies that
Speaker 1: you've seen to making sure that you have an accurate,
Speaker 1: up to date playbook when you need it.
Speaker 6: Yeah, up to date.
Speaker 2: Everything is legacy as soon as you write it. Like
Speaker 2: as soon as you write something down, it is out
Speaker 2: of date. That code is already wrong as soon as
Speaker 2: it's released.
Speaker 4: That Yeah, So that's I'm going to go back to.
Speaker 4: Like building out an S OR team is you need
Speaker 4: technical skills obviously, but you really need people who take
Speaker 4: ownership and care. Like we're talking about the playbooks. Like
Speaker 4: I've definitely been at companies where I will get I'm
Speaker 4: brand new.
Speaker 6: I'll get Paige.
Speaker 4: I go to the playbook and I see that like
Speaker 4: the playbooks can get it hasn't been updated in five years,
Speaker 4: and I'm like, you know, shoot, crap.
Speaker 6: Like what do I do? Like I'm getting Paige.
Speaker 4: Usually, like when you're Paige, it will point you to
Speaker 4: the playbook and it's not there. So, you know, the
Speaker 4: best way that I've seen people tackle this is like ownership.
Speaker 4: Someone needs to own these playbooks. Somebody if a if
Speaker 4: A system is like a Tier one or a Tier
Speaker 4: two system, like this is part of this, like production
Speaker 4: readiness checklist. Like before before the SRI is okay with
Speaker 4: deploying this and like a lot of times, like company
Speaker 4: like the the SR team is they're not really the
Speaker 4: gatekeeper because a lot of these companies, like the developers,
Speaker 4: have the ability to ship themselves, but there are obviously
Speaker 4: consequences if they ship something and it crashes and and
Speaker 4: that doesn't completely come that that is like a shared ownership.
Speaker 4: But having there needs to be ownership of these playbooks,
Speaker 4: and that's usually done by the s RE team. Typically,
Speaker 4: you know, you will get the leadership knows when something
Speaker 4: is very critical, and good leadership will make sure that
Speaker 4: these teams are communicating on like a regular cadence. I'm
Speaker 4: big on like these regular cadences, not necessarily because meetings
Speaker 4: kind of suck, but they are important for communication.
Speaker 2: I like that you put the responsibility of the playbooks
Speaker 2: on the s RE team. There's actually a debate that
Speaker 2: my CEO and myself have been talking about a bunch
Speaker 2: where if it's an artifact that gets thrown over the wall,
Speaker 2: then it's not going like you can't it doesn't contain
Speaker 2: knowledge in a way it contains They're usually actionable things,
Speaker 2: and so since the knowledge is there, you won't know
Speaker 2: how to adapt to a playbook when you get to
Speaker 2: a new scenario that's not encountered before. Right, And most
Speaker 2: of the problems that we find in systems that we
Speaker 2: automate are only problems that we haven't seen before.
Speaker 4: And I will say too so when I say like
Speaker 4: having accountability and ownership, like that's where for better or worse,
Speaker 4: everybody hates on call schedules, but those on call schedules
Speaker 4: do serve as kind of like a backpropagation of like
Speaker 4: if somebody is on if you're on an on call
Speaker 4: rotation and you're getting paid frequently, like you have a
Speaker 4: vested interest in stopping that because if it gets out
Speaker 4: of hand, it's just a huge snowball of you know, obviously,
Speaker 4: like you you're starting to like your sleep is interrupted.
Speaker 4: So and for better or worse, like people will be like, oh,
Speaker 4: you know, you had a rough night, take it easy
Speaker 4: during the day.
Speaker 6: Yeah right, that's not.
Speaker 4: You're still getting up and doing your usual hours, but
Speaker 4: you're just like I'm dead. So there's a vested interest
Speaker 4: in in like sharing that ownership of the on call rotation.
Speaker 4: And if you're getting paid constantly, like you're going to
Speaker 4: want to make sure that your teammates have the playbooks
Speaker 4: in place. And you're like, I just had a huge
Speaker 4: outage and these are the steps that I took to
Speaker 4: remediate this these are the things that were helpful. So
Speaker 4: after my on call rotation, I'm going to go in
Speaker 4: and update the playbook and make sure that the steps
Speaker 4: that I took are there so that maybe there's like
Speaker 4: more junior members on the team they also know and
Speaker 4: things like that, because usually too and like these kind
Speaker 4: of environments that you'll have like multiple tiers there, so
Speaker 4: there's a knock. But then even within s RE, like
Speaker 4: I think it's helpful to have like multiple tiers of
Speaker 4: SRY support, so you have like more senior level sries
Speaker 4: and then more junior level esteres and like maybe maybe
Speaker 4: during the day you would page more junior SRY or
Speaker 4: something like that, whereas a senior is around to step
Speaker 4: in right away, but you want to have stuff in
Speaker 4: place for it makes sense.
Speaker 2: What I'm hearing is you're a huge proponent of these
Speaker 2: incident management tools that are generating playbooks dynamically on the
Speaker 2: fly using some sort of lum please a lot of so.
Speaker 6: Much reviewing them.
Speaker 4: That's fine by me, but like, yeah, these lms are helpful,
Speaker 4: but they are they are not the end all, Like
Speaker 4: that's not the end.
Speaker 5: Of the road.
Speaker 1: You just gave him my next startup idea, Warren, I
Speaker 1: mean you have to compete with some of our past guests,
Speaker 1: I think, who are already already promising h dynamic run
Speaker 1: books based off I mean, there's a thing I think
Speaker 1: Sentry does, and I think there's a couple other tools
Speaker 1: now that they have your source code or at least
Speaker 1: you know, and then they have the stack trays from
Speaker 1: the error and the actual error message, and they use
Speaker 1: that to automatically propose a pull request into your get
Speaker 1: repository that supposedly fixes the problem so that someone can
Speaker 1: review and improve it.
Speaker 2: And you've got to know that at three am, you
Speaker 2: are just going to click improve.
Speaker 6: Yeah, yeah, that's yeah.
Speaker 4: All those tools, Like I said, I think they're helpful,
Speaker 4: but they need to be used responsibly and with somebody
Speaker 4: who is actually like a human being with background that
Speaker 4: says yeah your name.
Speaker 1: Yeah. I think we're still discovering, like what the rules
Speaker 1: of responsibility are. Like I feel like we're learning quickly,
Speaker 1: but we're still learning, you know, some of those being
Speaker 1: like you have to give it very discrete tasks, you know,
Speaker 1: ask it to do one thing so that the result
Speaker 1: that comes back to you is something you can actually
Speaker 1: parse in your head. And you know, don't give it
Speaker 1: something that you don't know how to do, because then
Speaker 1: you have no way to check its work. Or another
Speaker 1: one that I use that I really like is treat
Speaker 1: it like your own personal intern or junior developer. You know,
Speaker 1: you wouldn't like hire an intern and then say, you know, hey,
Speaker 1: go architect this four tiered micro service for us. It'll
Speaker 1: be due by Friday.
Speaker 2: Oops. I mean you're onto something there, will I will
Speaker 2: say that maybe it's just forcing us to finally think
Speaker 2: about concretely how human should actually work together effectively. And
Speaker 2: I you know, in the last you know what is
Speaker 2: the year twenty twenty five, we haven't figured out how
Speaker 2: to do that correctly, and now we're throwing in a
Speaker 2: tool into the next which actually requires us to do
Speaker 2: that work. I'm going to guess it's going to be
Speaker 2: like another two hundred years before we got we got that,
Speaker 2: you know, actually figured out how to optimally communicate one
Speaker 2: human being.
Speaker 3: I'm telling you, I have a teenager, and like I
Speaker 3: would just like to point out that we have been
Speaker 3: peopling for millions of years and we still do not
Speaker 3: have a good way to make the teenagers not really
Speaker 3: really dumb Okay, like just it's never gonna happen. It's
Speaker 3: never gonna happen.
Speaker 2: Millions is a bit long. I'll give you like four
Speaker 2: hundred thousand or so.
Speaker 3: But I.
Speaker 2: Do definitely accept that argument that you know, but you know,
Speaker 2: acceleration of evolution, so maybe maybe we'll get there faster
Speaker 2: this time.
Speaker 1: Right, Moore's law for humans, that's a thing, right, Yeah, Yeah, I.
Speaker 2: Really appreciate Moore's law. What I don't appreciate is people
Speaker 2: saying that Moore's law applies to things that it doesn't
Speaker 2: apply to. I mean, I totally agree that the principle
Speaker 2: by what is it correlation doesn't necessarily imply causation. Although
Speaker 2: you know, you look at lots of things and they
Speaker 2: do double at you know, some rate. That's but people
Speaker 2: get more law wrong a lot. They apply to things
Speaker 2: that don't make sense. It is literally just the size
Speaker 2: of the transistors will reduce by half every eighteen months.
Speaker 2: That's that's it. That's the whole law. It doesn't apply
Speaker 2: like statistically to anything else. Now we do see doubling
Speaker 2: and size reduction and other things definitely, like dies on
Speaker 2: a chip and et cetera. But you know, there's like
Speaker 2: an interesting thing. Does it apply to these new plastic
Speaker 2: chips that I was China producing now that don't use
Speaker 2: silicon I don't remember the material and that are supposedly
Speaker 2: like half or a tenth of the size, you know,
Speaker 2: does Moore's law apply there too?
Speaker 1: I have no idea.
Speaker 2: I was just trying to make a joke, okay for us.
Speaker 3: I wanted to backtrack just like a little bit and
Speaker 3: point out Amy that I really like your kind of
Speaker 3: go gettedness, I guess with understanding actually what the business needs.
Speaker 3: Because I work with a lot of people and especially students,
Speaker 3: and they just have no idea, like no idea like
Speaker 3: what it is, like what is supposed to be the
Speaker 3: end result of this kind of like process that they're doing.
Speaker 3: And I think it's very important. I mean it's important
Speaker 3: from like work, but I think it's also very important
Speaker 3: from a career perspective as well, Like would you like
Speaker 3: to maybe get new jobs? Like you should? You should
Speaker 3: understand what's going on at least a little bit.
Speaker 5: Yeah, Like I said, I don't know.
Speaker 4: I just like still to this day feel very fortunate
Speaker 4: to be able to do something that I pretty much
Speaker 4: enjoy every single day. And I just I don't know,
Speaker 4: maybe I just just like too harsh growing up or something.
Speaker 4: But I'm just like I feel like if I'm getting
Speaker 4: a salary, then I should be. There is value in
Speaker 4: pushing back sometimes when you're like senior enough to have
Speaker 4: a level of expertise, like in a professional and respectful way.
Speaker 4: But yes, like, at the end of the day, our job,
Speaker 4: whether we like it or not, is to make this
Speaker 4: company profitable, whether that be features, making sure that users
Speaker 4: have confidence in the service.
Speaker 6: Yeah, sorry, stuff like that, They're.
Speaker 2: Going to say, despite leaderships and a strategy to the contrary,
Speaker 2: I am. I am sort of curious that you have
Speaker 2: any you know, personal strategies for gleaning better insight into
Speaker 2: how the business should work or how a feature that is,
Speaker 2: say technical, transforms into value for the business. Are you
Speaker 2: working with product managers or with someone on the marketing
Speaker 2: and sales team? Are you grabbing information from the internet?
Speaker 2: Like how are you actually figuring this out?
Speaker 5: Like what is and isn't valuable for the business? I
Speaker 5: guess it's for.
Speaker 4: Me personally over my career. It probably depends on the
Speaker 4: domain I'm working in. So I've worked in like very
Speaker 4: like domains of like the construction industry, Like I don't
Speaker 4: have expertise in what these people want obviously, Like I
Speaker 4: like my personality, I want to understand the domain that
Speaker 4: I'm working in so that I can try to better
Speaker 4: understand these types of things. But in that sort of scenario,
Speaker 4: like I am going to lean more on the product
Speaker 4: people now if it's like a dev focused company. You know,
Speaker 4: my own thoughts obviously, like doing this a while, like
Speaker 4: having friends that I work with and like hearing their
Speaker 4: stories that goes into like what isn't isn't valuable? Like
Speaker 4: I'm trying to think of like different scenarios like that
Speaker 4: I've been in. There was definitely one later on in
Speaker 4: my career where there was like this is like an
Speaker 4: SR type thing, so like the security team was extremely
Speaker 4: focused on like getting this tool out because they were
Speaker 4: getting paged based on things that were happening. But the
Speaker 4: tool that they had vetted, while it seemed good, it
Speaker 4: was a very like rush job to get it out
Speaker 4: in time. And so like on my side of things,
Speaker 4: like there was a lot of code that needed to
Speaker 4: be deployed to get form the infant being a little vague,
Speaker 4: so I'll try if I can. That's fair, I can clarify,
Speaker 4: I will, but at the end of the sorry it.
Speaker 2: Works, no, but it works because the more vague you are,
Speaker 2: the more trauma that listeners will have because it will
Speaker 2: relate to their situation. Like I have like three different
Speaker 2: traumas right now, just based off of what you said.
Speaker 2: You know, security teams pushing stuff out, you know, not
Speaker 2: knowing what to do, you know, not well vetted software
Speaker 2: that now everyone is dependent on, like you know, not
Speaker 2: a short number of times.
Speaker 4: Yeah, So like and I have, like in this particular scenario,
Speaker 4: like a really close relationship, like really got long well
Speaker 4: with the team that wanted to push this out. In
Speaker 4: the ser side of things, I keep saying, you have
Speaker 4: to understand like the tier one, Tier two, Tier three,
Speaker 4: and this was getting deployed to like tier one, So
Speaker 4: this is like getting.
Speaker 6: Deployed at the edge. So if this is wrong, like.
Speaker 4: There's no like the quest the request doesn't go through,
Speaker 4: like it doesn't even it's not even like a latency issue,
Speaker 4: like it's it's dead. Yeah, it's I don't know. I
Speaker 4: see Lauren like shaking his head.
Speaker 2: So I was gonna say past trauma, like actually will
Speaker 2: and I will, and I did an episode last year
Speaker 2: about how to handle scaling around the holidays, because you
Speaker 2: know it's a time, especially for companies that do e
Speaker 2: commerce et cetera, anything with orders, there is a huge
Speaker 2: spike and how to be prepared for that. And it's
Speaker 2: sort of interesting that if you break down the systems
Speaker 2: thinking model you brought it up, there is this perverse
Speaker 2: incentive where if you have a deadline, that you are
Speaker 2: more likely to rush to meet that deadline, which means
Speaker 2: that you cut more corners, which means the thing is
Speaker 2: more risky. And so if you create a deadline or
Speaker 2: a code freeze to prevent risky code from getting into production,
Speaker 2: you are actually encouraging the exact thing that you are
Speaker 2: trying to prevent.
Speaker 4: So and like also on that end, and this is
Speaker 4: where like it, I guess it does like you start
Speaker 4: to like traumatic events and you that is usually the case.
Speaker 4: I've also seen the case of we do a code
Speaker 4: freeze and a system doesn't get touched for six months,
Speaker 4: maybe even a year, and then you decide that you
Speaker 4: do want to deploy like a new feature, and boom
Speaker 4: it's down and hard down because nobody has touched it
Speaker 4: in a year. And so like this certain situation that
Speaker 4: I ran into months we had like a reindexing job
Speaker 4: and there was so much data to reindex that what
Speaker 4: that the machines that it had been running on could
Speaker 4: no longer support the reindex process. So we're like screwed
Speaker 4: at this point. So yes, so you have to wait,
Speaker 4: and there's trade offs in all regards, and as I sorry,
Speaker 4: like it's just really your job to try to understand
Speaker 4: like not even like what's the perfect scenario, but like
Speaker 4: what's the least of like the evils here?
Speaker 2: He dos actually is a really interesting guide for resilience engineering,
Speaker 2: and one of the things that they talk a lot
Speaker 2: about is what happens when there is like one or
Speaker 2: two points of failure, what actual new systems start coming
Speaker 2: into play, What does the request volume start to look
Speaker 2: like versus the nominal state? And you mentioned cash is
Speaker 2: at the edge, and I think one of the most
Speaker 2: common scenarios is why do you add a cash well
Speaker 2: because you're trying to reduce the load on your system,
Speaker 2: which means that you create the ability to create higher
Speaker 2: load on your system to hit the cash and as
Speaker 2: soon as the cash you know, drops or gets busted
Speaker 2: because you're using something like valky because no one's using
Speaker 2: Reddus anymore. Of course, which isn't designed to be persistent.
Speaker 2: It's going to drop at some point, which means you're
Speaker 2: going to get a lot of load to your system
Speaker 2: without going through the cash and it's going to cause
Speaker 2: a hard failure at that point, and how are you
Speaker 2: going to recover? And so it sounds great to add
Speaker 2: a cash in, but then you're gonna have to deal
Speaker 2: with this quite critical scenario where you are just instead
Speaker 2: of being able to handle any number requests, you're going
Speaker 2: to be able to handle nothing.
Speaker 4: Yeah, back to like what you're saying the distributed system stuff,
Speaker 4: Like I in my mind you brought up like single
Speaker 4: point of failure and it's just like the nature of
Speaker 4: how things work, like you're always going to have a
Speaker 4: single point of failure. And it's not so much like
Speaker 4: how do we get rid of this single point of failure,
Speaker 4: because I don't even think that's possible, because you're going
Speaker 4: to have like traffic management at some point, Like what
Speaker 4: if the traffic management fails? It's more so in my mind,
Speaker 4: like what is what system seems to be the most
Speaker 4: resilient and that's where we want to place this single
Speaker 4: point of failure. So like usually it is like the distribution,
Speaker 4: Like if you have like a cash distribution, that is
Speaker 4: usually the in my opinion, like your wisest single point
Speaker 4: of failure.
Speaker 2: This is an interesting way of phrasing and I haven't
Speaker 2: heard that perspective before.
Speaker 1: What's your on call rotation look like?
Speaker 4: So it's super different based on the company. I am
Speaker 4: a big fan of companies who are hopefully you work
Speaker 4: at a company that's large enough that they have engineers
Speaker 4: across the globe and so your on call rotation can
Speaker 4: fall within the hours that allow you to uh work
Speaker 4: optimally and not be up all night. But like I said,
Speaker 4: I also firmly believe like everybody should share in the
Speaker 4: on call rotation because it shares ownership and if things
Speaker 4: start to go awry, then you have a vested interest
Speaker 4: in making things better. But the on call rotation like
Speaker 4: is it? It is what it is, and you know
Speaker 4: it can be a little rough at the beginning, but
Speaker 4: it's a great way to learn honestly, like just dive
Speaker 4: in because there's nobody knows everything in the system. Like
Speaker 4: you're going to hit something that probably somebody has and
Speaker 4: hit before.
Speaker 2: When you say everyone, like, what's the size of the
Speaker 2: org uh that you're thinking about there?
Speaker 5: You know.
Speaker 4: I've been in teams where, like my own conrotation honestly
Speaker 4: was like every other week, which is a little rough.
Speaker 4: I've been on teams where it's I want to say,
Speaker 4: like maybe once a month or something like that. I
Speaker 4: feel like that's pretty reasonable. I think it's helpful to have,
Speaker 4: like I said, like the tears of support also to
Speaker 4: like hopefully it doesn't get to this point, but it's
Speaker 4: definitely a real thing. I've seen, like with myself and others,
Speaker 4: where you're on an issue for twenty four or forty
Speaker 4: hours straight and you need to hand that off because
Speaker 4: after a certain amount of time, like you're just your
Speaker 4: brain dead, or like you need to bathe, right, I
Speaker 4: mean I guess like if I think of like military
Speaker 4: or something like, you can go a long time without bathing.
Speaker 6: So maybe that's not the best example. Like you need to.
Speaker 1: Sleep, especially in a remote workforce culture.
Speaker 4: Yeah, like you need sleep to be able to like
Speaker 4: debug things, but there should usually I feel like in
Speaker 4: a proper on call rotation, like a handoff phase, if
Speaker 4: it's been like more than twenty four hours something.
Speaker 2: Like that, yeah, I will. I think follow the sun
Speaker 2: implies that you, like you hand it off to someone
Speaker 2: who's still awake at that time and not you. You
Speaker 2: just stay awake until the sun comes up.
Speaker 4: That that, in my experience, it typically works the best.
Speaker 2: So this is this may be a little bit of
Speaker 2: a tangent, but since you're from the JavaScript Java Jabba podcast,
Speaker 2: I have to ask you preference no JS, DNO or BOND.
Speaker 4: I'm old and boring, so I like nodes still No.
Speaker 4: I've talked to like the Dino team and like I
Speaker 4: I don't have anything against that.
Speaker 6: I just I'm old and boring.
Speaker 2: And I shouldn't say I owe Jos.
Speaker 3: I still like Pearl, so like, I agree.
Speaker 1: I think it's just fitting that she said I like Pearl,
Speaker 1: and the rest of the audio cut out.
Speaker 2: After that, The said part is like it's still recording
Speaker 2: for her, so we'll find out when the episode released
Speaker 2: was She actually said.
Speaker 3: It's only for this podcast, you guys that I have
Speaker 3: so many technical problems, Like I'm fine in all of
Speaker 3: my other meetings.
Speaker 4: It's just this'll be doing something right now.
Speaker 2: I believe you. Jillian.
Speaker 3: That's good.
Speaker 1: I have no comment.
Speaker 3: That's probably for the best quite possibly.
Speaker 2: How do you deal with the complexity of having to
Speaker 2: share so much knowledge with so many people? So the
Speaker 2: more people that are working in solution in an area
Speaker 2: and a team or means there's more things that are
Speaker 2: going to be created, which means there's more things everyone
Speaker 2: will have to be aware of to potentially deal with
Speaker 2: when an on call incident comes up. Is there a
Speaker 2: good metric or litmus test to figure out what the
Speaker 2: maximum amount of stuff is that a team can actually manage.
Speaker 4: Yeah, honestly, that is a very good question, and I
Speaker 4: feel like I don't have a good answer, but now
Speaker 4: that's something I want to go see if I can
Speaker 4: dig into more. But I also say, like how we
Speaker 4: have like these different like tiers of support. It's hard
Speaker 4: if you get into like a more senior role because
Speaker 4: stuff is going to bubble up to you, but it's
Speaker 4: usually helpful. Like in a large team, there's usually even
Speaker 4: like slas to the developer team. So even like a
Speaker 4: lower environment is going to like be held accountable to
Speaker 4: the business to keep a lower environment up in.
Speaker 6: A certain amount of time.
Speaker 4: Like sort of related to your question, like having those
Speaker 4: types of people like work in those environments and that
Speaker 4: helps distribute knowledge of like how these different systems work
Speaker 4: without being tasked with like the actual production environment, and
Speaker 4: then if they do well in those lower environments, and
Speaker 4: then they can kind of move on to a production environment,
Speaker 4: and that helps spread the nolle.
Speaker 2: Pray that's prey. I mean, I think there's a there's
Speaker 2: a corollary here where I often have to advise some
Speaker 2: companies on which is we have like five different mobile
Speaker 2: apps because you know, there's many different providers out there,
Speaker 2: and then there's a website and also web native version
Speaker 2: for your mobile app that isn't like an app version
Speaker 2: but is responsive like and then there's back and that
Speaker 2: goes with it. And the infrastructure is that all one team,
Speaker 2: you know, so everyone is cross functional and understand what's
Speaker 2: going on. Or do you have like ten teams that
Speaker 2: each have the exact same functionality. And I feel like
Speaker 2: the answer keeps on being well, they're both wrong and
Speaker 2: there's no there's no good solution there, and you just
Speaker 2: got to have to deal with the consequences.
Speaker 6: It's awesome.
Speaker 4: I mean, this is why I did startups for a
Speaker 4: long time. But as I've gotten like further into my career,
Speaker 4: I feel like it's hard to make an impact unless
Speaker 4: you've been at the company for really for a good
Speaker 4: amount of time because it the larger the code base
Speaker 4: and like the domain than and you really do need
Speaker 4: that time to understand it, whereas like a startup usually
Speaker 4: like a smaller application, and you can understand it more.
Speaker 4: But like a lot of these like larger companies, they
Speaker 4: have like these huge systems and it takes time to
Speaker 4: understand it.
Speaker 2: That's a really interesting challenge. Then we see in the
Speaker 2: tech industry the average tenure for engineers reducing over time. Yeah,
Speaker 2: does that mean that we're actually more and more incapable
Speaker 2: of building larger systems because people aren't staying at the
Speaker 2: company to be able to diagnose and build more resilient systems.
Speaker 2: Are we still attempting to do that and the systems
Speaker 2: we're building just aren't resilient anymore? Or is this just
Speaker 2: like you see whatever problems are close to you, and
Speaker 2: larger companies with bigger solutions are doing a good job
Speaker 2: at retaining experienced staff that have experience in their own
Speaker 2: solution in order to help solve those challenges.
Speaker 4: It's it's very tricky because yeah, there's like a trade
Speaker 4: off both ways, Like you stay a company long enough,
Speaker 4: like yes, you might kind of have some like siloed
Speaker 4: information and start to not know how other people are
Speaker 4: solving problems, and then that kind of can produce like
Speaker 4: some blind spots in your knowledge. But at the same time,
Speaker 4: like if you don't stay at a place long enough,
Speaker 4: it can be hard to see like how this huge
Speaker 4: system interacts and.
Speaker 6: Be able to.
Speaker 4: Really solve like these harder problems because it takes a
Speaker 4: while to like get the whole domain, the whole system
Speaker 4: in your head. It's a there's definitely like like a
Speaker 4: vested interest I feel like in these companies and like retaining.
Speaker 2: People, well, yeah, for sure. I mean there's the benefits
Speaker 2: to them and not to the individual and a lot
Speaker 2: of times, I mean, I guess, you know, maybe a
Speaker 2: different way of phrasing this is if we look at
Speaker 2: Dumbar's number and ORG is going to be at max
Speaker 2: like one hundred and fifty people, how many years of
Speaker 2: experience working in that company do we project someone would
Speaker 2: a new hire would have to work before they or
Speaker 2: at the point where they are delivering or understanding the
Speaker 2: system sufficiently that one hundred and fifty person ORG has
Speaker 2: created any thoughts on that.
Speaker 4: That's an interesting question too, like how it kind of
Speaker 4: like scales based on the size and the system and
Speaker 4: how long you'd have.
Speaker 2: To be there, but a personal preference, you know, like
Speaker 2: oh yeah, once I'm there, you know, six months, I
Speaker 2: feel like I'm now somewhat accountable for every system or
Speaker 2: a year or two years or something like that.
Speaker 4: It probably this doesn't answer your question, unfortunately, but I
Speaker 4: would say like one of the things that could be
Speaker 4: helpful is like if you start to like segment your
Speaker 4: career working in a similar domain, so some of that
Speaker 4: knowledge is transferable, like whether you're talking about like the
Speaker 4: hyperscaler that you're working on, or if you're more focused
Speaker 4: on like CDM distribution, and maybe that's valuable to other companies,
Speaker 4: whereas like if it's a you know, if it's a
Speaker 4: paylalled type of application, that maybe your CDN experience is
Speaker 4: not as beneficial there.
Speaker 1: I think also when you say one hundred and fifty
Speaker 1: person or you refer into like the entire company or
Speaker 1: just engineering.
Speaker 2: I mean even a subset of engineering potentially, like I
Speaker 2: just like at Dunbar's number, like your teams are going
Speaker 2: to be like two pizza teams for instance, that are
Speaker 2: cross functional. But then there are different types of teams
Speaker 2: and different features within the product or product suite that
Speaker 2: you're delivering, and that can only get up to one
Speaker 2: hundred and fifty. Above that you need to create a
Speaker 2: second org and have them work on a completely different
Speaker 2: feature set with a completely different focus. You know, you
Speaker 2: think of like how in a hyperscale or I'm going
Speaker 2: to use Google Workspace as an example, like email, Gmail
Speaker 2: and drive, right, I can imagine those being separate, completely
Speaker 2: separate orgs for instance, But I would not expect one
Speaker 2: org structure where it's fundamentally accountable for every single product
Speaker 2: in Google Workspace. There's just too much stuff there. So
Speaker 2: that's the part for me that makes the most sense,
Speaker 2: that you can't have more than one hundred and fifty
Speaker 2: people working on the same product because there's only so
Speaker 2: much functional work there, and at a larger size you
Speaker 2: have a communication breakdown. You can't pass the information effectively.
Speaker 2: So that's just sort of the metrics on the math
Speaker 2: that seem to work out.
Speaker 4: Too many cooks in the kitchen, and like I think
Speaker 4: for better where some people have like a vested interest
Speaker 4: in like trying to offer value, but unfortunately some there's
Speaker 4: the values not there.
Speaker 2: Yeah, I mean even to your point of like, well,
Speaker 2: let's have an on call rotation in everyone and say
Speaker 2: the team in the ORG could participate in right, one
Speaker 2: hundred and fifty people means you're on call for your
Speaker 2: product once every three years, right, So that doesn't work out, right,
Speaker 2: So you know if your August fifty people, then you
Speaker 2: get to the okay, once a year, I'm on a call. Well,
Speaker 2: that maybe works out potentially if you have a low
Speaker 2: number of bugs. You deal with real time applications that
Speaker 2: can never really be down, highly resilient, and you run
Speaker 2: you're probably running fire drills during during working hours as
Speaker 2: if there were an incident to know how to respond
Speaker 2: and not just hopefully waiting and never seeing a problem.
Speaker 4: I kind of like, I feel like computer systems like
Speaker 4: mirror a lot of like real life. So whether it
Speaker 4: be like I people who don't understand astory, they're kind
Speaker 4: of like, what in the world do you do? I'm like,
Speaker 4: I'm basically like an emergency room doctor, and like somebody
Speaker 4: comes into the emergency room and my responsibility is like
Speaker 4: keep them alive until the right person can come in,
Speaker 4: and you know, get them into like critical condition, not.
Speaker 2: Even not even the surge end, but you know, high level.
Speaker 2: I understand how how patients work and the sets of
Speaker 2: problems that can happen, and I can direct people on
Speaker 2: the right places.
Speaker 1: Yeah, the wet stuff on the inside and this dry
Speaker 1: stuff on the outside.
Speaker 5: I love it.
Speaker 2: You said, you said nuclear physics. Well I don't think
Speaker 2: you said E M T right right right, Yeah, true, true, true.
Speaker 1: But I do spend not to just qualifies my opinion
Speaker 1: by any means, but I do spend a lot of
Speaker 1: time out in the wilderness, and like the wilderness, the
Speaker 1: wilderness first aid stuff I've been exposed to is pretty
Speaker 1: much that keep the wet stuff on the inside, dry
Speaker 1: stuff on the outside.
Speaker 2: Okay, so now I'm imagining bear grills. I don't out
Speaker 2: back are you know, frequently known on the internet means
Speaker 2: for drinking his own You're unnecessarily.
Speaker 1: But the likes he got, that's the metric.
Speaker 2: You gotta wonder what he was really going for. Was
Speaker 2: he going for, you know, teaching survival skills or was it,
Speaker 2: you know, just to become a paid influencer.
Speaker 1: I'm pretty sure he's got a mortgage to pay.
Speaker 6: Yeah, so.
Speaker 1: Someone who's interested in pursuing a career in s E.
Speaker 1: Give us like your top rundown pros and cons and
Speaker 1: things you'd wish you things you wish you had known
Speaker 1: before ending up here.
Speaker 5: There's a lot of different paths that you can take
Speaker 5: into s E.
Speaker 6: One thing I.
Speaker 4: Didn't really touch on, and I know we're close on time,
Speaker 4: so I won't go into it too much is like
Speaker 4: a performance engineer. That's very important for an s E
Speaker 4: team to do performance testing all these kinds of things.
Speaker 4: That's a huge part of s E. Is like resource allocation,
Speaker 4: and you need performance testing in place to better make
Speaker 4: those decisions. So performance engineering, like I can say, like
Speaker 4: from my background, like coming in from application engineering, there's
Speaker 4: a lot of value there. Could you understand like how
Speaker 4: these micro how these microserver systems.
Speaker 6: Like work together.
Speaker 4: And then like the systems in Ino your background has
Speaker 4: like an ability to debug at like the network level
Speaker 4: really well and things like that, and all of those
Speaker 4: things come in and offer value to an s R team.
Speaker 4: I guess things I wish I would have known kind
Speaker 4: of like we talked about the beginning of the episode,
Speaker 4: I I'm like very much like go go go, and
Speaker 4: like early in my career, everybody was like, you're gonna burn.
Speaker 6: Out, like slow down. I was like impossible.
Speaker 4: And I still say, like I didn't burn out because
Speaker 4: I still absolutely love it. But I really did not
Speaker 4: realize that like it actually did start to like the
Speaker 4: lack of sleep just didn't start to kind of like
Speaker 4: take a toll on my actual health a little bit.
Speaker 4: So like lesson learned to myself is like, be be
Speaker 4: cognizant of like your personality and like your you know what,
Speaker 4: some of your weaknesses might be there, because like for me,
Speaker 4: I absolutely love what I do and I want to
Speaker 4: be able to do this for a very long time.
Speaker 4: So I kind of came to this realization that I
Speaker 4: was like whoa, like if you don't put it, and management,
Speaker 4: like my manager was fine, like he would encourage me
Speaker 4: to do more of it, not like my director like
Speaker 4: same thing, like dude, like you you need to take
Speaker 4: some time off. So like my advice would be like,
Speaker 4: if you're more on that side of the spectrum, like
Speaker 4: know yourself and allow yourself that time because it will
Speaker 4: make you better in the long run.
Speaker 6: Other things.
Speaker 4: I would just say, like if it sounds interesting to you,
Speaker 4: like don't shy away from it because it is I
Speaker 4: feel like a huge there's like a huge surface of
Speaker 4: areas you can tackle. But if I'm always like of
Speaker 4: the mindset like anybody can learn anything obviously, like some
Speaker 4: people are like more technically talented, they come in with
Speaker 4: more experience.
Speaker 6: Those sorts of things.
Speaker 4: But if it's interesting to you, like and you have
Speaker 4: the drive like.
Speaker 6: Go for it.
Speaker 4: Those would be my biggest like two takeaways and.
Speaker 2: Through the power of MS now you now you two,
Speaker 2: everyone can be an expert in whatever topic you know
Speaker 2: you fancy. I mean listening to you talking to me
Speaker 2: about this, it really makes me think. Like you say,
Speaker 2: you really have to care a lot, But caring a
Speaker 2: lot means understanding the business and gives you an edge
Speaker 2: over everyone else who may not care as much. They
Speaker 2: won't give them a drive to really dive in and
Speaker 2: be able to make the right decision. But then there's
Speaker 2: the question that comes up of like if you care
Speaker 2: too much, you're liable to burn out from doing that,
Speaker 2: and you really need to know yourself. And that's a
Speaker 2: tall order I think for a lot of people.
Speaker 4: Yeah, Like it was very it was a challenge for
Speaker 4: me to be like you can't be the hero twenty
Speaker 4: four to seven or like you are not going to
Speaker 4: be able to like sustain this, but there's.
Speaker 2: Just one more fire over there that you know how
Speaker 2: to deal with.
Speaker 4: Oh lord, Yeah, I mean I guess I would say too,
Speaker 4: Like I'm probably at a place now where the thing
Speaker 4: that I did really enjoy is like I did get
Speaker 4: to serve in more of like an engineering manager role
Speaker 4: on the SR team towards the end my last role.
Speaker 4: And you know, everybody is like driven by different things,
Speaker 4: but you can kind of see people in the org
Speaker 4: that have a lot of potential and starting to kind
Speaker 4: of like mentor them and hand things off to them
Speaker 4: and things like that can.
Speaker 6: Be very rewarding and.
Speaker 4: Really like the best thing you can do is this
Speaker 4: sounds like so hand baby, but like fort multiplier, Like
Speaker 4: you know, whether you're an actual manager or in a
Speaker 4: senior role or anything like that, like what can you
Speaker 4: do to help the company and the teammates like fall
Speaker 4: into the pit of success?
Speaker 1: I like that analogy important leadership skill.
Speaker 2: Learn to delegate, Right, you have to.
Speaker 4: Be okay at a certain point in your career with
Speaker 4: like not being the hero, because if you're in that
Speaker 4: kind of role, like sometimes your value is more so
Speaker 4: in enabling others and building out parts of the system
Speaker 4: that like help others fall into the pit of success.
Speaker 4: And if you kind of like are one of those
Speaker 4: people that feels like they always need like the like recognition, like,
Speaker 4: then like leadership type roles might not be the path
Speaker 4: for you because a lot of the recognition is going
Speaker 4: to be like hidden behind the scenes of enabling others.
Speaker 5: Yeah, but it's warm, cuzzy. You like the girl and he.
Speaker 6: Likes it, so.
Speaker 1: I agree with you. But it's a it's a completely
Speaker 1: different high probably not the best analogy in the world,
Speaker 1: but that's the one that just sits in my head.
Speaker 4: It's more so like I would I guess I would
Speaker 4: almost equate it to like delayed gratification, Like you're not
Speaker 4: going to get the like that a girl in the moment,
Speaker 4: but it might come like two years later when somebody
Speaker 4: that you managed comes back to you and be like, man,
Speaker 4: like you taught me this thing and I used it
Speaker 4: today and thank you, and you're.
Speaker 6: Like really good.
Speaker 2: Right. It's interesting that you say that, though, because that
Speaker 2: actually means that some of the most enjoyment you get
Speaker 2: out of it if that's the right word. Is actually
Speaker 2: seeing others execute effectively and seeing back on what you've
Speaker 2: taught them, which indirectly has no impact on the business
Speaker 2: in a way, especially if they leave and go somewhere else.
Speaker 2: So you know, there is this weird paradox there.
Speaker 6: Yeah.
Speaker 5: Yeah, yeah, it's a little of both.
Speaker 6: Yeah.
Speaker 4: For sure, it's helping the business, and hopefully you help
Speaker 4: other people on the team that help the business or
Speaker 4: just go on and do good things themselves.
Speaker 2: I don't know if this is relevant, but this keeps
Speaker 2: coming to my mind in this conversation. There's this SMBC
Speaker 2: Saturday Morning Breakfast Cereal webcomic issue where Superman's like, how
Speaker 2: can I deliver the most value possible? And you know,
Speaker 2: the mayor of the city is like, well, you know
Speaker 2: what actually saving people? Like you're pretty slow at that.
Speaker 2: If we look at it, you know what would really
Speaker 2: work is if we just had more energy and to
Speaker 2: make this, you know, relevant for twenty twenty five, to
Speaker 2: obviously power all of those lms to help people. And
Speaker 2: so can you just turn this one giant crank really
Speaker 2: fast as you can. That's just your whole life just there,
Speaker 2: And like decades later, he's still turning the crack and like,
Speaker 2: that's not a very rewarding experience, but that's what gives
Speaker 2: the most value to UH civilization. And you know, one day,
Speaker 2: the years later, the mayor wakes up and says, you
Speaker 2: know what, actually, we don't need you anymore. We automated
Speaker 2: your job away with nuclear fusion, and now we generate
Speaker 2: a limited energy all the time, basically without doing anything.
Speaker 2: You can just retire.
Speaker 4: Well, hopefully that doesn't happen you kind of You're always
Speaker 4: wanting to invent new ways to make yourself valuable.
Speaker 6: That's part of being in tech.
Speaker 1: I don't see it's running out anytime soon, which is
Speaker 1: good because I've got I've got a mortgage to cover, So.
Speaker 2: I don't know. I hate to have the dissenting opinion here.
Speaker 2: I feel like there is just people making the same mistakes.
Speaker 4: Yeah that's true too, Yeah, the same, the same underlying mistakes.
Speaker 6: Yes, it's history repeating it.
Speaker 1: Yes, so warning, if you could just compile a list
Speaker 1: of those.
Speaker 2: I tried, so I have tried to, you know, write
Speaker 2: down so what happens frequently. I always thought I'd be
Speaker 2: doing engineering, But what I do is I write blog
Speaker 2: posts and I record podcast episodes, and I get triggered
Speaker 2: sometimes while I'm doing other things in my life, talking
Speaker 2: with my colleagues and whatnot, in the communities that I'm in,
Speaker 2: so much so that I feel compelled to have to
Speaker 2: write something. And so there is a list of things
Speaker 2: out there of problems that I've seen and my recommendations
Speaker 2: for it. But some of them are like really nuanced thing,
Speaker 2: Like there's one particular little thing in security that everyone
Speaker 2: seems to run into, and then there's like a forty
Speaker 2: minute conference talk on it or a blog post on
Speaker 2: it that I'm sure no one has ever read.
Speaker 1: Well, it sounds like a really good point. Put all
Speaker 1: those words together into one coherent sentence in the right order. Right,
Speaker 1: That sounds like a really good time to move on picks,
Speaker 1: and maybe you can point someone to some of those resources.
Speaker 2: Uh, I'm not going to plug blog as my pick,
Speaker 2: but I'm happy to put a link for this episode
Speaker 2: for anyone that wants it. Actually, I'll find the Saturday
Speaker 2: Morning Breakfast Cereal episode two and put that. But my
Speaker 2: pick actually is going to be based of our conversation.
Speaker 2: There is a book by Peter Senge called The Fifth Discipline,
Speaker 2: and it's all about systems thinking. And there's this one
Speaker 2: great example in the book about it's a canonical thing
Speaker 2: that I believe it's taught at I think it's Harvard
Speaker 2: Business School, but also at MIT in the economics theory.
Speaker 2: And that's basically, there is a brewery that makes a
Speaker 2: beer and they make enough for a distributor to sell
Speaker 2: the beer to retailers for people to buy it, and
Speaker 2: every retailer sells like your local store sells two cases
Speaker 2: every week. And then in some random week, a new
Speaker 2: pop song comes out and everyone loves the beer, and
Speaker 2: because the band mentions the beer in the song, and
Speaker 2: from that point on, every single retailer just increases the
Speaker 2: number of beers the case they sell by one to three.
Speaker 2: And this causes some ridiculous effects to happen throughout the
Speaker 2: whole ecosystem. The distributors will fall over, the brewery will
Speaker 2: get some massive orders, and basically what ends up happening
Speaker 2: as lots of people will be fired for failing to
Speaker 2: deliver effectively. And it's just such a small change to happen,
Speaker 2: and you can see huge impacts, and I feel like
Speaker 2: it's a really interesting case study of what happens over
Speaker 2: and over again, and lots of organizations and relates out
Speaker 2: to a lot what Amy was talking about in today's episodes.
Speaker 2: Those relevant.
Speaker 1: That's pretty cool. That's called the fifth dimension discipline, fifth discipline, gotcha,
Speaker 1: re Peter sin get yeah? Right on, Jillian, what about you?
Speaker 1: What'd you bring for a pick?
Speaker 3: I don't know. I was going to pick. I'm giving
Speaker 3: a talk next week on HPC, And now it occurs
Speaker 3: to me that I don't know if that's going to
Speaker 3: be like recorded and put any place, So that's maybe
Speaker 3: not my pick. I don't know, like Horizons zero down
Speaker 3: the video game I've been playing, and maybe the talk.
Speaker 3: Maybe the talk too. If it's actually published and recorded,
Speaker 3: we'll see.
Speaker 2: You can always record it yourself on your laptop and
Speaker 2: then you'll have the transcript, you can publish the slides,
Speaker 2: and then you can you know, release it to all
Speaker 2: your faithful audience there.
Speaker 3: Yeah, that's true. I mean I could just help somebody
Speaker 3: record it on my phone, right, Like, I don't know.
Speaker 1: Okay, so we're gonna count on seeing your talk.
Speaker 3: Then, yeah, sure, that's the point. It's supposed to be
Speaker 3: self promotion, like, right, that is what I do.
Speaker 1: Amy. I know you've done this before. What do you
Speaker 1: have for a pick this week?
Speaker 4: See I was debating if I should pick something technical
Speaker 4: or non technical. I guess I will try to break
Speaker 4: it up a little bit. I'm going to pick a
Speaker 4: band that I am like absolutely obsessed with and I
Speaker 4: can't shut up about it, And because other people won't
Speaker 4: listen to me anymore about it, this is a great
Speaker 4: opportunity to share it. My husband is really tired to
Speaker 4: be talking about them and blasting them, so and that
Speaker 4: is sleep token. I don't know if anybody who's ever
Speaker 4: heard of it or heard of them, but I will
Speaker 4: drop a link. I first heard about them like maybe
Speaker 4: like two or three years ago, and they have a
Speaker 4: bunch of new songs out this year, and I am, yeah,
Speaker 4: it's when I've had like a long, stressful day at work.
Speaker 4: I don't know why, Like I listened to them and
Speaker 4: it's like peaceful to me to fall asleep toobe. So whatever,
Speaker 4: maybe other people will like it too.
Speaker 2: What's the genre?
Speaker 6: That's the thing?
Speaker 4: So they are like they're all over the place, like
Speaker 4: I guess traditionally more like metal. They're almost like a
Speaker 4: little bit like ed M, a little bit metal, like honestly,
Speaker 4: like a tiny bit hip hop something like they're just
Speaker 4: like you listen to your song and you're like, oh,
Speaker 4: this is like really relaxing, and then they start screaming
Speaker 4: and then there and then it's like back like a
Speaker 4: hip hop's kind of vibe, and I'm just like, what's happening.
Speaker 2: It's just like you're gonna say, like, yeah, it's like
Speaker 2: it's like heiden or Dominate the Christmas Donkey. I just
Speaker 2: use that music to falls leap that night. I'm just
Speaker 2: like really like, not my personal choice, but uh, you know,
Speaker 2: if it works for you, that's pretty interesting.
Speaker 4: I like metal, so why I absolutely love them, So yeah,
Speaker 4: that's that's going to be my pick.
Speaker 1: That's awesome. I was just as you were saying it
Speaker 1: and you're like, oh, it's so just what I want
Speaker 1: to listen to after a long, stressful day. I was like, oh,
Speaker 1: this would be so great if it's a metal band,
Speaker 1: and then you're like a surprise, guess.
Speaker 4: What I mean. They're not metal in the sense of
Speaker 4: like like I really like this band Motionless and White.
Speaker 4: If people have heard of them, they're not metal in
Speaker 4: that sense. They're like a little more chill than that.
Speaker 4: But yeah, right, on, I'll drop a link before.
Speaker 6: We hang up.
Speaker 1: Cool. Cool, all right, So my pick I switched it
Speaker 1: since we started recording because it's now a relevant topic.
Speaker 1: On Netflix, there is a series called The bear Grills
Speaker 1: Celebrity Hunt, and so it's all of these celebrities who
Speaker 1: are taken to Costa Rica and then they compete, and
Speaker 1: the losers of the competition have to go into this
Speaker 1: area that's like walled off and they have to survive
Speaker 1: in there for one hour while bear Grills is hunting them.
Speaker 1: So they have an hour to either escape the bear
Speaker 1: pit or get caught by bear Grills. And it was
Speaker 1: actually just super fun to watch. And I brought it
Speaker 1: up at work saying, Hey, for our next off site,
Speaker 1: we should go to the bear pit and have bear
Speaker 1: Grills hunt us down.
Speaker 2: Where bear grills will actually be well buttoned.
Speaker 1: I'd be cool with that.
Speaker 2: Yeah, I feel like that may create some sort of
Speaker 2: psychological safety issues for coming back work later.
Speaker 1: Yeah, there's probably a downside to that, but let's not
Speaker 1: focus on that.
Speaker 5: Makes me think.
Speaker 4: My husband, Like, at first I thought I was like,
Speaker 4: what are you watching? But he watches this like it's
Speaker 4: probably like a famous YouTuber people probably know I can't
Speaker 4: think of him, but like he's always out in the
Speaker 4: wilderness like doing things, and my husband loves watching him.
Speaker 4: And initially I was like, this is crazy, but now
Speaker 4: I kind of like it too.
Speaker 5: All Right, he's usually in Alaska.
Speaker 1: There have been a lot of those episodes where my
Speaker 1: kids were watching something like that's stupid. Why are you
Speaker 1: watching wasting your time on that? You know, like two
Speaker 1: hours later, I'm still sitting next to him watching it.
Speaker 1: But anyway, Amy, thanks for being on the show. This
Speaker 1: was a fun chat. Thank you for your insights and
Speaker 1: your expertise and sharing your thoughts on sre Warren Chillian.
Speaker 1: Thank you both for jumping in and co hosting today.
Speaker 1: It's good to see both and for all our listeners,
Speaker 1: thanks for listening.