Bridging the Gap Between Customer Support and Engineering With Rachel Stephens

Transcript

Kat Gaines: Welcome to Page it to the Limit, a podcast where we explore what it takes to run software in 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, Kat Gaines, and you can find me on Twitter, @strawberryf1eld, using the number one for the letter I. Okay folks, welcome back to Page it to the Limit. Again, this is Kat Gaines, I’m your host. So today we are chatting about communication between customer support and engineering, a topic I’m pretty excited about. We’re talking about bridging the gap there. We’re talking about how being able to do that will manifest in critical moments, for example, when you’re in the middle of incident response. And for folks who know anything about me or might have heard at least one of the other podcast episodes that I’ve hosted, you might know that my background is in leading tech support teams. So I’ve seen multiple iterations of really how relationships are built across the two orgs. And it does take a lot of time, it takes a lot of negotiating, a lot of trust, et cetera, to affect just the transparency, the in sync style of working that we’re talking about aiming for. But it’s really worth it. So with me, I have Rachel Stephens from RedMonk. Rachel, welcome to the podcast.

Rachel Stephens: Thank you so much for having me Kat. I’m Rachel Stephens. I am an analyst with RedMonk, and at RedMonk we focus on kind of practitioner led technology adoption trends and how that impacts how technology kind of propagates throughout the industry. But prior to working at RedMonk, I have a background, I just today actually was called a “recovering” DBA. So I’ve done kind of that user-facing, everyone gets grumpy at you because it turns out that nobody actually likes DBAs. I didn’t realize that until I left the DBA world. I came to the other side. But it’s one of those ones where I’ve definitely been in the place where I have been on the providing support for software for internal users. And so I’m very excited to talk about these intersections of how these groups can work together more effectively.

Kat Gaines: Yeah, I think it’s probably good for you maybe that you didn’t know that until after. Sounds like you were in the moment.

Rachel Stephens: You’re either a really good DBA or a really clueless one and I don’t know. I’m going to go with I was really, really good.

Kat Gaines: That’s perfect. So just to get us started, I think that when we’re talking about relationships and perceptions maybe of different teams and we can really talk about just the challenge we’re discussing here, which I think one of the biggest ones is: silos that exist between teams and different sides of the org. So if we can talk a little bit about why those silos exist, especially when you’re talking about between customer support and engineering or product, I think that there can be stigma that exacerbates that. I am personally spending a lot of time these days, and I just gave somebody a slap on the wrist in a doc the other day, to stop talking about engineering and CS in the same sentence by calling them technical or non-technical, especially calling customer support a non-technical team. It’s just not true, for one thing. And it’s a slant that really just will harm credibility with the CS community. And then it’s also one that if you keep saying it, whether it’s in your marketing materials or wherever else it is, it’s one that engineering teams can be misled to believe. And that really is something that I find can deepen silos a lot, that you might have someone who says like, “Oh, I didn’t know that that person could code,” when “engineer” is literally in their title in the support org. Or who will just say, “Oh, we’ll just handle this because we don’t think there’s anybody on that team who’s able to deal with it.” And then they’re surprised when, guess what there is. It is technical staff. And that’s one of those things that really can just put a wall between the two sides of the organization.

Rachel Stephens: Yes. And I love the word stigma that I think the place where I first kind of encountered a deep discussion about this was actually when I was prepping for this and I was listening to back episodes of Page to The Limit and you had the “Support Career Stories” episode with Pablo Gonzalez from Salto. And he was talking a lot about these misconceptions about what support is and how support engineer isn’t like a, quote, unquote, “real” engineer. And there’s this stigma around skill and technical ability. And I think that it’s such a harmful way for us to view our teams overall because I think one of the things is, one, it’s not true. There’s a lot of technical ability that exists on our support teams. And two is the other discussion that you all had on that talk about the importance of human-centered skills. And I love that you don’t call them soft skills and kind of this focus on empathy and communication and communicating technical information with other people who may or may not have the same background as you. All of those are really important. And so if we get to a point where we are valuing one team, one over an incorrect assumption of what the skills are or two, an incorrect understanding of what skills are valued, it creates a lot of problems in terms of how we can actually cooperate.

Kat Gaines: Yeah. I think it really does, and I really like you calling back to that because that’s another thing that again, when I see somebody say soft skills, I always question, are they really soft? Because some people find them very hard to learn, I think. And that’s okay, we all have different things that are challenges for us. A challenge for one person might be a technical skill. A challenge for someone else might be some of those human-centered skills. And there’s no shame in that. It’s just that we all have our learning curves and there’s no harm in just admitting that and then using that to say, “Hey, this is something I need more help on. Can we work together? Can we build our relationship over that?” And that’s another thing that can maybe help start to break down those walls a little bit. Right? Yeah, I really love that you called back to that episode, that conversation with Pablo and Isabella and Andra was just so fruitful and full of goodness. And I was worried I’d feel like I was talking into an echo chamber because it’s just like we all feel the same things about this, but it was a really good conversation. That’s sparked a lot of thought for me.

Rachel Stephens: I would second that and I would recommend people go check it out because it has some lovely stories in there.

Kat Gaines: Definitely. So let’s talk about breaking down those walls and silos a little bit, I think.

Rachel Stephens: Yes. What I think is really interesting in our industry is that we have spent so much of the last decade, I want to say, talking about the DevOps movement and talking about this important cultural change that needs to happen in our organization to ship software better or we’re not throwing software over the wall from development to ops. And we have this shared understanding of each other’s pain points and we have this shared ownership over software performing well. And I feel like as an industry, it’s kind of become something that has general levels of acceptance in most circles that yes, we can’t operate in complete silos, we have to have this shared understanding of how the software actually runs. I think that’s all to the good. What I think is curious is that silo continues, the silo mentality continues to exist in so many other groups. It’s not just dev and ops that needs to have these walls torn down. It’s dev and what we’re talking about today, is the customer support teams. It’s your devs and your engineers. Engineering can’t exist in its own bubble and we do have to start finding ways that we can interact across teams in a more fruitful way.

Kat Gaines: Yeah. I think that’s super important to remember that no team can exist in its own bubble, really. Even if you do the majority of your work within your department, across teams, that’s fine. But you will eventually have to touch another team. And so when I worked within support, every single team in the organization was a collaboration partner because the types of questions that you get come across every different side of the organization in terms of who needs to offer up resources to help answer them. Your support teams will know a lot, but they can’t possibly know everything. Otherwise, they’d be doing every job in the business. And it might be a little chaotic because that’s a lot for a small team to do. But yeah, I think that what you’re saying too is that it can be really easy to talk the talk and sometimes a little harder to walk the walk when you get outside of who’s immediately around you. And so I think it’s a lot too, around just kind of understanding why that can be hard for some folks to grasp a little bit. I think there can be a lot of fear that plays into it, that for example, if I’m an engineer and I’m being asked to give the customer support team more access to file more tickets directly in my systems or to get more involved in my processes and really just kind of get in there in what I’m doing on a day-to-day rather than just being someone I communicate with when a bug is fixed or something like that, I might worry that the systems might be overused or abused, for example. That suddenly I’m going to get a barrage of tickets asking for things where if they might not have had that access previously, it would be a little bit more metered and have some checks in place. I might be worried that I’d be asked to jump on calls with customers to explain what’s going on. Imaginations can kind of go everywhere, and not that any of those things are inherently bad, it really depends on your organization itself. But I think it’s about kind of addressing those fears a little bit and talking about how do you do this in a way that keeps everybody’s jobs feeling safe and protected and that you still feel like you’re going to be able to focus on your important work. But then you also have the benefit of: you’re building a good relationship across the business. Taking that first example that I brought up, if you’re giving your customer support team more access to file tickets for your team, how does that work? In what tool are you doing that? Are you introducing a new tool? Are you sharing some tooling? Are you building partnerships that support not just that tool access but the overall process and how it’s built? So something I like to talk about all the time is something PagerDuty built when we were really small, which was our support ambassadors program where we assigned basically one person from support to one product and engineering team and they would be embedded within the team to go participate in some of their planning process and really understand what it is they’re working on, become kind of a subject matter expert in that area, and become kind of a subject matter expert in that area and then bring that information back to the team. Which then has the really nice effect of reducing the team going to that engineering team all day every day, asking questions about this part of the product, how does it work? Instead, they have somebody within the team that knows a little bit more about that part of the product and they can help inform them. So there’s a double component to it, I think, which is the process that you implement, the tooling you implement, but then also the relationship building that you implement and going about that really intentionally.

Rachel Stephens: Right. I love that story because I think it touches on two of the things that I think are important here, and I think one, kind of ties back to that original stigma that you were talking about. It’s like if you are not someone who’s already started to build those relationships and you don’t understand that your support team, one, has good insights, and two, has the ability to communicate what they need to you in a way that is helpful, it makes sense that you would have this fear of I do not want this barrage of tickets coming in from these people who aren’t going to understand and the tier one support kind of things. “I want someone who knows what they’re doing.” And so if you’re coming from a place where you don’t think your support teams know what they’re doing as an engineer and you’re kind of having that, I want to say hubris is maybe the right word, of this lack of understanding and maybe lack of compassion. One, I think that’s part of the driver of fear, it’s just not having that shared compassion, shared understanding. And so I love your ambassador program example as a way to, one, build those relationships, two, prove that shared value to both teams to create those pathways for communication, to create ways in which there’s not going to be a barrage because you can kind of have a point person. I think all of that is amazing in terms of helping overcome some of those things. Because I think the second thing then is shared processes and kind of a trust of your tools and processes. Because I think a lot of teams, ticketing processes, alerting processes can be really fraught. So they can be noisy, they can be overused, they can have things that linger for a really long time. You can have alert storms, all of these things that create pain in an engineering environment. It makes sense that if you’re in a place where you don’t trust your system and processes to work for you, adding additional inputs can be scary. And so I think it’s both of those things. It’s like can you create that relationship between the teams and do you have systems that can work with this?

Kat Gaines: Yeah, absolutely. I think so. I really love your point about just the compassion and I think shared compassion because it’s really easy to get caught up. From an engineering standpoint, I think it’s very easy to get caught up in like, “Ugh, God, customer support is so annoying. They failed another ticket or they’re asking for an update on this ticket. I want to go actually do the work I intend to be doing. I don’t want to be doing this interrupt work.” And then from the customer support perspective, the compassion can be lost in, “Ugh, engineering isn’t doing their job, they’re not updating it.” Without the visibility of the priorities on each side. The customer support priority is to go to customers and keep them informed with timely up-to-date updates on what is happening. Even if we don’t have an answer right away, you really need to just always let them know where things stand so that they don’t feel out in the cold. And then for the engineering side, the priority is yes, making sure that bugs and things are fixed, but then also making sure that the roadmap work that you have is happening and that it’s moving along. And sometimes that’s pretty strict and there isn’t always visibility. So the more that those relationships can be built, the more that understanding can be built. The other thing that I always recommend people do, if they have the opportunity, and for engineers that I think for anybody in an organization is go shadow your support team for a day. Just go hang out with them. When I was running PagerDuty support, we had them answer tickets. I don’t know if that’s how they do it any longer. It sounds really daunting and scary, but it was always actually pretty fun. And we had people talk a lot about how much they learn from it. And it’s a really good way to get an understanding of what is going on with your customers firsthand because you’re seeing them in their moments of emotion and sometimes pain. And then it’s a good way to build that relationship if you need to have a good working relationship, which again, I’d argue everyone in an org does with your support team and really understand each other and spark more great conversation about how to do that.

Rachel Stephens: Yes. And I love that you kind of talked about some of the support stressors. It’s like you’re probably inherently dealing with customers who are in a hard moment where something is not working, something is broken, they have something that needs to happen. Their customers are probably not being their best selves while they are interacting with the support team because-

Kat Gaines: Not always.

Rachel Stephens: Not all the time. I would hope that we would all try to be our best human selves all the time, but that doesn’t always happen.

Kat Gaines: No.

Rachel Stephens: And I think especially when people are stressed and under the gun and something is broken or not working as expected, that tends to not be our best human selves most of the time. And so there’s some compassion for your support team and understanding that that’s the environment that they’re living in. And then the shared compassion for, “I have a sprint that I’m trying to finish, or I have a feature that needs to get out the door. I have all these competing priorities.” So understanding the pain points of each other’s team I think is really huge for actually breaking down that barrier. And I love the idea of having a sense of shared priorities because I’m not sure that that is something that organizationally, I think figured out the right way to do, for a lot of enterprises anyways. It’s really hard to have that cross group visibility into what other people are doing. It’s just really hard.

Kat Gaines: Yeah. And I think it’s really important to be able to do that. That’s why I think it’s wonderful when people follow the recommended practice of sharing goals org wide. And there are a lot of tools set for however you goal set, whether it’s V2MOM or OKRs, where you can mark a goal private. And I hate that button because I think that everybody should have the visibility in what everyone else is doing. And fortunately, I’ve never been in a situation where I was in an org that was actually using that button even if it was available. But I think that it’s just silly to not have that visibility into what the goals and what the priorities are. And so it should be at that level of the more formal goal setting. It should be in the conversation about how you work together regularly. I think the other thing to understand too is that priorities change. So for example, if there is a feature that, let’s say you’re a customer support agent or a customer support leader and there’s a feature that you know your customers want to see updated or they want to see some changes made to, and you’ve been told that it’s a priority for next quarter. And that’s great, that’s exactly what you’re hoping for because you would make a bunch of customers happy if that update happens. And then something higher priority comes along and changes Product’s roadmap. It is going to happen. It has happened to me and it has happened to everyone I know pretty much. And there is really no way of avoiding it. It’s really about understanding why this thing is higher priority. Maybe it’s some kind of compliance thing. Maybe it’s something that’s really, really urgent and it has to get done. And then working with those teams to make sure that you’re messaging to customers is something that can explain that. Even if you can’t give away every detail of what’s happening and why it got reprioritized, make sure that they still know that they’re being heard, that they’re not just dropping feature requests into a black hole, for example, and just being in sync with what those priorities are across the business.

Rachel Stephens: Yes. So I’m going to ask you a question from your support days. So I’m wondering, as someone who worked in customer support, when you’re trying to find that balance of the right level of information to share with a customer, what level of information did you need from your engineering teams in order to translate, or from your executive? And we’re talking about you need to balance what you’re sharing. Do you want the engineering teams to give you these barrages of information and you kind of pick out what’s important or did you want your engineers to tell you the summary that you can pass on? Whose job is it to do the filtering?

Kat Gaines: Yeah. It’s kind of everyone’s job. And I think what that means for me is that engineering can share the full context with customer support of everything that’s happening, what we would want to share publicly, what you want to just share behind the scenes. And having a shared understanding of what messaging looks like. So whether you have templates that you follow in your org for how you send out messaging around something that’s going on. One of the next things I want to talk about probably is incident response process and how that works, and there’s a little bit of that in there. But some general guidelines too for that communication are using, for example, your support team to help inform what level of information your customers can take in. So in some businesses, that might mean assuming that your customers are more technically competent than they are or being reminded that they are. For example, if all of your customers are engineers, they’re going to ask for some technical details. If you get a glossed over version of what’s going on, they’re going to call that out with your support team and they’re going to say, “No, no, I need to know more of what’s going on.” And you might not be able to dive into every nitty-gritty piece of what’s happening, but you can be reminded that if there is something you can safely share without setting expectations improperly, for example, that you should be sharing it. And so it’s about having those guidelines of who your customers are, what type of information they’re going to want to know, what they’re going to challenge your teams on, and then having a shared process across your teams for saying, okay, here’s what we want to share. That might involve templates. It may involve at least some responses that you have outlined where you have just a bigger kind of set of not just templates, but how you talk about certain things, like guidelines for communication. But then agreeing on those things too across teams. So for example, it’s not either teams responsibility to come up with those things on their own, but teams have to have basically SMEs who work together to make sure that these things are in place as part of the process.

Rachel Stephens: Fascinating. Okay, so I’m really excited to move into the incident response part. So is the role of the incident commander then going to be like the sole touchpoint into your customer support? Is that the ideal way that this would work if you’re in an active incident?

Kat Gaines: Yes and no. So we have a lot of, obviously because of the nature of what PagerDuty is and what we do, we have a lot of stuff out there published on incident response. I’ll drop some links in the resources for folks later on what to check out in terms of if you want to walk through best practices. Really, we recommend having a customer liaison who is, for example, in your incident call. And so they’re going to go to your incident commander for decision making, but they’re going to be in the conversation with everyone. So if a subject matter expert can give them some information, that’s helpful. And then they’re going to be the ones who are able to both bring information into the call. So they’re not just looking for communication and templates and things, but they can say, “Okay, hey, here’s some context about what we’re hearing on the customer support team. We’re getting this many reports about this. This is what’s happening.” Maybe we’ve brought it into some tooling that we’re using shared. So for example, we might be using PagerDuty as shared tooling to manage incident response and we’ve linked up our support cases to this incident. So you have some visibility around that. But then we can also report on it live in the call in the moment. And then they’ll work with the incident commander around language. So again, as a best practice, templates for incidents so that you don’t have to come up with everything on the spot, you can kind of fill things in madlib style. We have some great features in PagerDuty that help with that. But being able to say, okay, what’s the context? What’s going on? What do we think about our next steps? So as you’re writing those status page updates or as you’re writing those updates in emails to customers who have reached out, there’s an agreed-upon language around what’s happening. And you can also be the one, if you’re the customer liaison, to share that out with other customer facing teams, the rest of customer support, folks in sales who might need an update, executives who might have folks reaching out to them, so that they don’t have to then come in and say, “Hey, what’s going on?” I think there’s nothing more stressful than executive swoop in an incident call when you’re just trying to remedy things. And you can really be the person to own the communication and updates so the incident commander can continue commanding the incident and making sure that we’re driving toward resolution.

Rachel Stephens: Yes. Thinking back, if we go back to my question of how much information should the engineering team be sharing with the support team was probably based off of my understanding of how much information should the engineering team be sharing with the executive team, who is breathing down their neck during an incident, which is very much you should be sending a filtered view. You should not be sending everything.

Kat Gaines: Exactly.

Rachel Stephens: Yeah. It’s interesting because communicating out and communicating up is going to look a little bit different, it sounds like.

Kat Gaines: It is. It definitely will. So you might give your customer support team a little more information for customers than you would necessarily give the exec team right away. And execs, that’s not to say that you shouldn’t have information, but it’s to say that you should trust your teams to do their jobs. And you shouldn’t be jumping into the call and saying, “Hey, what’s up? Talk to me about it.” Yes, you need an update, but you should have process and tooling in place that lets them filter the relevant information to you so that you can say, “Here’s exactly where we are,” at any given moment that you need it, and they can still continue doing their jobs. So really, it’s about having that tooling in place. And then it’s about understanding the types of information. So customer support is going to need to be able to tell customers kind of what to expect next, workarounds to try. And then if you’re filtering up to stakeholders, like executives for example, it’s going to be more just kind of what’s the status of the thing, what do we expect next? And it all boils down to the same issue, but it’s just different views on the information.

Rachel Stephens: Yeah. I think that’s an excellent way to kind of frame it, which is very helpful. I’m curious, so if we zoom back out from not just an incident, but kind of forging these cross-team relationships, how much of this is coming from a bottom-up, peer-to-peer talking to another versus top-down executives are helping teams break down these silos? Have you seen one versus the other or success one way versus the other way?

Kat Gaines: I have. So I actually worked in a company at one point where the customer support team and the engineering team didn’t communicate at all. And gosh, that was stressful and it was different in terms of the type of business than what PagerDuty is. It wasn’t the same size, it wasn’t the same setup, it wasn’t a tech company, per se. And so the needs, sure, were a little bit different. But it did really make it hard to get issues resolved because there were still websites with components that would occasionally not work, and not being able to just talk directly to engineering was difficult. And that was a top-down decision. And I think that had I been there a little bit longer, I probably would’ve advocated for some process and some change, but I just ended up moving on in my career. So I’ve seen that side of it where there was top down, this is exactly what we’re doing and the individual contributors had no say. And then I’ve seen environments where really, everyone’s involved. So there can and should be leadership influence in the process. And I said that carefully does not say that there should be top-down influence, but there should be leadership influence in the process. But there really needs to be individual contributor influence in it as well because they’re the ones who are going to be closest to the issues. So even if I’m a leader of a support team, for example, I’m not in my team’s tickets all day, every day. I’m doing my job, enabling them to do their job, I’m helping manage them, I’m coaching them, I’m working on issues that have been escalated. So I really just get a filtered view of a couple of things. But they’re the ones who are really intimate and up close with what’s happening on the day-to-day and what’s going on with our customers and as a result, what their needs are for communication and partnership with the other side of the work. Same thing on the engineering side. If I’m a manager on that side, I’m doing the same things. I’m working on coaching and developing my team as one of my main activities. And my engineers are the ones who really know what their day-to-day looks like and what they might need in terms of how their time is used and how they work with other parts of the org, in terms of what customer insight they would love to see to be able to do their jobs better. And so those folks have to be really actively involved. I am a pretty big fan of never doing anything just from the leadership perspective because you just don’t have the lens to know. You can be the best leader in the world and you still really don’t have a clue of every single thing that your teams are going through on a day-to-day basis. So it has to be both, I think maybe a little bit more primarily individual contributor driven, in my opinion.

Rachel Stephens: Wow, that’s a great insight. Thank you. I feel like I might have derailed us a little bit from what we intended. I just got excited.

Kat Gaines: Yeah, that’s perfectly on topic. This is the stuff we have to be talking about because it’s about relationship building. That’s the whole piece of what we want to talk about today. And so yeah, I really think that to bring everything home here, if we’re talking about just understanding and building these relationships, it’s about understanding our teams. It’s about understanding the people in them. It’s about understanding what they’re doing on a day-to-day. It’s about understanding who your customers are and what their needs are. And then letting all of those inputs influence how this happens. But really focusing on the compassion, the empathy building, which are just some of my favorite topics to talk about. Honestly, I feel like a broken record at this point, but it’s true. And really focusing on making sure that you have tools and processes that just support that happening. Because at the end of the day, if you’re not sharing some tooling, if you don’t have some similar process, you’re not going to have that nice view. And so as much as you can, integrating tooling, pulling things in. Talking in real time about what’s going on too. So I think one thing that we probably didn’t touch on too much is how you communicate in real time. And just some quick thoughts on that from my side or we talked about incident calls and how productive those can be when you have a customer liaison in the call. But then there’s also the usage of tools like Slack, for example, where you can communicate in real time, whether it’s an incident and you might have just a running log because you have a scribe writing down what’s being said in the call. And that’s helpful if you’re not the person in the call yourself, but you kind of just want to follow along and maybe help your teammates out by getting real-time updates from looking at that. But then on a day-to-day too, just having a place where you are able to chat about what’s going on. So I’m a big fan of the PagerDuty and Slack integration as one of our integrations because it’s a really good way to get a view into what’s happening in PagerDuty, and not have to necessarily leave the tool that you might be already working in all day. And so I think as much as possible, integrating tooling and bringing everybody into just the same view of things can be incredibly helpful.

Rachel Stephens: Yeah. The power of shared context is huge and shared context and shared processes where we understand this is how we’re going to work together, these are the methods that we’re going to communicate with one another. These are the kind of point people that we talked about in various scenarios that are going to be in charge of leading communication. All of that is so huge in terms of actually fostering good communication.

Kat Gaines: Yeah, exactly. I want to move to a couple of questions that we ask everybody on this show, and I’m going to throw these out to both of us. What’s one thing that we wish, and Rachel, you can go first, that you wish you would’ve known sooner when it comes to this topic, collaboration between different sides of the org?

Rachel Stephens: Mine is going to come in the form of a story. So I became a DBA from being the user of the database. And so I was on the finance team and the financial DBA left. And rather than bringing in someone from the outside, they decided they wanted someone who kind of understood the impacts of using all of the data and the financial reporting to be in charge of the system because they didn’t want anything to go sideways in their external financial reporting. Totally fair. So I came in, I learned the database. And I came in with the total perspective of the user and all of the things that used to drive me crazy about the system. It drives me nuts when things update without me realizing it. I had this list of pet peeves. And then I came in and I learned how to be the DBA and the systems and I understood what created all of those things. And so it was this mishmash of understanding where the user’s coming from and then also understanding what the system drives are that create the problems. And so I felt that really upfront. But for me, I came over very much starting with that user-centric thing. And so I had a little sticky note on my monitor that said, “You are only as successful as your least successful user.” Because I was like, “I’m going to be very customer driven.” And it turns out that there are some really unsuccessful users out there.

Kat Gaines: Yeah.

Rachel Stephens: You can’t tie your total view of your own performance to that metric. That’s not a good metric for your own person. But also being able to find that balance of, I really want to focus on what it means for my customers to be doing well to be successful. That’s very important. And I think everyone struggles to find that balance. But me especially, in the beginning, I wish I would’ve found that balance earlier of how can I be customer focused without feeling like I am a failure anytime somebody can’t use my system well?

Kat Gaines: I think that’s beautiful. I wish you would’ve known that sooner too. For me, I think it’s maybe just a word of caution that I want to give to folks who are in the support world, who are either individual contributors, or are a little earlier in their career maybe. So I mentioned in that past job where I wasn’t allowed to talk to engineering as a support agent. And to heck with that, that’s ridiculous. The thing I wish I would’ve known sooner, slash the piece of advice, is to challenge authority a little bit. I think early in my career, I was very authority driven and very just ready to just do what I was told. And it’s okay to speak up and say, “Here are our needs as a team and here’s how we can do our job better and here’s how we can, by doing our job better, help the business do a little bit better.” At the end of the day, you’re protecting the business, you’re protecting the brand reputation. You are the first person that a customer talks to when they’re stressed out at any degree. You sometimes get the folks who write support tickets to just say, “Oh, we love the product so much.” It sounds fake, but it does happen once in a blue moon. But the majority of what you’re dealing with, we were both talking about earlier, is folks who are high emotion, probably in a difficult moment. And so you’re the person who’s going to allay their fears about whatever’s going on. And so if you don’t have the tools at your disposal to do that, everyone’s going to fail. You’re going to be miserable in your job and you’re going to therefore, create miserable customers whether you intend to or not, if that’s the situation. And so being able to just advocate for yourself and say, “Here’s what I need to do my job well,” because if the business knows what’s good for them, they want you to do your job well. They want you to have the resources to do that. And so that shouldn’t be a tough conversation, even if it sounds scary. Challenge authority a little bit and say, “Hey, this isn’t going well.” Don’t wait for managers or team leads or other folks to speak up for you, do it yourself.

Rachel Stephens: Yes. And if you’re not somebody who is a challenge authority person, your manager can’t tell you who to talk to. You can send nice DMs, you can send over a gif in Slack to somebody and tell them have a great day. You can start to build those relationships yourself, even if it’s informally, because I do think that even if you don’t, like we talked about the importance of shared context, shared processes, like top-down and across org collaboration, that does matter. But also the human-to-human connection points definitely matter and you can build those all by yourself. You don’t need a manager to do that.

Kat Gaines: Yeah. You should be building those by yourself because that’s how you network and continue having folks in your career that you want to work with too. So it’s not even just about doing your job today, but thinking about your job long term and just your satisfaction, your working life long term. It’s getting to know and building great relationships with the other humans around you. This is the harder one, I think, but let’s do it anyway. Is there anything about the topic that we’re glad we didn’t ask each other about?

Rachel Stephens: The great news for me on this one is that I’m an analyst, and so part of my job is to just say, it depends. There’s a lot that I think running software and production and doing customer support is really hard. I think one of the things that I’m watching in the kind of broader landscape and ecosystem is some of these categories are collapsing into one another. So if you see automation tools and incident response tools and monitoring and alerting tools, this whole space has some interesting overlaps emerging. And so I’m really, really glad that we didn’t have to try to untangle any of that, I guess. I’m glad we kept it to a narrowly scoped topic.

Kat Gaines: Yeah, I’m glad we did too. And I think I’m personally also glad that we didn’t ask each other about some of the horror stories of tough communication and collaboration, because I feel like that’s just another episode. That’s just another day.

Rachel Stephens: Very much.

Kat Gaines: It can get tough, but we wanted to focus on the positives and how we can do things well for this conversation, I think.

Rachel Stephens: Yes.

Kat Gaines: So folks, for our listeners, we’re going to go ahead and drop a couple of links in the resources section, so do go check that out. We mentioned our response.pagerduty.com, our ops guide earlier. There’s a whole section on customer liaisons and how they should operate. And there’s also a newer section that we published, let’s see, I think it was around the end of October, that talks specifically about communication during an incident too, talks about building templates, talks about all of that wonderful human communication stuff that you’re going to have to figure out in that moment and how to go about it. That was a result of some work that the PagerDuty teams did internally and spent some time thinking about the process and how they make those types of decisions and saying, “You know what? We need to write up and formalize this, in internal process.” And then we said, okay, now we need to go update our ops guide in return because there’s a lot out there that folks can learn from. So go check that out. I’ll probably drop a couple of other things in there too, just around CS ops and collaboration between teams. But otherwise: Rachel, it was great having you on the podcast today. Thank you so much for this conversation.

Rachel Stephens: Oh, it was my absolute pleasure. Thank you so much for having me.

Kat Gaines: Fantastic. So folks, again, this is Kat Gaines and we’re signing off, wishing you an uneventful day. That does it for another installment of Page it to the Limit. We’d like to thank our sponsor, PagerDuty, for making the podcast possible. Remember to subscribe in your favorite podcatcher if you like what you’ve heard. You can find our show notes at pageittothelimit.com, and you can reach us on Twitter, @pageit2thelimit, using the number two. Thank you so much for joining us, and remember, uneventful days are beautiful days.