Jonan Scheffler interviews Google Developer Advocate Amanda Lewis about DevOps Research, and Assessment (DORA), being hospitable to customers and finding creative ways to solve people's problems, and what exactly “a DevRel team does.”
Should you find a burning need to share your thoughts or rants about the show, please spray them at email@example.com. While you’re going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you’d like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @ObservyMcObserv.
Jonan Scheffler: Hello and welcome to Polyglot, proudly brought to you by New Relic's developer relations team, The Relicans. Polyglot is about software design. It's about looking beyond languages to the patterns and methods that we as developers use to do our best work. You can join us every week to hear from developers who have stories to share about what has worked for them and may have some opinions about how best to write quality software. We may not always agree, but we are certainly going to have fun, and we will always do our best to level up together. You can find the show notes for this episode and all of The Relicans podcasts on developer.newrelic.com/podcasts. Thank you so much for joining us. Enjoy the show.
Welcome back to Observy McObservface. I'm Jonan. I'm a Developer Advocate here at New Relic on the Developer Relations team, The Relicans. And if you have not heard yet, The Relicans are showing up at FutureStack. They gave us a whole track just to ourselves where we are going to be getting up to all sorts of nonsense, and you definitely want to be there. You can go to register at therelicans.com/futurestack. And without further ado, I would like to introduce my guest, Amanda Lewis. How are you, Amanda?
Amanda: I'm great. Thank you for having me.
Jonan: Thank you so much for coming along. So, time ran away from us a little bit. I typically start these podcasts off where we just chat a little bit because I like to fall into a natural conversation. I think too many podcasts you get on, and it's almost scripted. It's like, "Well, tell me where is it that you work?" Then there is the company pitch.
Jonan: "And do you enjoy it?" "Yes, we do." So I'm glad that we had such a nice, long conversation, but then we've used up all of our time. So we have to speak very quickly. If you could just real quick, say all of the things you just said over the past 30 minutes, just speak now for another 30, and then we'll call it a day.
Amanda: [chuckles] Awesome. (speaking indistinctly) just kidding.
Jonan: Yeah, perfect.
Amanda: So maybe the short synopsis, if I remember everything we spoke about, is it started by you understood that I went to university in Japan and then somehow magically several years later dropped at Google.
Jonan: Yes, that was it.
Amanda: So I filled in some of those dots, being that I was a customer advocate at Stackdriver, and then we were acquired by Google seven years ago. And then, I moved into a support engineer role at Google. And from there, I became a program manager within cloud DevRel within Google Cloud. And then magically, six months ago, I got to become a Developer Advocate working closely with our Google Cloud customers talking about DevOps, and DORA, and SRE and really trying to help all the people in the business come together and have a shared language so that we can deliver awesome software to help our customers.
Amanda: How did I do? [chuckles]
Jonan: You nailed it. You did a really good job. That's great, actually. We were looking for your background, and I think when I was looking you up, the Japanese university stood out to me because I also lived in Japan for a bit, and we talked at length about that. And then you brought up that you had also worked in hospitality for a while. I used to work in hotels.
Amanda: That's right. We both did. We both worked in hotels, which I think is so important. I think it brings that experience, and the idea you hear the customer is always right. But you really got to make sure that the customer had an amazing experience, and that was really in your power firsthand.
Jonan: This is a different expression in Japan. So in the U.S., we say, "The customer is always right," but in Japan, they say, "The customer is a God." They're polytheistic. And the customer is a God, I think is a little closer to the hospitality definition of this thing because really when you work as the concierge at some hotel, if someone comes in and wants something, the answer is never no, it's a creative yes. "Yeah, I hear that you'd love it if we had a waterfall in our lobby next week, but that's a short timeline for us. What we can do is I'll have someone stand there and just pour tea out, and we can get the sound effects; how would that work for you, customer?"
Jonan: You are constantly looking for creative ways to solve people's problems, and that is very much a transferable skill to any industry but especially in tech.
Amanda: Absolutely agree. I love this. I'm envisioning you with --
Jonan: Just standing with the tea.
Jonan: "Faster? Slower. Okay, slower, yeah. More gurgling, got it, yeah."
Amanda: I think that should be one of the next videos you stream.
Jonan: Just me streaming water.
Jonan: Yeah, very peaceful water pouring. So now that you are working here on the DevRel role and you mentioned this DORA thing, the DevOps Research, and Assessment, an organization that was acquired by Google and produces the State of DevOps Report. So you've been working with that lately. What is the state of the State of DevOps?
Amanda: So when you think about the State of DevOps and DORA, they've been running this since 2014. DevOps has over the last several years -- We always love to say if you ask somebody, "What is DevOps?" If you're in a room with ten people, you'll get 27 answers probably, right?
Jonan: [laughs] Yeah, that's more.
Amanda: What is the State of DevOps? Well, we know what it was in 2019 because that's when the last report came out, and then we published an ROI report in 2020 because it was 2020. And they'll be working on the next report soon. But I think what we're seeing as we talk with customers using the DORA research -- We have a quick check that allows you to go through and answer questions about your lead time and your deployment frequency. But what you're really doing with that is creating conversations within your team and ideally, not just in the team you work in, so not just your dev team or your Ops team, but that you're including the sales team, the product managers, the project managers, the support team, and really building a shared language across your team of understanding what does it actually mean for your organization to deliver software out to your customers?
Jonan: This is a really interesting point that I think is often missed. It is a common conversation on this observability podcast that it's all about humans, and instead, we talk about humans. So let's do that again because I actually think this is a really important point that when you're talking about finding shared language, you are talking about the value of communication in observability and how important it is to get all of the people in the room rowing the boat in the same direction. Because without that, you're not really going to achieve your goal, and you're not going to get the value out of what you managed to achieve either.
Amanda: Right. I think so often when we think about observability, the metrics historically that we've used to look at that it meant something to few of the humans in our system. But it didn't necessarily mean something to our customers. Like, they probably don't care about how our CPU utilization is doing, right?
Amanda: But they do care if they can't log in. And I think the same thing with your product managers or your support team; they want the same outcomes. Like, we all want the same outcomes. But being able to understand what metrics we should be looking at and how we create observability that allows the entire team to work together and make decisions together using that same language.
Jonan: Yeah, that shared language helping the entire team make decisions about how they're going to achieve their goals together and even what those really are. You talk about the CPU utilization as an example, but even things like mean time to recover MTTR. Am I saying --
Amanda: To restore mean time.
Jonan: Mean time to restore, MTTR. This is measured and valued by some set of humans who are maybe not the same set of humans that are going to be using or operating the systems all of the time or certainly involved with the customer pace that is affected by the MTTR in the first place. I think this is a common example that we give about measuring the wrong kinds of things. How do you feel we're doing as an industry? If we look broadly at site reliability engineering and software development, I certainly think that this bridges that gap at a minimum. Then what sorts of things do you think we are measuring that maybe we shouldn't be?
Amanda: I don't know if I want to say the things we shouldn't measure.
Jonan: Okay. What sorts of things should we measure? I guess, is really more where I was going.
Amanda: What I want to encourage is that we actually have conversations about what we're measuring. I don't remember who says it, but it's like, whatever you start with, it's going to be the wrong metric, or it's not going to be the right thing to measure. And I think where we could improve the most is acknowledging that what we're measuring today and the dashboards we've put in place are maybe just a starting place and that we need to improve upon them. And that if we had more conversations about them and how they actually impact our customers, then we could measure more effectively. So I don't necessarily think that what we're measuring today is wrong or bad, but I think as an industry, we could spend more time being more inclusive of getting more voices and roles exposed and having conversations about does this matter to the customer, and what is the metric that does matter to the customer? And let's make sure we're measuring that. And then, on each team level, CPU utilization is going to matter to those subsets of humans, and it should matter to them. And that's awesome. And they can continue to get excited about that. And then there's going to be people on the other end of the spectrum that's going to get really excited about sales numbers. For each individual team, it's going to be something different. But I think when we look at observing our systems, really understanding what is it that the customer cares about, and how do we make sure that we have a metric that measures that and everyone across the org understands it and can have conversations about it?
Jonan: This actually has sparked an idea in my head that there are a lot of parallels here with Developer Relations, and the kind of work that you're doing now is exactly that thing. When you talk about the metrics and deciding what actually matters to the customers, for example, if you took that team that is focused on CPU utilization and instead held them accountable for sales, you would have a different outcome, I think. And this is a common problem in Developer Relations where there are a lot of things that a DevRel team does. And some number of those things land around the product and around popularizing the product and making sure it's easy to use. But I think the vast majority of the work that Developer Relations does is about showing up for the communities that we're a part of and being there as active participants, and adding value. So from that perspective, I think what you're really talking about in this case is the value that you can add to the customer experience and correlating directly to the things that you're measuring to match up with what actually is going to matter to the customer. Because while CPU utilization may not be optimal, if they can log in and they can use the product, and it functions approximately as it did before, they care less about that and more about some other metrics nobody is paying attention to that in fact, breaks their experience. Am I picking up where you're going?
Amanda: Yeah, absolutely. And also, when I think about those humans and when we think about Developer Relations and our communities, is we want them to feel valued, and we want them to be happy. And so I think when we can help them have what's important to make the system run effectively when we can build this perfect vision of observability that allows the business to understand that as well, so that everybody can share in the success of the customer's happiness and that they can feel connected to that as well if there's metrics where we're measuring it from a customer's perspective. So then the developer or that Ops person who's keeping it up and running can feel that same success and happiness. And whether it's the support team or the sales team, they'll understand and recognize how everybody's role is playing together to make that happen and that it's not like, "Oh, we're having an outage, argh." It's like, "We're all in this together. This is a shared effort." And I understand that maybe now we're not going to prioritize my new feature I want because what I really want us to do is to improve the infrastructure or the system, maybe fix those tests that we've been ignoring so that we can have better outcomes.
Jonan: This thing that we should be focused on collectively and we have shared ownership over I will give priority over my very important feature that I wanted to ship.
Amanda: Having worked in all the different sections of a company that delivers software, I think that everybody has positive intent, and it's when we don't have a shared common language across those roles that friction happens. But if we can have a metric that we can all understand and get behind, then we can have really productive conversations.
Jonan: Absolutely agree. Well said. I think the part where DevOps professionals need to turn to Twitter for their– is maybe less than ideal. This world, we have right now, wherein no uncertain terms, there are divisions within these companies that are actively opposed to each other. You have the engineer who wrote that code; it's their fault; they broke this system. And then well, this is the person who was supposed to keep that server up, and they didn't set up this thing, and so this broke. And sales is on the line yelling at everybody, or people are yelling at sales for not sprinting fast enough. And it's like, we're on the same team, right? [laughter] Can we just, first of all, agree that we're all working towards a common goal? And then we work to achieve that thing sends criticism really I mean, it's important to look critically at what you are achieving and adjust as necessary but not at the expense of the humans involved in the equation.
Amanda: And I think that the DORA research has when you look at it holistically, it's now broken up to I think there are 40+ capabilities that you can focus on. So there's transformational leadership. There's working in small batches, which as a side note, I was on vacation last week, and we got 10 yards of mulch delivered. And so I took that opportunity to teach my children how to work in small batches so that we could accomplish it because it was super overwhelming. I should send you a picture of this ginormous pile. But anyways, so whether it's working in small batches, you're working process limits. And I think all of those when you look at all of the capabilities together; it's all the teams have to come together within an organization to be an elite performer at software delivery and operations. And so the research over all these years it's small companies with large organizations, and it really boils down to -- It's not necessarily are you a startup, or are you a big organization? But if you are good at all of these capabilities, which really means you have to be holistic across the organization, you will be an elite performer. So it's not just one team; it takes all the teams.
Jonan: You had 10 yards of mulch?
Amanda: Yes. [laughs]
Jonan: For those who are unfamiliar with ordering things in yards, if you think of a pickup truck, a standard pickup has an 8ft. x 4 ft. bed, and if you fill it to the brim with mulch, that is one yard. You had ten pickup trucks worth of mulch delivered.
Jonan: You have a big yard, or else you just did everything four inches deep.
Amanda: We don't have that big of a yard. This was our second year putting down mulch. We added a couple of new places we put it. We had to put several inches down in some locations, but it felt very overwhelming when it was first delivered.
Jonan: I can imagine.
Amanda: But you do it wheelbarrow by wheelbarrow, section by section.
Jonan: My children would just fall into the mulch sobbing. They'd be like, "You can't make us do this."
Amanda: [laughs] I'm not saying that didn't happen.
Jonan: Yeah, right? That's exactly how it would go down at my house. And then they'd be like, "Dad, can I help with the mulch?" And I'm like, "Yes." And we find the gloves or the tiny gloves, or you go and buy some work gloves. "I got you your own shovel, kids." And seven, eight minutes in, they're like, "I'm tired. Can I go take a break? I'm just going to go rest for a little while." I've got the next five hours here. I'll just keep shoveling.
Jonan: So this analogy, though, is actually really interesting, the too much work, the divide and conquer approach to these kinds of things because the other piece the communication gives you is that collective shared momentum that can come from actually knowing where you're trying to go. These are fundamental leadership principles when you talk about getting the ship going in the same direction and making sure everyone is aligned with the same vision. And we're basically talking about applying that same thinking to some very concrete numbers aligned with your DevOps goals as an organization, right?
Jonan: It's a smart way to handle it. I hope that there are fewer wheelbarrows involved in the DevOps work.
Jonan: But in the report you mentioned in 2020, you had the ROI. You had the work published.
Amanda: In 2020, we published the ROI of DevOps transformation, and you can access that at cloud.google.com/devops. And there, you can also take the quick check, and that will give you the baseline of where you are today as far as your DevOps, you know, your software delivery and operations performance. And then all of the capabilities that you can focus on to improve your software delivery and operations is available there too.
Jonan: Amanda, is there anything else that you would like to share with our audience before we depart?
Amanda: I think that in the next year, we will spend more time as an industry really thinking about how we communicate and collaborate together as we look at coming back into the offices, potentially. I think there's been this interesting shift where everyone has been working from home, and we've made that work, but I think it's really highlighted where the challenges were. And so I think as an industry, when you think about the DevOps Culture, I think we will spend time thinking about the humans and what do the humans need to be successful moving forward? I think historically, I feel like we knew we needed to do that, but this last year gave us that opportunity to realize how important the humans are. So I think you'll see a lot more collaboration and discussion in the industry about how we work together and collaborate.
Jonan: This is, I think, a very achievable prediction. I certainly hope that you're right. A year from now, if we look back and, in fact, it goes the other direction, I'll be very disappointed.
Amanda: [chuckles] I also hope that my -- I would like to make a prediction that we will get to experience the old days of hospitality that we will be going and staying in hotels again because we will be traveling again, and we will be seeing people in person I would hope.
Jonan: You and I may someday even meet in actual restaurants somewhere and sit down for a meal.
Amanda: That would be incredible. I believe it will happen. Hopefully, it's in the next year. We will see.
Jonan: Yeah. It's hard to say. Right now, where we are, I think it's hard to predict. We are seeing mixed results with this whole vaccine. If you're thinking about it, if you're listening to this podcast and you're maybe on the fence, get the shot, please.
Jonan: For the love of all that is good, go out and get a shot in your arm so I can go outside again, please, please, please.
Jonan: Okay. So one last question, if you were speaking to a younger version of yourself and/or someone who aspires to be in your position as many of our listeners I'm sure do, what advice would you have for them, someone starting out earlier in their career? And not necessarily that you would regret anything but things that they should pay attention to. I feel like we are the product of all of our experiences. So I don't think we should be looking back with regret, but I would definitely have told a younger Jonan maybe to get into that programming thing a little bit earlier and less of the poker playing, but I do appreciate my poker knowledge today. So it's hard to say.
Amanda: So that's funny because I feel like my advice may be the opposite because I think there's pressure like, oh, learn to code and go into tech, and tech is what you need to do. And I think that to my younger self, I would say, "Just keep following your passion, and it will come." Like, I think I was so passionate about technology when I was little because my uncle was an engineer, and then I hit 15, 16 and decided that wouldn't be cool. And so when I went to college, I pursued International Business and Accounting and Japanese, and that led me to work in hospitality. But then, ultimately, I ended up at an e-commerce platform development company, and I realized that tech is what I love. And so I think had I not gone along that journey and just followed what I was passionate about at the moment, I think I wouldn't have gotten here. So I would tell my younger self to maybe don't be so focused about the 10-year plan, learn, make sure you're learning, be in a role where you're learning, and really enjoy the people you're surrounded by, and the rest will follow.
Jonan: This is really, really good advice. Don't take my advice, young Jonan, if you hear this podcast.
Jonan: Computers are terrible. The end of the story is everything is awful. Please don't learn any computers.
Amanda: I still encourage people to learn to code, but I think the humans, right? I think if you work with awesome people, which I get to do every day, everything else is great. So whether you want to code, or you want to work at a front desk, or maybe the lovely people outside that are fixing my road as long as you're working with awesome people and loving and what you're doing...
Jonan: Keep doing you. You'll find your way eventually. Experience is additive, and I don't look back with regret on any of the experiences I have because they managed to make me. Maybe just a little less poker, though. I feel like there was a lot.
Amanda: I think the poker was good.
Jonan: Yeah, the strategy is good. Maybe Magic: The Gathering. I've spent hundreds and hundreds of hours on that. Whatever it is, don't worry too much about getting to where you're going. Just know that it will come to pass. You will find your place. For now, focus on happiness, optimize for happiness.
Amanda: I got to spend the last seven years at Google and the last six months being in this role. And I really do feel like I'm living my best life right now.
Jonan: I have to agree with you. It was an absolute pleasure to meet you, Amanda. If people wanted to look you up on the internet, where would they go?
Amanda: So they could find me on Twitter. I will fully admit that I am more of a consumer than I am a conversationalist on Twitter. They can always D.M. me @swansama, but it's S-W-A-N-S-A-M-A.
Jonan: Swansama on Twitter.
Amanda: On Twitter.
Jonan: It's the easiest way to get a hold of Amanda. Thank you again for coming on the show. I look forward to having you back.
Amanda: This has been great.
Jonan: Dear listeners, we have reached the end of this episode, and I once again remind you to go and register for FutureStack because there's lots of silly fun on The Relicans track, which is called Nerd Island and should be a hint as to the contents of this. There may or may not be a virtual cute animal island platform involved in the delivery of this conference. So you definitely want to investigate at therelicans.com/futurestack. And with that, I hope you have a lovely, lovely day. Take care.
Thank you so much for joining us. We really appreciate it. You can find the show notes for this episode along with all of the rest of The Relicans podcasts on therelicans.com. In fact, most anything The Relicans get up to online will be on that site. We'll see you next week. Take care.