Support Career Stories

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.

Kat Gaines: All right, folks, welcome back to Page It To The Limit. Today, we are talking about career paths from customer support into mainly engineering, but there are a whole bunch of ways that can be twisted, and you’ll hear about that a little bit more as we go on. Just a quick intro on why we’re talking about this, personally, it’s something that I’m passionate about. I came from a tech support background before I moved into a Dev role. Our three guests have similar feelings, they feel passionate about it and have had some similar career paths. Really, customer support is a difficult role, no matter where you are, no matter how awesome your team is, it’s a really hard role. You’re feeling a lot of feelings from customers, from anyone who will take advantage of you lending your ear to listen all the time. But, it’s also a role that gives you a lot of expertise on the products you support and the customers who use them.

Kat Gaines: It’s a role that gives you that expertise in a way that other teams don’t always get the chance to. They don’t always get the chance to be that close to customers, to experience what they experience, to get to know their feelings so deeply and intimately. When customer support agents move into engineering, product, other teams in the business, they bring that familiarity to those teams. What we want to do today is talk about those benefits and we want to talk about some stigmas about people who come from a support background that we really want to squash once and for all. We want to talk about a lot of things, so let’s just get into it. We’re joined today… we’re lucky, we have not one, but we have three guests. We have Pablo Gonzalez from Salto, and then we have two Dutonians, that’s what we call PagerDuty employees internally, Andra Burck and Isabella Applen. Real quick, Isabella, I’ll start with you, just say who you are and what you do at your company for your listeners.

Isabella Applen: I’m Isabella, and I work on one of our site reliability engineering teams here at PagerDuty.

Kat Gaines: Andra, we’ll go to you next.

Andra Burck: Hey, I’m Andra. I’m a security engineer, and I’ve been at the company for about four years now.

Kat Gaines: Pablo, round us out.

Pablo Gonzalez: Hey everyone, my name is Pablo. I have a different title, it doesn’t sound as cool as yours, mine is business engineering architect, which I think is little bloated, but that is in a company called Salto, which is an Israeli startup. I’m actually quite new there, I’ve only been there for around six months.

Kat Gaines: Awesome. I’m going to disagree with you, I think that everybody’s jobs sound really cool, and that’s what we’re here to talk about. Just a level set for our listeners on what we mean when we say customer support, so customer support are your frontline people, they field questions from your customers, they help them solve problems, they troubleshoot things, they develop a lot of feelings about the product as a result. Their general duties involve, again, bringing those feelings back from customers into the business, letting your, in a software company, product and engineering teams kind of know what the pulse of the customer is. At PagerDuty, we actually used to have a newsletter called Pulse of the Customer that our support team published, so we could bring those insights into the business. Career paths is the discussion today for a lot of reasons. The job is really hard, as I mentioned earlier, there’s a really high burnout capacity after a few years.

Kat Gaines: It’s awesome to want to be career support, but not everybody wants to do that all of the time. For example, I had my entire career in tech support, so straight up college, I went into tech support, I bounced around a couple of different companies over a couple of years, I landed at PagerDuty. I went into leadership in tech support, I had a lot of fun doing it, but eventually I wanted to try something else, and so when the opportunity came up, somebody in our advocates team was moving on from the company and tapped me and said, “Maybe you should apply for my role,” I went ahead and did it because it sounded interesting. Public speaking is something I like to do, thinking creatively about how we solve problems is something that I like to do, and I saw a lot of opportunity to do those things as part of the role. It was a refreshing way to take the things that I loved about my existing job and expand them out a little bit more into something else.

Kat Gaines: Folks, if each of you could talk us through your career paths briefly, I’ll start with one of you, but then just jump in whoever wants to go next. Pablo, why don’t you talk us through?

Pablo Gonzalez: Yes. I’ve been in technical support for many years, I started right out of high school when I was 18 years old. I did technical support for cable TV, which is really tough. There’s a lot of feelings there, very upset customers. I did that for about two and a half years, then I moved to technical support for Salesforce, which is a business platform, and I did that for about five years. I was able to experience all the roles in technical support. I started in triage, then I did tier one, eventually tier two, then tier three support, and I ended up in mission critical support. After five years, I felt like I only knew Salesforce, so I moved to Marketo and I had a tier three engineering role there as well. That had been already too many years in support, and I really felt like I wanted to do something a little bit more challenging, not that support is not challenging, but just challenging in a different way, I guess a little bit more creative.

Pablo Gonzalez: I eventually was able to move to software development for the Salesforce platform. How I moved is a whole story that maybe I can talk about later, but that’s the gist. Then, for the last few years, I’ve been in software development specifically for the Salesforce platform, and that’s how I ended up in Salto because we have products that integrate with Salesforce and they needed a Salesforce expert in-house, and now I’m helping the engineering team, product marketing, pretty much everyone create the best product that we can come up with. That’s sort of the story, more or less.

Andra Burck: I had kind of a similar experience. I started out about eight years ago, and I was just building and repairing PCs at a little computer repair shop. After that though, I took on a support role at a mom and pop internet service provider, but they also had a colo facility and web hosting servers, so I ended up doing a little bit of everything. I did field operations, sys admin work, and obviously tech support for internet connectivity issues and issues with hosted websites and things like that. Then from there, I moved into another support role at my first SAS company, troubleshooting a JavaScript application. Then, after a couple of years of that, I joined PagerDuty as a support engineer, and I was a support engineer for a couple of years before I moved over to security.

Isabella Applen: Okay, I’ll go next. I went to a coding bootcamp in San Francisco and our main project was the fully functioning web app that we build entirely. We’re supposed to present our apps at a company in San Francisco, and for my class it happened to be at PagerDuty, and so I met people there at that event, then I started working there. I started as a support engineer and about six months ago, I transferred to one of our site reliability engineering teams.

Kat Gaines: We have a lot of different, but similar paths. I think what folks are probably hearing as they listen to the podcast is that there’s multiple ways to kind of get there and approach whatever it is that you want to do eventually. I’ve known a number of people who’ve kind of started out thinking that they want to do one thing and then they’ve done support for a while and eventually found their way to that thing, and it’s not always necessarily the linear path that you maybe had in mind when you started, but you get there eventually. As I was mentioning earlier, what you bring is really interesting to the team. Something else that kind of happens sometimes is that sometimes those moves can be a little bit difficult, sometimes they’re not easy to facilitate, whether you’re the person who wants to move, the person on the team that they want to move to who’s trying to help them, or their manager trying to make that move happen.

Kat Gaines: I’m going to say from personal experience from having managed folks moving to different teams from support, it’s always been creative, there’s never been one prescribed path that’s how we get here. Even at PagerDuty, we eventually developed a set of guidelines for moving between teams, but that came after a lot of just kind of, “Well, we’ll figure it out as we go along and we’ll just kind of make up whatever works and we’ll get people wherever they are whenever it makes sense.” Things happen just a little bit kind of off the cuff and randomly sometimes, and we had to be pretty creative to make some of those happen, but I think we learned a lot because of it too. I think other things that we learn sometimes are other people’s perceptions of what support is. We have people here who have had support engineer in their title and sometimes people and other teams look at that and say, “That’s not an engineer, you don’t know what you’re doing.” That’s a lie. That’s crap.

Kat Gaines: Anyone who’s thinking that, yes, support engineers do know what they’re doing. There are a lot of stigmas around what support is and how much skill people in support have, how much technical ability they have. Something I’m personally on a campaign for right now is to stop talking about support and technical staff as separate staff, because they are one in the same, but it’s something that people differentiate between quite a lot. There’s just too much exclusivity around career paths in tech sometimes, we treat it like this cool kids club that people have to try to get into. If you didn’t come from the right background, or if you didn’t follow exactly the path that somebody else thought you should follow, people might take you less seriously. I will personally admit that I’ve kind of shouted people down over the years about needing people to follow an exact path, to make sure that they’re exactly what they envision for someone on their staff, because again, those views can be really harmful, and what you bring to a team is different. That’s the most valuable thing.

Kat Gaines: Folks, I’m going to open it up to the floor. Who wants to share thoughts on just stigmatizing support agents, what teams should be looking at other than just the resume and the things that you’ve done, what else should they be looking at if they’re considering bringing somebody from support into their team?

Andra Burck: I can definitely talk about a couple of stigmas. I think you kind of hit the nail on the head though. One stigma, it’s probably the most common, is that if you’re in support, your communications are scripted and your technical aptitude is below par. It’s like this idea that if you’re in support, you don’t understand systems design, you don’t really know anything about networking, you probably don’t know how to code. That’s a big one. But, there’s another kind of stigma that I’ve been subjected to, and it’s like once you’re in a couple of support roles, it’s really easy to get pigeonholed into support roles. I can give you an example. My old director wrote an article about diverse hiring practices, and so I don’t have a computer science background so she mentioned me and my background. But after that, I received this massive influx of really low level support reqs, and it was super weird because it’s like, “No, I’m a security engineer.” That’s literally what the article was about, I can do more than just support roles.

Pablo Gonzalez: I’ve also experienced similar things. It’s also not what people think support is, it’s also your own perception, the imposter syndrome, I struggled with that a lot for many years. I would say that was probably the main driver for me to move away from technical support is I didn’t feel like I was one of the cool kids, I felt like I was doing support, I wasn’t doing programming or engineering stuff. I’m not sure what creates this problem or where it’s coming from, but I think there’s this misconception that support is somehow just not part of the software development life cycle, and anyone who’s created products would know that a product spends most of his life cycle in a support stage, right? The part where you develop the product and all that is… it’s very much the beginning, but then for the rest of its life cycle, it’s all about supporting that product, enhancing it, making upgrades, et cetera.

Pablo Gonzalez: There is a huge need for people supporting a product, and I don’t understand why there’s this misconception that engineering is just that developing phase, just the coding part. I also feel that another problem is that the practice of coding or programming is also glorified within the same umbrella of different careers. For example, you move to security and some people may still not even consider that real software engineering because they might think, “Well, you’re not coding, you’re not using the latest JavaScript framework of the week so you’re not a real software engineer.” Of course, I’m not saying that, but I’m saying some people will still think like that even if you got out of support, and it’s because somehow the practice of coding, it’s put on a pedestal. Again, I don’t know where this comes from, but it is very hard to get out of this idea that the only thing you can do is support.

Pablo Gonzalez: I think one of you mentioned once you do support for a few years… the more you stay in support, the harder it is to get out. It’s like you have a stamp on your head that says technical support, and recruiters, managers, everyone will see you through this lens of a support person, not an engineer, not a technical person. It’s really, really challenging to get out of that.

Andra Burck: I wonder if it might be a little bit self perpetuating. Historically also, I think it maybe wasn’t uncommon for support teams to kind of be siloed from the engineering org. Engineers, support engineers, and technical support specialists, they weren’t interacting as regularly as maybe they should have been. I think at least in my experience, once I’ve built rapport with software engineering teams, it definitely changes the entire dynamic. I don’t know. I think that would definitely be the first piece of advice that I would have for someone who’s looking to move out of a support position is definitely get to know your Dev teams and start to build rapport with them, because you can be the most competent and capable person in the world, but your career progression is just going to be a lot harder if you don’t have a relationship with those teams.

Kat Gaines: I want to plus one that, and I think that’s also part of owning your career progression, sometimes people look elsewhere and say, “Well, my manager has to do it, or the team I want to go to has to figure it out.” They’ll be your aid, they’ll help you find that path, but at the end of the day you have to be the one to say, “This is where I want to go and these are some steps I’m going to take to personally get there.” Let’s talk about that rapport a little. I think that all of you probably have some experience in building that as part of your career progression. Let’s talk about how you did that because I think that’s something that people get stuck on a little bit, in terms of just, “Well, how do I get to know these teams? How do I put my name in front of them?”

Pablo Gonzalez: I think, for me, the only way that I was able to do it was to become really good at what I was doing to get noticed. For example, when I was in tier three then, the escalations would be the actual engineering team, so I put a lot of effort to… I wanted to be a very well known tier three. When engineering would get an escalation from me, they would say, “Great, it’s an escalation from Pablo, I know it’s going to be good. It’s going to have a lot of details, it’s going to have all the logs, all this stuff.” Of course, I did that because I enjoyed it as well, but a big part of it was also that effort of these are the people that can eventually help me move into that role and I want to be the best I can in their eyes. I put a lot of effort in making sure that everything I did was of high standard.

Pablo Gonzalez: Also, if you have the opportunity to just meet them in person, it’s different now with remote work and all, but if you’re having an off-site event, just really breaking that barrier of remote work and being able to have a coffee with someone or a chat with someone really helps a lot. But for me personally, as I said, what worked was to become as technical as possible so that I could sort of impress them and so that they would think of me as a possible candidate for a position in their team. I don’t know if that’s the only way, but that’s what worked for me.

Kat Gaines: What else? Isabella, do you have anything?

Isabella Applen: I do think that my transfer is kind of exceptional and not a good example because…

Kat Gaines: It’s still good for people to hear about, right, because those kind of strange ones happen all the time, like I was saying earlier.

Isabella Applen: It’s just funny because, on support, I had contact with a lot of our engineering teams, but mostly feature teams or security. But, there was really never an occasion for me to contact infrastructure teams, so site reliability was one of the departments that I really had no relationship with at all, so it’s kind of funny that I ended up there. I think what my manager found appealing about support engineers is that we have a customer first mindset and we’re very… our whole job has been serving developers, so that part of transitioning to SRE made a lot of sense. I’m just going to use SRE instead of site reliability engineering.

Kat Gaines: They saw that benefit back to the business, and I think it’s probably twofold. It’s the benefit back to the business and knowing kind of the… having someone who’s familiar with your customers and your developers and that way it can help you understand what you’re doing on that side a little bit more. Then, I think it’s also, Pablo, like you said, the reputation thing. Folks may have connected the dots, other people listening to this might know this, but Andra and Isabella, you both used to be on the PagerDuty support team, as they mentioned. I used to manage both of them on the PagerDuty support team. The reputation piece is huge because for each one of you, people would often come to me and just say how grateful they were for something super cool you did, partnering with engineering or another team in the business.

Kat Gaines: Even if it’s not a team that you’re working with directly, Isabella, like you’re saying, that word spreads. If you’ve been working with the development teams and the people who are working on the features, that word will still spread back to SRE teams, other teams who aren’t working on those things so that they know that, “Okay, Isabella, she knows what she’s doing. She does quality work and she’s somebody worth having this conversation with at the very least.”

Pablo Gonzalez: There is another topic sort of related is that it’s also hard work, just because you’re in technical support and you want to move to some engineering role, even if you have the connections, you may actually not have the skills at that time to be able to perform well in that job. That’s also a huge part is that you have to also have the skills, and not everyone has them in support. Obviously, I’m not being the person that we are sort of criticizing here, but it is a reality that you just don’t have all those skills naturally in support. For example, something like coding or troubleshooting, very specific database performance issues or network issues, they may not come naturally to you depending on the type of support that you are doing, so there is a little bit of homework that you have to do to understand what is the ideal role for me? What kind of technology do I want? Do I want to specialize and put in some work?

Pablo Gonzalez: You have to spend some time learning that, maybe buying some books or some Udemy courses or YouTube tutorials and really get the skills that you need, and then everything else that we have discussed, but I think that’s also a huge part as well.

Andra Burck: Yes, and just to touch on that… previously we kind of touched on some things to look at when you’re hiring, and I think that is one thing to look at because you can teach someone technical skill, you can teach someone how to troubleshoot something specific, you can’t teach someone to be interested and you can’t teach someone to be passionate. The willingness to be open about things that you don’t know, that’s also going to just make it a lot easier to work with that person because it kind of indicates that their ego isn’t wrapped up in this idea of knowing everything. If they’re interested, passionate, and kind of honest about the things that they know and they don’t know, those are all really big green flags in my opinion.

Kat Gaines: Yes, and it’s a patience with the skills both ways, so Pablo, like you were saying, you might need to be self aware if you’re just not ready yet, and you need to know that, you need to know what you need to work on. Then, Andra, what you’re saying, that if you’re a hiring manager you need to be able to look at that person and say, “Maybe they’re not ready yet in a way that ticks all of my boxes, but how quickly can they learn? Is it worth taking this risk?” I’ve seen people find that, more often than not, it is worth taking the risk and it pays off for them when they do. As a sidebar, a pet peeve that I have is also the discussion of skills in the sense of soft skills.

Kat Gaines: I really have come to hate that term so much because they’re hard skills to learn. What we talk about when we say soft skills, people are usually talking about empathy, they’re talking about communication, they’re talking about human facing and human centered skills. I started saying that instead, human centered skills, or just what we actually mean, communication skills, because they’re super necessary in customer facing roles. It’s everybody’s responsibility to learn them though, even if they don’t think their role demands it. I think it’s awesome when a team is considering somebody from support, they know that they have those human-centered skills and that they can, not teach their peers because it’s not their responsibility, but maybe lead by example a little bit when they come into the team and say, “Well, this is how we do this, and this is how we do this,” if maybe the team’s struggling with it, or maybe they haven’t been challenged to learn those skills for some reason. It happens more often than you’d think.

Kat Gaines: I’m not saying that people are just cold and difficult to work with on other sides of the business, but it can happen that you have people who need a little bit of work on that, and so if they can see by example that they have peers who do that really, really well, that’s another kind of good benefit back to the business and that team.

Andra Burck: Yes. At my last company, I was given extra soft skills training because of how gruff I was. To be fair, I think at the time I just had less emotional maturity, but I was originally very insulted by the fact that I had to take this extra training. I completed it, but begrudgingly. In hindsight though, that was probably some of the best free training I’ve ever gotten. I think people are getting better about this now, but at the time there was almost this misconception that a technical position was solely about technical skill. If you think about it though, technical skill is not going to diffuse misunderstanding, it’s not going to prioritize things on a roadmap. Or, a security focus example, a CVE is not going to convince a team to bump something down on the roadmap, it’s a collection of letters and numbers that’s meaningless, so you need soft skills to be able to approach that situation, explain risk, and to help prioritize. It is really important.

Pablo Gonzalez: Yes, they’re not soft skills though, that’s what Kat is saying right there. What did you say? Human-centered.

Andra Burck: Human-centered. Yes, I like that.

Kat Gaines: Human-centered skills, hard skills.

Pablo Gonzalez: Yes, hard skills.

Kat Gaines: For a lot of people.

Pablo Gonzalez: I think it’s very important because, especially when I used to work in tier three, again, it’s very easy for someone in engineering to say, when you escalate a problem and they can say, “It’s actually not a bug, it’s working as design,” even though it doesn’t make any sense whatsoever and it’s clearly a bug they’ll say, “Well, it is working as design. Close the investigation, and then good luck, go tell the customer,” now, of course, you cannot just go tell the customer, “Hey, it’s working as designed. Thanks for reaching out. Have a good day.” You really need to do a lot of acrobatics and gymnastics to massage that same message into something that has a little empathy, that makes sense, and the customer is going to be somewhat okay with. That actually takes a lot of practice, it’s not easy, and there’s no recipe for it, there’s no script that you can just follow.

Pablo Gonzalez: It does take a lot of practice, and I think it’s often overlooked how important that is. If you were to put the actual engineer on a call with the customer, that call would go completely different than if it’s someone that has those human-centered skills to be able to deliver the message in the correct way.

Kat Gaines: Yes, support acrobats, I think that’s what a lot of people should get their title changed to because it’s very true a lot of the time.

Kat Gaines: Before we wrap up, there are two things that we ask every guest on this show, and these are kind of hard questions to answer, but we’ll get through them. Isabella, I’ll start with you, and then Andra and Pablo, you can jump in as you want. What’s one thing you wish you would’ve known sooner when it comes to career moves between support and other departments?

Isabella Applen: I think I knew this. I think it was just really, really hard for me to act on, but I think it’s so important to treat your career progression as part of your day-to-day job because it’s really easy to think of that as something that’s in the future or something that’s more high level and abstract, and it really needs to be a part of your tasks that you do every day, that you focus on every day, and put time into every day. It can’t be something that is just on the back burner or is just abstract.

Kat Gaines: 100%.

Andra Burck: Yes. Something that I wish I had known sooner is actually how to determine whether or not career progression is even going to be possible where you are. If you’re experiencing things like the goalpost keeps moving, or if you’re siloed from engineering teams, if your manager doesn’t care about and doesn’t help prioritize your career progression, you need to get out of there. That’s definitely something I wish I had learned sooner.

Kat Gaines: Yes, there are absolutely major red flags where you need to just know if it’s not going to happen for you. Pablo, how about you? What’s one thing you wish you would’ve known sooner?

Pablo Gonzalez: You should try to focus on exactly what is it that you want to do. When I was trying to move away from technical support, I bounced on a lot of ideas. I’m going to do big data, no, I’m going to do web development, or no I’m going to do actually networking or site reliability, and all those things are actually very different. It is very easy to get distracted with all the different topics that you can learn, and you end up becoming a generalist, which is not a bad thing, it’s actually great for support, but it’s not necessarily great for a specific role. I think I wasted a lot of time trying to find exactly what was it that I wanted to really learn, so I wish I had just known that… hey, spend some weeks just thinking about it, and then decide on what you want to do and go with that rather than spending months learning all these different technologies and different approaches, trying to figure out what is it that I wanted.

Kat Gaines: Isabella, that’s part of the same thing that you said, right? Your career progression is an everyday job, and so you really have to spend that time thinking about where you’re going and what you’re doing. I think what people don’t realize is that… I think people get freaked out by the idea of thinking and talking about that every day, because it’s like, “I don’t know what I’m doing. I don’t know where I’m going to be in six months, a year, five years,” that doesn’t change ever. I have never figured it out for myself and I’ve done all kinds of stuff. I think everybody here would probably say the same. You’re constantly figuring out and constantly working on it. People get really just deer in the headlights, thinking that they need to have the answer from day one when their manager says, “All right, let’s talk about your career progression.” They go, “Oh no, I need to know right now, what?”

Kat Gaines: But in reality, you don’t. You get to figure it out, you get to try different things, but you have to kind of pick a path or two and hone in on it and say, “What do I need to do to get toward that path?” If it doesn’t work, cool, flip over to something else, but you do want to be able to at least focus and be able to say, “All right, I tried this thing and now I know either that it’s the thing I’m going to continue going for or it’s not for me, that’s okay.”

Isabella Applen: Something more specific that I thought of was… something I wish I had known was just the internal engineering recruiting channel at our company. I didn’t find out about that channel until last year, and that was probably on me for not asking around more. But, something I wish I had known and acted on sooner was just keeping track of those positions that open up and applying to them very aggressively and very regularly, even if I start annoying engineering managers or recruiters, but to just be very aggressive about that. I think I also wish I had asked other people who transferred from support before me exactly what they did, because I would just ask the other people who were still on support, “How did that person transfer to engineering?” That version probably wasn’t as accurate as the actual person’s firsthand account.

Kat Gaines: Yes, knowing your resources. I didn’t even know about that channel for a long time, and as somebody who was moving folks from support into engineering, that was really frustrating to find out after the fact that it could have been a thing for a while. I think there’s a lot about sharing information, and like you’re saying, also asking folks for information, so asking the right folks, asking what they did. But then, if you’re somebody who knows something, for heaven’s sake, share it with your peers, let them know what you did if you had a successful transfer. That’s part of why we’re doing this podcast I think because we want other people to benefit from it too. But then, also, if you’re in other roles, if you’re a manager who knows exactly how somebody did something, share that information, don’t make it a secret.

Kat Gaines: Don’t think that you’re going to keep your support people forever, because that is just delusional, and make sure that people know what the paths are and how to get there. Or, if you’re somebody in engineering and you know these great resources like slack channels where people can go find information, go tell people in other parts of the business so they know, they can use them, and you can all benefit. The other question is the hard one, I think, but we’ll give it a shot. Is there anything about this topic that y’all are glad I did not ask about?

Pablo Gonzalez: I guess it’s good that we didn’t talk about how many different versions of my CV I had for all the different jobs that I was trying to apply to because that would’ve been a long conversation.

Kat Gaines: Do you have a number?

Pablo Gonzalez: No, but I had a lot of different resumes, different CVS, trying to portray myself as something else for different recruiters, but that was part of the journey I guess. I think it’s good we didn’t talk about that.

Andra Burck: Probably good that we didn’t talk about using macros, considering the whole stigma around support not being scripted.

Kat Gaines: Look, it’s not scripted, but sometimes you need a shortcut because it gets repetitive a lot, right?

Pablo Gonzalez: Yes, it’s true.

Kat Gaines: All right. Last thing, if we have anything we want folks to check out, a call to action, folks, do we have anything that we want people to go look at after this episode?

Pablo Gonzalez: Yes. For me, I wrote an article on the website of my employer, again, that’s Salto, and the article is about how I did the move from technical support to software development. It’s pretty much what we spoke here, but obviously in a lot more detail, and there are some of my personal recommendations on which books you should read and how you should change your CV to be more about the technical skills, so that’s on the notes for this podcast. If you want to check it out and give me some feedback on LinkedIn, that would be great.

Kat Gaines: All right. Then, I think I personally have one, and it’s a topic we didn’t talk about very much, but it’s the importance of community and knowing that there are other people out there going through the same stuff as you, and knowing that there are other people out there who are trying to figure this out. That’s actually hard to find when you’re in support, it’s hard to find out who those people are and where those conversations happen. I want to plug the support driven slack community. We’ll link that in the show notes too, along with Pablo’s article, but go check it out. They have a conference that just happened a couple of weeks ago, every year I think too. It’s a legitimate community, which again is a very hard thing to find when you’re in support, but it’s a really great place to go bounce ideas and questions off of other people who are in tech support across all kinds of industries.

Kat Gaines: It’s something that I’ve found really helpful over the years. I think I’ve probably lurked more than I’ve contributed, but lurking and gathering information and then contributing where I can. I definitely encourage people to go check that out. I want to thank all three of you for this conversation. It’s been really awesome to have y’all on the podcast and hang out a little bit. Thanks for our listeners too, for listening. We’re excited to have more of these types of conversations. Without further ado, again, my name is Kat Gaines and we hope you have an uneventful day.

Kat Gaines: 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 pod-catcher if you like what you’ve heard. You can find our show notes @pagetothelimit.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.