Life of An SRE with Stephen Benjamin

MP: Hello, and welcome to episode five of season two of the Google "SRE Podcast," or as we affectionately refer to it, "The Prodcast." So for this episode and the next episode, I have a new co-host. So I am-- first things first, I'm going to go ahead and let him introduce himself.

CHRIS: Hi, I'm Chris. I'm a Noogler. I started working for Google back in May. At previous jobs, I've worked to speed up deployments through automation for a credit card processing fintech in Oakland, building an education-centered social network with Golang from scratch in LA. Prior to that, I was building and maintaining web infrastructure for terrestrial radio production and distribution in Arizona.

I've been all over the stack in my tenure. I've built server rooms from scratch from cooling and network stacks to virtualization and storage clusters. I've built back-end servers. And I've created very terrible UIs. I'm brand new to managing systems at Google scale. And I'm very excited for the challenge and super excited to be part of "The Prodcast."

MP: Thank you for joining us, Chris.

CHRIS: My pleasure.

MP: So on this episode, we are going to have our first guest, who is a member of SRE management. So that's new and exciting. Everyone that we have spoken to so far has been an individual contributor. So now, we are going to get a little bit more insight into what it means to be a SRM or a site reliability manager. So I'm going to hand things over to our guest for him to introduce himself.

STEPHEN: Thank you, MP. Hi, everyone. My name is Stephen. And I've been at Google a little over 12 years. I'm based in Zurich, always have worked for Google in Zurich but originally from the UK. And right now, I'm managing a team who build out the monitoring infrastructure or parts of for Google and other Alphabet companies.

Before Google, I was working for a finance company. And we can talk about how I went from finance to SRE management I think later on. And before that, studied electronic engineering for a few years and sustainable development. So very excited to be here. And this is my first podcast, Prodcast of any kind, so very excited to see how it goes.

MP: Thank you for joining us.

CHRIS: OK, cool. Thanks for the intro, Stephen. So I'm pretty new to Google. What does a site reliability manager do? What does your day look like?

STEPHEN: So I guess the answer, which no one wants to hear, is it depends. It varies quite a lot depending on what you're focusing on and also what your focus as a manager is.

So right now, I primarily manage other managers. And so a lot of my time is spent working with them and other stakeholders and customers to try and align on, agree, and drive the priorities and expectations that we've got across my sets of teams and with our partner teams and customers. I think if you're a line manager, and by that, I mean someone who's typically managing a team of perhaps six or seven SREs in a traditional SRE team, then you may be more involved in the day-to-day operations of your team.

So some managers are, in fact, on-call for their services. I am not on call for a service, so I don't have that as part of my day-to-day, but I know that there are managers who are managing a single SRE team who would be perhaps involved in that on-call rotation. And I think it's a balance. Whichever level you're at, it's a balance between that sort of direct people management side of things and the more strategic team leadership, product leadership, organizational leadership aspects.

And I think it does depend a bit on where you are in the cycle of things that you have to do as a manager. So that if you're in an annual planning cycle, you spend a lot more time on the non-people management side of things, thinking about how do you align your OKRs with your organization. How do you make sure you've got a good vision, and you've got plans that set you up for the next six, 12 months.

However, if you're going through a performance review cycle, which we're heading into right now, then lots of your focus is going to be on understanding what the people who report to you have done in the last six to 12 months, and how you can reflect on that and talk about performance ratings and give coaching and feedback to people. So it really depends on where you are in that cycle. And of course, depending a bit on your organizational structure too.

So Stephen, you manage direct line managers, or do you manage other managers of managers?

STEPHEN: No, my managers all are line managers at this point. So I have four managers reporting to me who manage between six and 15 people, which I will say up front 15 people is a non-ideal number for a manager. We're going through some growth in our team at the moment. And so they're sort of holding the fort for us as we grow out in a different site.

So I'm managing people in both Zurich and Munich. And the Munich site is a growth site for us. We have managers coming in January, thank goodness. But for now, I've got two folks in Zurich who are managing the people that we've hired in Munich until we have the managers ramped up there. But they are all-- they're not managing managers themselves. And I have one individual contributor also reporting to me.

CHRIS: So you've come from a financial analyst background. That's pretty unique. How did you decide this is what you want to get into? What made you want to do it? Like, what was the process there [AUDIO OUT]

STEPHEN: It was definitely a mixture of circumstance and luck and some intentionality as well for sure. But I want to be clear that it wasn't all planned out from the beginning. So as you said, I started out working for a finance company. This is an asset management company I moved to work for on basically a grad program when I left university. Moved to the States for a couple of years. Did a variety of different things.

Ended up living in Zurich for personal reasons and was looking for a job. And Google was looking for a finance analyst to support the engineering and product management teams in Europe, Middle East, and Africa. And I thought, well, I worked for a finance company for a couple of years. And I've got an engineering degree of sorts, so engineering, finance analyst seems perfect.

Took a punt on it. And thankfully, Google agreed that it was a punt worth taking. And so ended up, to my surprise, at Google in Zurich as a financial analyst.

I think, very honestly, I knew fairly early on in that role that it wasn't somewhere I wanted to grow a long-term career. I worked with a lot of product managers, especially early on. And I loved the aspect of working with products, especially at Google scale. I mean, I think everyone here knows the scale that we're talking about.

It took me a long time to make that move. I had a few transient points in between. So as a finance analyst for about three and 1/2 years, ended up moving into one of the teams I was supporting was the emerging markets team. And we were rolling out products in various different countries. And I moved in to that team as a program manager doing business operations analysis, basically. I had a team of reporting analysts. We would look at how a product was rolling out, how we could optimize its performance or its roll out and its scale up, and providing information to teams on the ground who could then sort of adjust how they were doing things.

CHRIS: How did you get involved in that?

STEPHEN: So the former vice president of engineering and product for all of the EMEA-- Europe, Middle East, and Africa region-- was specifically leading this emerging markets initiative from Zurich. And I was, as the only finance person in Zurich, I think well-situated to be his finance support. So again, that's sort of partly where luck and circumstance just came into it.

And so developed a very close working relationship with him. And that was a very, very exciting journey, which is probably subject of a different conversation. But we ended up ultimately growing this fairly big organization of about 300 people, very cross-functional engineering, but also sales, marketing. And working with him.

And I talked to him regularly about where I'd like to go next in my career. So again, I was lucky to have a very senior person that I could sort of bounce these things off of. And eventually an opportunity came up to work in the operations part of the organization.

So I moved over there as a program manager and started work on this sort of business operations or business analytics team. And I think it was a good fit between pure program management and what I'd been doing in the finance team because it was sort of a mixture of reporting analysis but also sort of structuring programs and projects.

STEPHEN: So as these things come to pass, the emerging markets team graduated and various parts of it went different product areas within Google. Some of the prods went on to be scaled beyond emerging markets. Other parts were folded in. The team I was part of went into the GO organization, specifically local business and data listings, mapping. And so the focus became very much more singular, focused on that rather than this broad spectrum of things we were doing in various different emerging markets countries.

And so I ended up looking around for opportunities in Zurich that sort of felt more aligned with where I'd like to go. And SRE came along. And so I moved into SRE as a program manager. I mentioned that the team I was on previously moved into a different organization. And I just didn't have the same passion for the mission.

And again, circumstance dictated that Zurich is a growing site. And I was lucky to have some opportunities and options around me. And for sure, that played a factor.

And I met with one of the site leads for SRE at the time. And he was looking for actually three program managers. And he had some headcount to hire, some folks for those. And so I was lucky enough to actually kind of get to pick which of those three I wanted to work on.

And the thing I ended up opting for was to work with him across two product areas, which were at the time called Apps and Social. Social was the team that used to manage Google+, if people remember that. And Apps is Gmail, Docs, Drive.

But the goal of that program or that role was basically, before I joined, Social had split from Gmail, technically. It had been a group of SREs that had sort of broken off to support Social and Google+ as it was scaling and growing. And so historically, they had been built upon a foundation of similar ways of tackling production management.

But over time, as you can imagine, there had been this divergence of approaches to managing their production systems. And the goal was really to try and structure a program that would help bring those two product areas back together on a technical footing so that they would reap the benefits of convergence in terms of lower overhead cost, lower maintenance cost for the teams, lower cognitive load for engineers, higher mobility for people between services. And so that was what my new manager was looking for was a program manager to basically come in and help structure that program, work across those two product areas.

So super challenging space for me to go into because I had no technical experience in Google at all. I came into SRE and probably honestly understood 50% or 60% of the words that people said to me for the first few months. And we talked about ambiguity earlier. That was definitely-- there my solution was write a lot of stuff down, ask a lot of questions, and sort of play the somewhat naive idiot in the room for a while.

And I think I'd been at Google long enough I think, and I felt comfortable enough with the people I was working with to be able to do that. To ask a lot of questions, I think that's really important for people as they're ramping up into these new roles. And that's maybe something we can talk about later is how we kind of create that environment for people.

But it was very interesting because out of that sort of grew a track across all of SRE, which is called the Convergence Track, which I was working on with a couple other engineering managers at the time. I was still a program manager. And we were trying to basically drive some best practices and some actual technical convergence across SRE, different product areas and teams.

The thing that made that very challenging was that we didn't have any headcount for any of this. So we were doing it with a team of volunteers. And I think I remember listing it out at some point. We had probably about 120 people contributing in some way across all the different offices and SRE at some point, which sounds like a lot. But when they're all contributing 20%, it's never really 20%.

And actually managing that is really, really hard. Everyone has really good intentions, but their ability to deliver something on a schedule at a certain amount of capacity of their own time is basically impossible to manage. So we kind of made, we made progress in fits and starts.

Two of the bigger projects that I was involved in from the early days were called Prodspec and Annealing. Those were the two projects, at least that I was involved in, that made the most progress.

We had a very dedicated group of volunteers who were really interested in solving some problems for their own teams and their teams around them. And I think that really helped because we could actually make some good progress. And we had managers who were very supportive of this as well.

This and multiple other projects covering different aspects of service management. So capacity management, monitoring is the team I now work in, and incident response management had similar types of volunteer driven projects, some of which were funded, but most of which weren't. And I think the key shift and the way to answer your question eventually, Chris, the key shift came when we actually got proper funding for these projects. There was a recognition in SRE that either we do this properly, and we put headcount behind these efforts, or we don't do them.

And I can tell you as a program manager who was trying to manage even a bunch of 80% contributors, when you're trying to manage around on-call rotations and other schedules and competing demands and code yellows and whatever happens, it's really, really hard. So having this injection of actual headcount, I mean, it's night and day for where we are today compared to where we were running as a bunch of volunteer projects. At the time, I was program managing Prod Spec and Annealing, I think we had about 17 engineers working on the two projects in total, I think roughly. And I guess I was in the right place at the right time or the wrong place at the wrong time to be asked to take on management of those people directly.

And I have to say, again, I'm really grateful to my manager at the time who-- we had a very open conversation about this. And said, look, this is a bit of a risk for both of us or an experiment. I was a program manager, not a technical program manager. So I hadn't been-- I hadn't done a transfer even onto the technical ladder. And I was working very much in the kind of like let's organize people, projects, agree priorities, track progress, drive progress rather than exercising a lot of technical judgment on the projects. I had built up a lot of state over time just naturally through osmosis.

So yeah, we agreed to take this chance. And well, five years later, it seems to have worked out. But it definitely was-- it was a chance that we both took kind of consciously but not necessarily knowing if it would be the right-- work out for me or the team or SRE.

MP: I did have a question I wanted to throw in. So something that's come up a lot in our previous episodes has been the role of mentorship. So I would like to hear from you how mentorship has played a role in your time as an SRM, whatever your relationship with mentorship has been.

STEPHEN: OK. So I said when I joined SRE, I was originally part of the Gmail SRE team. And I remember the first day I walked in, the thing that opened my eyes to the scale of the thing I was working with was someone put their head up above one of the desk dividers and said to someone else, oh, can you just check this thing for me? I need to move half a billion users from this data center to another data center. So I realized I was in a totally different world than the one I'd been in before where we were talking about a few thousands of users on our emerging markets products.

And I kind of went from there. I didn't have any real technical exposure or background, especially to the things that Gmail was running at, the scale it was running at. And so in particular, I worked with a couple of engineers on some small starter projects. And they were super patient with me. And they were very-- they were low priority things. They were things that people felt like they would give me a good exposure to production, Gmail itself, and Google engineering more generally because it wasn't something I'd been exposed to.

And so I'd say it wasn't necessarily a formal mentoring relationship but it was definitely an important informal mentoring relationship, where I would just sit with them and pair program kind of is the best way I can think of that in some ways, like a way through some of these things. I'd write something in a doc. I'd get some feedback from them on it.

And then I'd try something. Inevitably, it wouldn't be quite right because doing stuff with Gmail is complicated as you could imagine. And then I'd sit with them and they'd sort of walk me through it. And I think having those patient sort of senior experts around me has been a hallmark of being able to actually be effective as a manager given my role and my path into the role.

I think as I've taken on people management, I've definitely benefited from having mentors. Often, when I'm trying to deal with specific challenges-- so two things I know about myself, which I've had to really work on or with as I've grown as a people manager is that I'm a conflict-avoider. And I'm a people-pleaser.

And those two things can make it difficult for you if you want to give someone feedback. And when you're not a manager, it's not really part of your job formally. Of course, everyone should try and give feedback, and ideally everyone does. But as a people manager, it's on the job description. At least once or twice a year, you have to give someone feedback on how they're doing.

And I picked up a team of 17 direct reports overnight. And it had a wide spectrum of performance levels throughout the team. And some of which needed more support than others. And that was something that I definitely wasn't familiar or comfortable with, especially given my previously mentioned characteristics.

And so that was something where I definitely relied heavily on experienced mentors. There was one engineering manager in SRE who it was very interesting. The first time he sat down with me to talk to me about people management, he just gave me effectively a lecture on physiology and psychology of how people react to challenging circumstances, like this fight, flight, or freeze kind of reaction.

And the whole thing there was to build up to when you're giving someone-- having difficult conversations, you need to understand what's going on inside them as a human being, as a person who has a physiological reaction to being given some difficult news. And I found that really fascinating that was the first thing that he thought he should share with me as a manager. But it really stuck with me that you will have these hard conversations. And they won't be easy. And the other person on their end is much harder for them. And they have a physical reaction to it.

And so sometimes you need to have those conversations in two parts, maybe even five minutes or an hour or a day or a week to then come back to it and have a rational conversation. So that was really important. And that person I stayed with them as a mentee for quite a while. I'd meet with them at least every two weeks just to talk about things I was going through and their experiences. They were a very experienced people manager.

CHRIS: How did you find these mentors [AUDIO OUT]

STEPHEN: So in this previous case, they were sort of an obvious choice because they were one of the three or four senior engineering leads or managers at the time in Zurich. And I wasn't working with them directly, so I think that helped because they were sort of somewhat removed from the circumstances I was in and could be a bit more objective, so that helped. Other times, I've asked colleagues around me who they've worked with, who do they recommend, and that's been useful as well. That's helped me connect to some senior folks outside the Zurich office, outside of SRE who have a very different or a more objective perspective and experience that's relevant.

I don't think I've used any of the formal mentoring mentee pairing programs at Google as a mentee at least. So it's really been about trying to exercise my network a little bit around me. I was lucky because I've been through various different parts of Google. I've got a decent network of people that I've worked with in the past. And I try and foster and maintain some of that. And I think having people outside of SRE has been helpful just to fall back on to ask not random questions but sort of somewhat random questions.

CHRIS: Some external perspective.

STEPHEN: Right, exactly.

CHRIS: So it seems like you have a lot of trust in your engineers. How do you build and maintain that level of trust

STEPHEN: So I'd say, as a person-- and again, this is something I've kind of [AUDIO OUT] I think it's important to know about yourself as a manager or as an individual contributor. I don't think it really matters. But one of the things I know about myself is that I tend to start from a position of trusting everyone. And so I don't rely on someone to build that level of trust with me beforehand. I kind of try and walk into most circumstances assuming that I can trust this person. And I don't mean on a sort of deeply personal level. I mean, if we talk about something professional, it will probably get done to a decent standard.

So I think that's just a starting point for me. Now, that can sometimes backfire. You pick up 17 engineers overnight. You don't know all of them that well. But that's just always been my starting point.

So it's probably obvious to say that trust is a two-way street, right? Also, when I started managing these folks, they didn't pick their manager. I didn't pick my team. That was an interesting situation for all of us to be in. Plus, for them, they had someone who had never been a manager before. So this was sort of uncharted territory for most of them probably as well.

So I think it was about for me establishing myself as someone who was there to support them. And also, I tend to be, as I mentioned earlier, I rely heavily on having partnerships with strong technical leads and folks around me for the technical aspects. I didn't mention it, but maybe it's implicit, but my technical background as it goes is electronic engineering. I don't have any formal software engineering background. So I'm not the person in the room that's going to be leading the charge on how we technically solve a problem. I am the person that will identify the best people to help us and really create a space where they can contribute and drive the discussion and decisions and help them kind of work through that.

And I think I tried to always be clear with people in the team that that was my role. I wasn't there to make the technical decisions for them. I was there to enable them to do their work.

So I think when I started out as a people manager, people already had projects on the go. And I definitely did not walk in and try and create waves and assert any formal authority as a people manager. Much more, it was about let me understand the set of things that people are working on. And then over time try and work out how does that align with priorities.

I think what was important is there was some organizational context around this as well. So the organization that we were in was going through lots of change. And so trying to also help them navigate through that. And again, by demonstrating that I was there to communicate those changes to them, help them understand them, build a team structure that kind of made sense was one way I tried to build trust with them.

And I think modeling, going back to maybe to finish the point, I mentioned sort of being clear that I didn't know-- I wasn't there as the technical expert. I think that was important. I said earlier I asked a lot of questions. I continue to do that to this day. And I think that's important for managers and leaders to kind of model that openness to not knowing something and creating a space where it's all right to ask the questions.

Oftentimes, I ask a question because I just don't know the answer. Sometimes it's also because I perceive that perhaps other people also don't know the answer, and it would be helpful for others to hear that. And I think if you as a senior person in the room can set that tone, I think it's really important for creating that environment where others feel like they can also put their hand up.

CHRIS: So you were just this newly minted manager. And I've been working in industry for a long time. I have mad imposter syndrome. Did you have imposter syndrome signing on to this position? And if so, how did you deal with that?

STEPHEN: Yeah, imposter syndrome and I are good friends, I think. So I think one thing that helped me is that I hadn't come into SRE from an individual contributor background as a software engineer or a systems engineer. Everyone knew where I came from.

And so I was very clear that this is my strengths. I think I'm good at organizing people. Hopefully, I will become good as a people manager over time helping support their career development. Everyone knows I don't come into this as a tech lead who's now also managing people. So that definitely helped.

Having said that, it also means that sometimes I'm in conversations, even today honestly, people tell me things that I feel like I really should know what that thing actually means. I'm not going to give an example because that would feed my imposter syndrome too much and probably validate everyone listening that, oh, Stephen shouldn't be here, so,jokes aside-- I still get that today.

And one piece of feedback I had in the past actually was that sometimes it's natural to have-- I think everyone, everyone suffers from imposter syndrome to a certain extent at different points in their career and to different levels.

MP: So in my personal head canon of what managers do every day is mostly being buried in meetings and short on time, which I don't think you've directly contradicted at any point today. Sounds like managing is quite its own unique challenge. But I am curious, how do you maintain a healthy work-life balance with the particular time demands, structured time demands that management usually requires?

Stephen: So first of all, I think probably worth at this point saying that I work part-time. I think that's an important context for people listening. It's not an everyday circumstance-- that not many Googlers or managers work part-time. I've been working 80%, which is four days a week, for a little over three years now. And I think that was a big part of me trying to manage my kind of overall balance between working time and life or life outside of work because I think I spend a big proportion of my life at work.

I have mixed feelings about the kind of work-life balance expression because I'm not sure it is always a balance. I think sometimes it's a case of prioritization. And that's sort of how I try and treat it. So sometimes, depending on what's going on at home or at work, I tend to emphasize one more than the other.

One thing that I had done before I was part-time when I joined SRE, which is at this point eight years ago, which shocks me to think about the number, is that I was already leaving early on Wednesdays. I had two young kids at that point already. And we had some commitments at home, which I basically had committed to my wife that I was going to be around at home to take on.

And so when I joined the team, everyone knew that I left the office at 3:00 on Wednesdays, and nothing could happen after that for me work wise. To the extent that there was a cross site team meeting that happened on Wednesday afternoons with Sunnyvale. And I said I can't be there. If you want me in the meeting, the meeting will need to move. And they said, it's fine. We don't need you in the meeting. And so we just kept it where it was. And I think it was a very explicit expectation between me and the team about my working patterns.

So I think I've put very explicit structures and times in general around my time. Maybe it's worth mentioning at this point, we're recording this at, for me, 9:00 PM on a Monday evening. And I'm not saying that to come across as some hero. I didn't start the day until 11:30 this morning. And I stopped half an hour later for lunch. So I definitely shift my day to cover the US once or twice a week. And I think that's important, right?

The reality is that we work in a global company. And you need to have some flexibility. And so I take that by working late on Mondays, but I start late. But I basically don't work after 5:30 on a Tuesday because I need to be back home to help. And Thursday is sort of my wild card day where I can flex it one way or the other, depending on what I need to do.

I guess it comes back to that comment I made a minute ago of it's where the priority is at a given time. And so sometimes, I got something happening at home. I've made a commitment to one of my kids that I'm going to be there to watch a thing. And that goes in my calendar.

And I have to say, you mentioned sort of meetings and calendars, and I live and die by my calendar. But my team also know that. So if they can find me in my calendar and there's a free slot, it's very explicit. I have office hours, which is a standing slot which people can book. But also, if they want to talk to me about something, there's an open slot on my calendar. I'm very religious about keeping it up to date. And so people know where I'm going to be and when. And I think that's really important from setting expectations inside and outside of work.

And so that's a tactic for managing it. I'll be honest. I think everyone should be honest about this sometimes it works better than other times. You know, I also like to try and keep myself somewhat fit-- a bit of running or cycling. And I try and sort of schedule those in. Sometimes that falls by the wayside. I think you can't do everything. in my case, I've got three kids at this point. And you know, I spend time with them. I can't also be a full-time athlete and a full-time engineering manager and whatever else is I want to do.

And so you have to make choices and prioritize. And sometimes you have to just drop one thing or another. So I think to answer your question slightly more succinctly, it's about setting clear expectations, understanding what your priorities are at a given point in time, and then just sort of being strict about those. And I think that's the really important part is really holding a kind of firm line both ways.

And personally, I'm very lucky. I have to say my wife, she works 60%, so three days a week. And we've kind of managed to balance that. So she works in the middle of the week, and I work Monday, Tuesday, Thursday, Friday. So we've kind of managed to spread a lot of it out. But she also has some flexibility, so if one or the other of us needs to come home earlier or stay later, we're kind of lucky to be in that situation as well.

CHRIS: It's super important to have those boundaries.So you've been at Google for over 12 years now. What if you could go back in time, what advice would you give to your 12 year younger self?

STEPHEN: I think the honest answer at this point is take opportunities that come up. In particular in Google, I know everyone doesn't work at such a large company with such a sort of diverse range of things going on. But one of the things I love at Google and one of the things that's kept me here is that diversity of opportunity and the ability that you've got. So I've been through three or four role profile or ladder changes. I've worked on the general and administrative side of the business, on the engineering side, on the operations side.

I think the advice would probably be: take the opportunities that come up to see different parts of the company. And I know that sounds-- that's not a very useful answer because I feel like I did take some of that path, but maybe I'd say do some of it sooner. I ended up-- I said earlier I knew early on that finance wasn't the place I wanted to grow long term. I think maybe in hindsight I could have been a bit more intentional about seeking out some opportunities. But you know, hindsight is 20/20.

CHRIS: I'd like to think that I would say yes to all those opportunities, but I hope when they're presented I would have your courage.

STEPHEN: Like I said earlier, also some of those were circumstantial and luck and some intentionality, right? And I think maybe it's just-- yeah. I feel very lucky to be in a place where that opportunity exists, right? And that's something I am very open with my teams about, actually. And maybe it sounds weird for a manager to be telling people to think about mobility. But I feel like it would be sort of hypocritical of me not to be open about it with people in my teams because I've moved around so many times.

And so I tell people very openly, like, if you've been in a role two or three years, thinking about mobility is not a bad thing. And by the way, here are some resources that you can think about. Would love to have you stay, but if you really want other opportunities, and we can't meet those, or it just makes sense for you to go do something else, like, let's also talk about that.

MP: So thank you so much, Stephen, for joining us today. It's been an absolute pleasure having you on, getting to get a little bit more insight into the life of the SRE manager. Is there anywhere online folks can find you if they want to reach out?

STEPHEN: Yep I think LinkedIn is probably the best place. And people can-- I'm happy for people to reach out to me there.

MP: OK, we'll be sure to include a link to your LinkedIn, a link to your LinkedIn in our episode notes. Chris, did you have any parting thoughts for us?

CHRIS: I just want to say a real big thanks to Stephen here for your time. This was amazing. I learned so much from you. I hope to be a really good SRE if you were a direct manager of mine, you be my manager because it sounds like you're really, really supportive and thoughtful and caring. I just want to say thank you so much for your time today.

STEPHEN: Well, thanks for the kind words. And thanks for the opportunity as well. It was great to speak to all of you and share some of these stories. Thank you.

MP: Thank you everyone. Until next time.

VOICEOVER: "Prodcast," the Google SRE production podcast is hosted by MP English and Chris Wojno, and produced by Salim Virji. The podcast is edited by Jordan Greenberg. Engineering by Paul Guglielmo and Jordan Greenberg. Javi Beltran composed the musical theme. Special thanks to Steve McGhee and Pamela Vong.