Mandi Walls: Welcome to Page It to the Limit, a podcast where we explore what it takes to run software and production successfully. We cover leading practices used in the software industry to improve both system reliability and the lives of the people supporting those systems. I’m your host, Mandi Walls. Find me @LNXCHK on Twitter. We’re going to be talking with Murriel Perez McCabe, who is an enterprise customer engineer at Google Cloud. Welcome to Page It to the Limit, Murriel.
Murriel Perez McCabe: Thank you, Mandi. Thank you for having me on. I’m super excited to be here. Our conversation has been super interesting so far, so I’m looking forward to keeping that going.
Mandi Walls: Awesome. To get us going, tell us a bit about yourself. You’ve had a really interesting career. You’ve done a lot of different things. What are you working on now? What’s cool for you?
Murriel Perez McCabe: For the past year, I’ve been here at Google as an enterprise customer engineer. My lineage before that was in this world of starting from the ground level with the IT systems administration, help desks of all kinds of flavors, working in managed service providers that had a closet full of these tower servers that were running off of a small UPS, all the way up through this transition to cloud. When systems administration was no longer in vogue, then I moved over to cloud engineering and DevOps engineering, which was a lot of the same principles just rebranded. Spent a lot of time doing that for different types of companies, and then finally landed here at Google on the other side of things, helping customers solve some of those same problems that I was working on.
Mandi Walls: Yeah, that has to be super different. What are you finding, once you are transitioning from in-house to working with a vendor who is helping all your customers?
Murriel Perez McCabe: The most interesting thing, which we’d spoken about a little bit, is coming to terms with, after having spent a good portion of my life being on call in one way or another, and having this stewardship for a large set of different systems in the back of my head constantly, to now being off the pager, off being on on-call to hardware, but being on call in a different sense to customers and to humans. It’s an interesting transition, of thinking about just work and work hours and also just the availability of myself as a person to be able to respond to certain things. That’s been a very interesting transition, and it’s been great actually to just say, “Wow, I had spent my time in those trenches and having to put out a lot of fires.” It’s not like there aren’t fires, they’re just a very different sort of problem.
Mandi Walls: That’s sort of the concept of you’re working on stuff that you don’t necessarily own, your transition into owning a relationship and these kinds of things versus owning the software that’s running. Have you found that to be it’s kind of strange to detach yourself from it, that transition?
Murriel Perez McCabe: Oh, absolutely. That’s one thing that I found that is something. Especially from being hands-on-keyboard for so many years, it’s something that I’ve baked in and carved out time for myself on generally, to be able to figure out how I can stay hands-on. I’ve got a mini lab of some of these Intel NUCs running in the background, because it’s my way of being able to still stay plugged into a hands-on world and start building things. That’s something I think I consciously hold on to, is can I still build some things so that I can stay close to the solution, close to the hardware, close to the software, while at the same time being a few levels above that and looking at things from this abstract architectural sense. I will say it’s different. I won’t say that I don’t miss having this collection. They’re not supposed to be pets anymore. You know, we’ve gotten away from this idea of your servers as pets, but you still think of this fleet of machines or virtual systems as a group of things that you are caring for in a certain way.
Mandi Walls: Absolutely. I still remember their names. I still remember some of the IP addresses that I had to know back in the day. It’s like remembering weird commercials from when you were a kid. Like, “Why am I retaining this piece of data? I don’t care about this anymore.”
Murriel Perez McCabe: Oh, totally. My first serious tech job when I was doing support, we had that secret master password that we knew if we couldn’t find the login, maybe try this one and maybe it was that, because that was a default that we were using. It’s like one of those secrets that you’re not supposed to have, but we all just internally knew. “Try that one. Oh, wow. We got into that system. Cool.”
Mandi Walls: Right. Right. When I was in college, one of our secret passwords was something along the lines of like the house is on fire and a list of numbers and stuff, and I will never forget that, because that association is just burned into my brain.
Murriel Perez McCabe: Totally.
Mandi Walls: Yeah. Definitely it does that for you. One of our little sections on Page It to the Limit is about debunking myths. We were talking earlier before we started the recording about a good myth. This is one of my personal favorite ones too. We’re talking about a good myth about systems administration operations. Why don’t we debunk that one for us?
Murriel Perez McCabe: Sure. The idea was around this being the hero, lone ranger of your systems, and that one person that is in a lot of organizations or teams that has been there for a certain amount of time to have this muscle memory baked in and a lot of tribal knowledge, that doesn’t always end up translating into your documentation or into your ticketing systems or into your monitoring tools or whatever you have. Where you know, “All right, if I just ping this person, there’s a good chance that they know some small detail about this system,” like our authentication system that has gone down that needs to be poked in a certain way to come back online. Or when they see a certain type of latency coming in for a request, they know where that bottleneck is without having to look at anything else. It’s just somewhere there in their neurons, right? This idea of having to either, one, on the other side, rely on that person to be able to support these systems in a certain way or support an outage in a certain way, or on the other end, being that person, where maybe it’s just faster to say, “I can go in there and I know within half an hour I can get this resolved,” versus there’s maybe double time or triple time to get somebody else trained into being able to do the same. I think that continued reliance of having the human bottleneck is just inherently, of course, not scalable in the same way that you need to scale your systems. The human resources need to be scaled in a certain way. I think the idea around that myth is, one, I mean, there’s probably a certain level of just chemicals and dopamine and everything that go into that rush of being able to solve a solution. I think overall, it’s the sustainability of being able to have a team that can solve those same problems, which will only really happen by, one, giving that ops, that hardworking systems or SRE person, a vacation every now and then that they can be unplugged for. Not a vacation where the pager or the emergency number is on the bedside just in case, but an unplugged vacation. Then also, the idea that the more people that are there can also start to respond to those similar issues, the more that they will now build up that same type of just instinct to be able to go in and to support these systems.
Mandi Walls: Yeah, absolutely. It’s super important for bringing along your junior people, your new folks that don’t have all that institutional knowledge or are new to the skill set, that they can only learn so much by watching the master. Eventually they have to wax on, wax off themselves. Detaching that person whose brain is plugged into the system directly and sending them off to the beach for a while is definitely an excellent idea for folks. When you’re working with customers, do you find they’re still working through some of those issues too, or is that maybe not something that you get to talk to them about?
Murriel Perez McCabe: Well, I mean, it’s something that I’m interested in talking about, or just this idea of being in this operations and dev space. I feel like of course there’s no ideal organization out there. They all have their own individual pain points of what is the most problematic, and are all in different stages of that growth. I feel like across the board, it feels like particularly now, particularly because we have this whole set of just new tech and processes to support by not being an office, by having places that were just not designed to support mostly remote work, which is where I think a lot of organizations are. There are a lot of teams now that I feel like are really trying to figure out how to be able to get their time set up in a certain way so that they can respond. I mean, a lot of teams just feel like they’re busy. There are people that don’t have enough resources, not enough time in the day, not enough bandwidth to be able to deal with things. It is kind of an issue. I think overall in the industry also, one other dialogue I think has been really interesting is this ongoing idea about to go back to bringing your juniors along, the mentorship of junior engineers and being able to slowly bridge that gap, because there’s a trade-off, right? There’s some places where they’re like, “All right, all we’ve got is enough budget for X.” A lot of times where places will default to is, “We just need to get that senior person in, because they’ll be able to come in and be autonomous and fix everything,” which is fine, but then we always end up with this gap of how do we get more people into that level. How do we get more people that are juniors or learning, or that have a lot of maybe even fresh ideas because they don’t have old bad habits baked in? How can these people start plugging in and contributing? It’s this difficult balance of getting more places to buy into saying like, “Yeah, there is going to be this extra overhead of maybe the mentorship and the training and the education and everything,” but it’s like that past benefit, future return analysis, right? How much is that going to gain you long-term, by having more people that you can bring along the way?
Mandi Walls: Yeah, absolutely. I was looking at your LinkedIn. One of the projects that you had been working on was Girls in Tech. Does that feed into the same ideas there of bringing more folks into the industry completely? There’s definitely, oh, we could go on for days about the shortcomings of the pipeline and the leaky pipes and all the other metaphors that we’re using, but internal to any given company, there’s opportunities for junior folks to move up and those kinds of things. External organizations that are looking to foster and mentor younger folks into the whole industry are super interesting, too.
Murriel Perez McCabe: Totally, totally. I’ve spent just a fair amount of time in volunteering and organizing and helping out with different groups on all levels. One place was doing a lot of these hands-on events for girls that would be sometimes as low as elementary school or youth of all ages to be able to get exposure, particularly in underrepresented communities, where I guess part of that idea is if you grow up and know nobody that is an engineer, and you don’t see any engineers that look like you, and this isn’t something that is ever either presented or encouraged as a thing in school, how do more girls make that leap to saying, “This is something that I think that I can do, this is something that I can do hands-on, this is something that is tangible, that I even understand”? I mean, people are using their mobile apps and websites, and technology is just an inherent part of growing up now. To make that jump to say, “Well, I can create these same things,” and knowing that. I think there is more and more access to a lot of that, because we’re kind of in this space where content and creation and making and uploading videos and working really hands-on with this technology is a lot more accessible. A lot of just these mentorship activities would take it to that other level of, “All right, now, what does it mean to be a coder,” and breaking that down. I think that sparks that curiosity and excitement. Also just being able to say, I think with some of the events that we would do just out in the community, to say like, “Hey, there is a place to support,” because everybody has a different story. Some people have very non-traditional backgrounds, right, or might not have come from a tree. I didn’t have a traditional computer science degree, you know? Looking at that and saying, well, there’s more space for people that either may be transitioning in from a different industry or might have non-traditional backgrounds, or even things like re-entering the workforce, to say that there’s a space for everybody and there is support. Because it can be hard if you’re coming from a place where you’re the only one, where you feel like you are not only working on trying to stay up on the technology, work on the things that you’re doing for your function, learn and study and grow, but you’re also the only one that is like you that is in that space in your community. It becomes a little bit of this extra harder overhead to carry.
Mandi Walls: It absolutely is. It’s an extra bit of just exhaustion, right? Sometimes you feel like you have to be the perfect example of whatever you’re representing, because you don’t know if your coworkers have ever met one of you before, that kind of idea too. It can be really stressful for folks. Really, I am just absolutely just flabbergasted at the number of these really supportive organizations for young people and underrepresented communities to get into tech, because we need so many more voices, right? There’s so many more things we could be doing if someone had been there to think about it, right? I know what I need out of a computer, but I don’t necessarily know what the next person wants or needs out of whatever app they might want to design. There’s so much space for people to be inventive and creative.
Murriel Perez McCabe: Totally. I think just that value of having these different perspectives. I spent some time working at a virtual reality startup, also doing DevOps there, and we would go to some of these different conventions and shows and they’d have all these really interesting pieces of hardware, or like spatial seats and everything. I had gone to do this demo where it was based around you wear a vest and you were walking around a space and tracking, but it was not built for my body type and form factor at all. I literally couldn’t go through and use this app because it just wouldn’t recognize me. It didn’t recognize my height and my body size and all of these other things. The vest was designed by a group of engineers that probably had roughly similar frames. One of the jokes was we had this calibration process. I think I was probably the shortest one in our group at the time. Then we had one of the other guys that had a really tall and stocky build. When we would test our application, that would be the upper and lower bound. They would test off of him for the upper and then for me on the lower, to make sure that when we did all of our calibration, it would recognize these two points of the spectrum.
Mandi Walls: Oh, that’s awesome. Just, yeah, fundamental inclusivity for components is so important. Some other things that you’ve worked on, one thing that seems interesting that folks might find fascinating is a bit about you did a talk a couple of years ago about self-care for systems. I was wondering if you could talk a little bit about that. I think you gave it at SCaLE, and that’s the Southern California Linux Expo that happens every year in Pasadena, I think, when we’re all in person.
Murriel Perez McCabe: Yes. Actually, the last SCaLE was the last conference that I’ve gone to for the entire year. I mean, there were a couple of virtuals, but I’m not counting those because it’s a very different experience.
Mandi Walls: Different, yeah.
Murriel Perez McCabe: It’s weird, because usually at least every month or every other month, there would be another major tech event or conference or something to go to. It’s been odd just to be in this new world. I mean, we’re all adapting, but that was still early on, in this proto-pandemic stage of we’re not too sure what’s going on in the world just yet. A lot of sanitizer around and people were all being cautious, but we still didn’t know. It was at the point where we just weren’t sure. I think that was probably the last time that I was in a crowd that large, was not the SCaLE where I gave this talk, but the one just after that, but it is a great conference. I know they’re not doing it this year, but hopefully next year.
Mandi Walls: Hopefully they’ll be back, yeah, next year. Yeah, I got to go a couple of years ago too. I miss that. Like you say, you miss the conference experience. We’re coming up on my one-year grounding, I guess you could say, after Devopsdays New York last year. Yeah, we’ve tried to do some of these virtual events, but it’s not the same. Part of the event is I want to be able to meet people. I want to be able to talk about what they’re doing. You want to bump into them on the coffee line or whatever and just have a chat, and it feels so artificial. Some groups are really good at it. They’ll get in there on that virtual networking thing and they’ll just go crazy, and other folks just are not. Yeah, it’s just a totally different, totally different experience.
Murriel Perez McCabe: Oh, totally. I think after going to a certain number of conferences, it’s almost like the talks … because the majority of those ended up being recorded and available afterwards, so all the best time ends up being in the hallway track or any of the hands-ons. Those would be the two things to do, is, all right, if there’s a hands-on lab where I can actually spin something up, and I’ve got someone on the other end to be able to answer questions because something doesn’t launch properly, or just catching up with people, or maybe some of being able to access and talk to some of the other speakers or people that are working on really interesting things, and swap notes, swap field stories.
Mandi Walls: Exactly, exactly. For workshops, have you been to anything super interesting that you really liked or felt really inspired? It’s been a long time since I’ve had time to sit through a workshop.
Murriel Perez McCabe: Oh, gosh. As far as on the virtual side or on the in-person side, or both?
Mandi Walls: Anything. Yeah, any of them that sound awesome, right?
Murriel Perez McCabe: Gosh, so one, so this is a couple of years ago now, I want to say, at KubeCon when it was in San Diego. It was actually the last day of the conference. This was before I’d started here, and there was this huge room. I think I was maybe wait-listed. It was full. It was a Kubernetes [crosstalk 00:20:41].
Mandi Walls: Thousands of people, yeah.
Murriel Perez McCabe: It was super busy. It was packed. I snuck in there and was able to get access to the lab environment, because they had just people fluctuating, but it was the very end of the day on Sunday where usually everybody’s clearing out, but that room was packed. It was actually this really great, super hands-on interactive. Prior to that, I guess, is maybe part of my origin story here, is prior to that, a lot of the work that I’d done at previous companies, it was maybe really Amazon-based or private data centers and other things. That was when I was just starting to learn about the world of what’s in Google Cloud and what it’s all about. That was, I think, maybe my first really in-depth hands-on, and it was I guess this really eye-opening experience, like, “Wow, this is really cool. I wonder how long I can keep this lab environment going before they shut it down?” Then as far as just internal, I mean, we’ve got a lot of internal training labs and resources. There were some of these tech challenges that we were running through of just being able to do the scenario-based, like here are a couple of scenarios and you get the tools to achieve that objective, like maybe building out a data pipeline or something. There have been some of these different ways that I’ve sought that out, just because. I don’t know, I think going back to earlier stuff that we’ve talked about, once you’ve been able to actually get on and still really connect to deploying and managing and being hands-on with the software, there’s a part, I feel like, that doesn’t always want to fully, fully get that up and transition it over to a totally non-tech, theoretical world.
Mandi Walls: Yes. Yeah. You always have that account with your favorite images or whatever’s ready to go over there, so you can …
Murriel Perez McCabe: Right, right. Totally. There’s always a little bit of like, “Oh, I’ve got it.” I had started a virtual study group during pandemic that was like, “All right, we’re going to have a study hall. We’ll hang out, talk for about 10 minutes, and then everybody’s going to go heads down mute and work on something.” That was my way of just like, all right, I’m going to try to keep my Python fresh and level it up beyond. There was a lot of like, “All right, you’ve got to use this for just your scripting and automation and everything,” but I wanted to move to building something interesting.
Mandi Walls: What did you end up building?
Murriel Perez McCabe: Ooh, so what I’m still working on is going to be, I think, more of like a text-based adventure game. I was also playing around with some UI. They have some of these different like Pygame and other utilities where you can actually build out sprites and stuff, but for now I’m interested in the storytelling aspect of it and being able to build out this interactive fiction-type adventure build. That is definitely still in progress.
Mandi Walls: Yeah. You’ve got a few more months of pandemic, I think, to continue to work on that, unfortunately. Yeah. Oh, my goodness.
Murriel Perez McCabe: Yes. I didn’t even get to the talk that I had done at SCaLE, which the title is Self-Care for Systems at any Scale, because I threw that scale pun in there.
Mandi Walls: You need a pun. Puns are required, yeah.
Murriel Perez McCabe: The idea was around looking at the overall health of your systems and infrastructure, and relating that to this idea of your own personal health and the idea of maintenance and your ongoing. How do I ensure that I am doing okay and healthy, and then also going back to some of these root causes and preventative solutions, where a lot of that is kind of the same, or at least the similar principles? It’s like, all right, if you keep just doing things in this break/fix sense, it’s fine, but you don’t necessarily resolve the root cause of something. It’s like, all right, I’m hungry. I’m going to grab junk food. Then it’s fine, you fix it, but it’s this short-term fix and what does that turn into long-term? Same thing with systems. The whole idea was taking this idea of looking at your systems from a high level and being able to manage things in this proactive way. That was, I guess, just the story that I had built throughout, was this idea of doing a checkup. Can you do a checkup on your systems? If your systems are bleeding, there are ongoing failures and things are on fire, the most important thing is not to go to a person and say, “Hey, how’s your blood pressure doing? Are you getting a lot of sleep?” No, you stop the bleeding first. You take care of the immediate issues, and then you go back and say, “Well, what do we need to do to be able to ensure longevity and health for the future?” You do patch management in a certain way so that you ensure things for the future, in the same way that you might take vitamins or something like that or drink a lot of water, because that is like how do you patch your body and your health to be able to ensure that you’re going to be better for the future.
Mandi Walls: Yeah. I was reading through the slides and it sounded so fascinating, because you’re right. You can check your blood pressure and you can do these vital signs. If you still feel bad, that’s only part of the problem. Okay, I know that my CPO load is X and my memory utilization is Y and my network throughput is Z, but do I know if my customers are getting the right stuff when they’re hitting my services? There’s so many facets to look at that, yeah, you have to keep broadening your view and working through all that stuff. Super interesting.
Murriel Perez McCabe: It’s just also this idea of some of these intangible outward manifestations, that are all driven in the back end by maybe certain stats. If you’re just looking at the stats and metrics, or if you’re just looking at the outward symptoms and you’re not starting to connect these, then you don’t really have that good picture of how to make things better. That’s the idea, is how do you make things better?
Mandi Walls: Yeah, definitely. Okay. We’re coming up on time. I have one final question for you. You’ve had a lot of different experiences and worked at a lot of different places. If there is one thing you wish you had known earlier in your career about running software, managing systems or these kinds of things that you wish you had known, is there anything there that folks might get some good advice from?
Murriel Perez McCabe: I think the main thing is not having to feel like I needed to know everything, for one, or to be the one to do everything, which is two. That’s because a lot of times I think looking at this whole idea of scaling and scaling self, an individual unit of human is only going to scale to a certain level before everything maxes out. Your CPU, your brain, maxes out. Your ability to remember things maxes out, your capacity to hold and store and execute on things maxes out. At some point, you’ve either got to knock down the inputs, or you just end up burnt out and end up wanting to sleep for a week, or just end up super fried, where your capacity and output just doesn’t end up. Your performance goes down, I guess thinking of self as a computer in this weird sense. Figuring out like, all right, when do you need to send some of these requests out? When do you need to start saying that there are things that you don’t have to individually do? Or even knowing like okay, and this is that idea of when to stop hitting your head against the wall for a problem and when to be able to tag somebody in on it. All right, if I need to fix our messaging queue or something like that, is the most effective thing going to be spending an hour and a half reading about the internals of the system, or getting somebody that can sit down and in five minutes maybe demystify something? Figuring out when to triage just knowledge and work in the right way, rather than feeling like at all times, you must be the technical expert or resource of having to hold and have all this information available. Especially coming from the support point of view of supporting and being with end users, where it’s like as a technologist, you end up being the de facto person that people will go to to ask about something. I’ve been asked about resolving Google Pay issues, or stuff with search extensions and everything else.
Mandi Walls: Right, yes.
Murriel Perez McCabe: Almost like if you look at contractors, right? Okay, there’s a general contractor and maybe they are experts in building a house, but they might not know how the plumbing or electrical or the landscaping works. There are finite limits to the information that you hold in your head, but there’s this ability of knowing how to outsource the right parts of it in the right way to be able to be most efficient. That was one to just have to come to terms with and understand at the time.
Mandi Walls: Yeah. That’s a super good lesson for folks to learn. We actually use it a bit in some of our other trainings, as far as when we’re talking about responding to incidents and things like that. Our theme there is don’t hesitate to escalate. If you are struggling to figure out what’s going on with an issue, it’s time to pull in some other folks and get some help, so excellent. Excellent piece of advice, 100%.
Murriel Perez McCabe: Thank you.
Mandi Walls: Well, thank you so much for joining us today. This has been really, really great. I’m really glad you were able to join us. Thank you so much.
Murriel Perez McCabe: Thanks again for inviting me. It’s been super awesome talking with you, and this has been a lot of fun. I enjoyed myself.
Mandi Walls: Awesome. That’s what we like to hear. We will sign off. Thanks for joining Page It to the Limit. This is Mandi Walls, and we are wishing you an uneventful day. That does it for another installment of page to the limit. We’d like to thank our sponsor, PagerDuty, for making this podcast possible. Remember to subscribe to this podcast if you like what you’ve heard. You can find our show notes at pageittothelimit.com, and you can reach us on Twitter at pageit2thelimit using the number 2. That’s Page It to the Limit. Let us know what you think of the show. Thank you so much for joining us, and remember, uneventful days are beautiful days.
The path to technology careers can be full of twists and turns and interesting side quests. Tune into this week’s episode for a chat with Murriel Perez McCabe, an Enterprise Customer Engineer at Google, to hear more about transitioning from system owner to helping others run systems better. Along the way, she has gone from being the solo operations specialist to a mentor and leader.
To find a Girls in Tech chapter near you, visit https://girlsintech.org/.
Want to chat more about mentorship, DevOps, cloud operations, or just whatever, join the PagerDuty Community at https://community.pagerduty.com.
Murriel is a Customer Engineer with Google Cloud, working with enterprise customers to solve technical and business challenges. She is currently excited about all things DevOps, Information Security, Kubernetes, and Observability. She is also a big advocate for mentorship of girls/youth in STEAM/Technology and enjoys plugging into the local Southern California tech and maker community. When outdoors, can often be spotted on a bike, by the coastline, in the garden, or covered in sawdust.
Mandi Walls is a DevOps Advocate at PagerDuty. For PagerDuty, she helps organizations along their IT Modernization journey. Prior to PagerDuty, she worked at Chef Software and AOL. She is an international speaker on DevOps topics and the author of the whitepaper “Building A DevOps Culture”, published by O’Reilly.