212: Knowledge Management with Cynthia Ng

Charlotte Ward: 0:13

Hello and welcome to episode 212 of the Customer Support Leaders Podcast. I'm Charlotte Ward. The theme for this week is knowledge management, so stay tuned for five leaders talking about that very topic. I'd like to welcome to the podcast today, Cynthia Ng. Cynthia, it is lovely to have you join me for the first time. Thank you so much. Um, first of all, would you like to introduce yourself?

Cynthia Ng: 0:44

Yeah, sure. So my name, um, is Cynthia Ng, uh, also known as Artie or Artie Chan, depending on which social media channel you might find me in. Uh, I'm uh currently a senior support engineer and GitLab.

Charlotte Ward: 0:59

Thank you so much, short and sweet, but thank you so much, Cynthia. Listen, um, I was super keen to have someone from GitLab come and join me to talk about the topic for this week, which is knowledge management. The reason I front-load this specifically is that I lead a support engineering team who support a very, very technically complex product. Um, and in that environment, knowledge management is always challenging, I think. And we're just beginning our journey in in terms of formalizing how we manage our knowledge much more consistently and accessibly and everything else. The the the team member who um I have on my team who is looking after that project said to me straight out of the bat, I love what GitLab do with big smile. I love what GitLab GitLab do with knowledge, and I really think we should emulate them. So as soon as I had the opportunity to talk to someone from GitLab about knowledge management, I took it. Um, so I would really love to kind of spend a few minutes with you just exploring how you approach it, particularly in this highly technical technical environment, particularly with support engineers, um, and and see where that conversation takes us. So maybe we start at the beginning. What do you think are like the particular challenges for this, for this sort of more support engineering role?

Cynthia Ng: 2:21

Um, yeah, I mean, I definitely think that um even though even at GitLab, you know, we we do have some kind of procedural things where you can say, hey, if this person has this kind of problem, start here, go through these steps. Um, for the most part, you can't do that. There's just, you know, especially in a very technical environment and with uh, you know, a combination of products. So GitLab has a SaaS cloud-hosted product, but also has uh what we call self-managed, but most people would think of as kind of like a self-hosted product, right? And you can imagine GitLab being run on any kind of infrastructure you can think of under the sun, you know? And how do you resolve those problems when you know it you can even be running a GitLab runner on Windows or Mac, you know, like like it's not just even Linux-based systems anymore that you're talking about, could be Kubernetes, could be almost anything, like really. Um, and so you know, you it's very, very difficult to, you know, rely on what a lot of I would say support teams rely on, which is like macros and like I say, kind of procedural workflow pages. And we certainly have some of those. Um, and we certainly use macros for efficiency purposes, you know, like even uh like a short greeting, you know, or a salutation, or you know, your typical, hey, it looks like it's been resolved, you know, I'm gonna close the ticket kind of thing. Like all of those kind of more repetitive things, even GitLab definitely uses macros for. Um, but in terms of trying to kind of share knowledge on how do you troubleshoot a specific topic. And for those who don't know, GitLab is has this, you know, really ambitious vision and goal to be the single DevOps product for any given company. So you're talking about features that range everywhere from you know just the Git repository all the way to how do you do uh security scanning? And so so even just within the GitLab product, you have this whole range of topics, and you literally cannot be an expert in all of them. One of the things we actually remind support engineers about is that don't you like don't feel like you have to be an expert in everything. If you need to ask for help, you know, do it. Like, like there's no reason not to. So so one of the things that we try to do is try to encourage people to keep in mind that yes, we try to, you know, keep all our knowledge and share it and everything, but it's it's it is really hard. Um, so I don't think any company, any any organization has ever done trying to figure out how to manage that knowledge.

Charlotte Ward: 5:19

Um so I guess so I guess what you're describing then, like particular particular challenge is is I think then exactly what I I see in my own team, which is that it's a low level of repeatability. Um, it's really technically complex and probably quite um the technology landscape, I guess, changes quite significantly and quite quickly, right?

Cynthia Ng: 5:45

I think that yeah, yeah. So so both both you know the landscape itself, but also even the GitLab products. We have a new release every single month. So at GitLab, we do sometimes struggle a little bit with even keeping up with our own features. Um, but I would say that like one of the really great ways we do that is um we do have training a lot of the we we build kind of um our own training uh kind of modules, like there, and really it's just a checklist of things. It's kind of like pointing people the to the direction. So like if you want to learn more about any given topic and that we have created a training for, like say Docker, then it you know, points you to certain documentation pages, not just like GitLab ones, but external ones, right? So like Docker pages and stuff like that. Um, and then it would kind of walk you through just a little bit, um, mostly by again pointing you to different places to um kind of gather that knowledge and learn more about the topic. Um, and then you know, we expect people to to kind of list some of the tickets that they've answered to kind of show that they're learning that knowledge. Um, and then we usually get an expert to review. So that's that's kind of one way to we do it. Um, the other is that we do kind of almost internal training sessions that are kind of synchronous and um uh on a very specific topic. So we call them deep dives. So we're kind of really diving deep into a very specific topic. Um, the engineer will usually put together a short presentation to kind of go over the basics of troubleshooting in that very narrow topic. Um, but then sometimes you use an example to really again really dive into how do you troubleshoot this, these particular types of problems. Um, and then you know, we usually have a slide deck and then a QA session and we record it and we upload it, and that's public actually. Like honestly, um, unless there's customer information or anything private, we actually try to upload them to our uh what we call GitLab Unfiltered uh YouTube channel, and it's actually public. Um, so I actually did one recently on on Skim and how we you know troubleshoot skim problems, and yeah, it's it's public. The slide deck isn't, but the video certainly, the recording certainly is. So anyone can access it. Um and and honestly, like what's interesting is that um we try not to keep the knowledge to ourselves, right? So I think the main thing and the main way that we uh do a really good job of again kind of um passing on that knowledge is actually to put it right in our docs. Uh so there's a you know, things like the deep dives we actually do publicly. Um, every so often we'll we'll record demo videos too. Again, they're kind of unofficial or whatever, haven't you gone through a marketing team or anything like that? But because we have this unfiltered channel to upload them to, we can link them to the docs. So the idea is that we don't embed videos unless they are kind of quote unquote officially approved, but we will link to them. Uh so you know, in any given doc page, you could say, hey, you know, this demo video may be of help and we'll link to it. The other is that we have troubleshooting sections on um basically every page. Um so our docs, uh as part of the docs site, every docs page has a troubleshooting section. Now, if it's empty, the the heading is just hidden. Um, but anytime someone from support actually adds something to the troubleshooting section, uh, then it displays and it displays whatever we decide to put in there. Uh and that's been super helpful because even within support, like I say, there's so many topics, but I can go to a docs page and if someone, especially if like someone encounters a specific kind of error, we almost do it FAQ style, it's like, hey, if you encountered this error, you know, go look here for the problem, or here are some possible causes and stuff like that. And so we're actually not only making it possible for customers to self-serve, but also for support to self-serve in a lot of ways and and kind of really make that uh knowledge transparent and kind of push it out of even just a ticket, right? And and out of our brains specifically.

Charlotte Ward: 10:21

That's the important thing, isn't it? Getting it out of heads somewhere where it's accessible and and just persists for as long as it's relevant, right? I think that that's really a big, a big focus for my own docs journey right now is how we get stuff out of people's heads. And I love that transparency actually that you're describing. I I think that there is um quite a common sense of like conflict in organizations, isn't there? About should we keep this knowledge to ourselves? We have worked very hard to acquire it. We spent a long time building this set of expertise. Um, and at what point do we release it out of support to our customers or beyond to the wider world? And and but your everything you're describing is is almost everything is external.

Cynthia Ng: 11:14

Yeah, and I will say that I mean, I think part of it comes from our values, you know, one of them is transparency. So part of GitLab's commitment to the community is actually to provide um, you know, support for the open source version and to kind of uh give back to the community in a lot of ways. So, you know, part of it is that people can self-serve in a lot of ways. The other is that, you know, we see as providing support um means also improving our own documentation. And if anything, you know, one of the things we actually say is that if something is so complex that someone has to uh, you know, contact support, it's it's probably actually user experience debt, right? So yeah, so we have this philosophy around like, you know, what what support is here to do is to kind of solve the problems, but there's no reason that we can't have customers self-serve. Um they're they're not people don't want to have to contact support most of the time, right? Like honestly, it's it's often the the last resort. Um, so if people customers can self-serve, honestly, they're usually happier and more satisfied with the product, even if they are encountering an issue. So uh in a lot of ways, it's it's the philosophy around the there's there's the GitLab values around transparency and collaboration and results and and all of these things, but also part of it is you know uh our sense of what it means to provide quality support. Um, and it really is to kind of solve these issues that they can't solve themselves.

Charlotte Ward: 12:58

Um, I think that's super interesting. The commitment to transparency just bleeds so nicely into that commitment to the community and and and that just it's it mirrors on all levels, doesn't it? It's reflected at all levels from the values through to the way you operationalize it through to that sort of making things very accessible regardless of how you access or or use GitLab, right?

Cynthia Ng: 13:23

Yeah, for sure. Um, so I mean, I'm happy to link to some of the uh documentation we have and some of like the workflows that specifically talk about, you know, um what we consider responsibilities within support, which I think um will be really enlightening about um kind of what we consider important. And I mean, it really helps for us to actually be able to see the code base, really dig into the code and that sort of thing, and um obviously have the technical expertise to try to reproduce uh or try to replicate a lot of the issues that our customers uh encounter. Uh, but in general, I think a lot of it just has to do with the fact that uh we are very open and uh you know, again, have this kind of idea that we really try to get that knowledge out of people's heads and even out of our support tickets into the open.

Charlotte Ward: 14:21

Yeah, I I I I think that's great. And I I think just something that just occurred to me that um you were saying before about um about how much customers do want to self-serve and how making it accessible and easy for them to do so by having it out in the open is of is of value to everyone. Um and I I think just what you said before about customers want to self-serve and they don't really want to contact support, I think it's something that's kind of lost often on support teams. It's it's that in in allowing our customers to self-serve, we actually can kind of speed up their day. Like we actually give them help by allowing them to self-serve, and and access to knowledge is is is the biggest part of that, right? Um as good as your support team are, like that there's always an overhead in your customers contacting your support team, isn't there? They they can be a great support team and they can get that customer to a point of resolution really quickly. But the fact is that the customer still has to reach out. There will always be a wait, whether it's seconds or hours, somewhere in between the two. Um, and if that customer can just in the moment, in the tool they're in, go and find the knowledge that you all have access to anyway. Um one hopes it enables them to self-serve and self-solve their problem, which is uh which is to the benefit of everyone, I think. Um the the final thing that I wanted to ask you was just about um how how you think the low friction that you have in getting knowledge out there, you said everything was kind of unfiltered to a degree. How how how much of a perfectionist is your average GitLab support engineer when it comes to putting knowledge out there for for people who aren't even paying customers at this point?

Cynthia Ng: 16:20

Um I would say that it I mean it varies between engineer to engineer, um, but honestly, you know, we usually say the most important thing is to get the knowledge out there, uh, especially if it's a problem that has kind of cropped out with a specific release, then you know, we want to make sure that knowledge is out there as soon as possible. Uh so we what we do with all of our docs updates is that with troubleshooting, again, it kind of depends a little bit. If we believe it's urgent, we can actually get it merged first and then do a post-merge uh request review. So after it the change has actually been updated and added to our docs, we will then get a technical writer to review it after. If it's not an urgent change, then we actually do get our technical writing team members uh to review uh the you know the change before it's updated. So whether it's a troubleshooting section or an edit to the, you know, to kind of the main part of the documentation, um, we do have a technical writing team that are great at reviewing uh quite quickly. And again, if we feel it's urgent and we were just putting it in the troubleshooting section, we'll just get the review to be done after. And that is something that we um kind of had to work at in a a little bit in terms of putting that process in to make sure that it is low friction for support engineers to get that information out as quickly as possible when we feel the urgency for it.

Charlotte Ward: 17:58

Yeah, yeah. And the other the final thing that um I just like your thoughts on, I think. I I get the impression um that there is very little distinction between what you would consider to be documentation and what another support team might consider to be a knowledge base article, right? I think you approach every everything is docs, isn't it?

Cynthia Ng: 18:22

We actually don't have a knowledge base. So that really should tell you something. So we have training, and like I say, we have workflows. Um, and our workflows are again more around process, internal process, right? Like um some of the kind of administrative stuff. We have things like you know, just guidance on, hey, you know, how to how to work tickets and and how to do these things and and whatever else. Um, how where you can get infrastructure testing, you know, instances for AWS or you know, Google, you know, clusters and and all this other stuff, right? So so there's definitely internal knowledge for the team that we have documented separately in our handbook. Um, but in terms of any kind of knowledge related to the product itself, it's it's in the docs, it's in bug issues or in the project, like you know, for developers and product managers to review. There's there's no there's no separate knowledge base at GitLab um to you know say whether there's an issue or anything. Again, if there's an issue, it's it's in the project tracker for the development team, for the product team to to look at and review. Um and that is actually one of the nice things about be able to have that open because then we can also point customers um and they can see our communication with the development and product teams.

Charlotte Ward: 19:53

Yeah. So so I mean, everything just has that single access point, doesn't it? There's no like real fragmentation. In that sense, to the knowledge. Customers and open source community all know where to find the thing that they're looking for.

Cynthia Ng: 20:10

Yeah, and um what we call the single source of truth is very important to us. Um and so uh we do definitely try to keep it uh all in one place. And and like I say, it's it's kind of actually really nice to just be able to look at the documentation as a support person and and be like, oh, I can see like what other people have encountered and how and and what might be the root cause for for certain errors or certain um you know issues that you encounter because often you'll end up with a symptom, but understanding what the root cause of something is can take quite a lot of time to dig in. And if someone else has already done that work, then then it's there and it's great, and it saves you a lot of time.

Charlotte Ward: 20:56

That's it for today. Go to