Latest / The Not-Boring Tech Writer / Advocating for docs and choosing tools with Kelton Noyes

Transcript

Advocating for docs and choosing tools with Kelton Noyes · The Not-Boring Tech Writer

• Kate Mueller: [00:00:04] Welcome to The Not-Boring Tech Writer, a podcast sponsored by KnowledgeOwl. Together, we hear from other writers to explore writing concepts and strategies, deepen our tech writing skills, get inspired, and connect with our distinctly not-boring tech writing community. If you're passionate about documentation, you belong here, no matter your job title or experience level. Welcome! Kate Mueller: [00:00:28] Hello my fellow not-boring tech writers. I am very excited to welcome to the podcast today, someone I know from my KnowledgeOwl world. He was a KnowledgeOwl customer once upon a time when I was still doing support quite a bit. And although I am no longer doing support and he is no longer a KnowledgeOwl customer, he is a very experienced, thoughtful, interesting, engaging tech writer and I'm so excited to have him on the podcast. So I would like to welcome to the show Kelton Noyes. Kelton, thank you so much for being here. Kelton Noyes: [00:01:01] Hey, I'm glad to be here. Thanks for having me. Kate Mueller: [00:01:03] It's always a delight. And so for folks who don't know, I feel like I just set you up, like, “he's thoughtful, he's brilliant,” and now you might be panicking about that. But for folks who don't know you, can you tell me a little bit about your tech writer villain origin story? How did you begin this crazy journey? Kelton Noyes: [00:01:20] Yeah, growing up through school, I was always debating what I wanted to do when I grow up, as it were, and I was leaning really heavily into engineering and computer science for quite a while, and I ended up taking several engineering classes when I got to college. And then I went away on a service venture for a bit. And when I came back, I decided that the engineering courses just weren't for me. I wanted to really get into English. I've always been an avid reader and a studier, and so I studied English in college with the idea of becoming an English teacher. Realizing that I had goals to have a family and to have other things later on in life, and looking at salaries and things like that, I decided that it would probably be the smart choice to move more into the technical fields. I got jobs in tech support and was always trying to find a way to use my English skills and my English training in my jobs, and I found the easiest way to do that was every position in tech support I was in, had invalid documentation, had out-of-date support references or guides, and I was tired of answering the same questions over and over again. Kate Mueller: [02:32] I really like that career arc for you. The shift from being primarily a support person who did some writing to being primarily a technical writer. Tell me a little bit about the role that you currently have. Kelton Noyes: [02:46] I am a senior technical communicator for a fintech company that specializes in products related to the real estate industry. And so my main focus as a writer is to create walk-through documentation and workflow processes for our mobile application tool, our web version of our tools, and just helping guide, not only loan officers, and their potential borrowers and customers in ways to quickly submit, process, and go through the loan application and acquisition process. And so anything related to helpful guides with documentation to even UX editing and copywriting and things like that, I assisted in editing and developing those things. Release notes or plugin updates or anything just in that space is kind of what I've been working in. Kate Mueller: [03:38] Very cool. And are you one of a team of writers, or are you kind of like a solo writer who has some other people that you pull in? What does that look like? Kelton Noyes: [03:46] So there are several writers that are with this company. I'm the only writer for my specific product line and what I do. And so, most of my day to day collaboration is with my product managers, with the support and training staff, product marketing specialists. And so I do have a coordinated effort that I work with on a daily basis, but I do also have writers that work in other parts of our company's products that I can use as peer editing references and collaborative efforts from a writing space as we coordinate on style and making sure that our documents can be unified as much as possible. Kate Mueller: [04:25] Yeah, that's helpful. It means that you have a fair amount of autonomy in what you're doing, but also you have that sort of community of practice around style proofreading or, “I'm thinking of changing this convention. What do you think about that?,” which is not really a conversation you can have with a support person or a product manager, unless they just happen to be super into writing, in my experience. Otherwise, they're like, “You're the writer. You're good at this, I trust you. If you think we need to change it, we can change it.” Okay, so senior technical communicator. So if I use the phrase tech writer, do you identify with that? Do you prefer technical communicator, is there some other label you would want to use? Kelton Noyes: [05:04] I'm fine with either of them. Technical communicator was an idea that was passed with my company a couple years ago, where we're realizing that with the introduction to AI and several other types of ways of creating and writing and drafting and curating documentation, what we really are is not just writers, our focus is we're editors. We are a bridge between engineering and the rest of the world and our customer base, and that can be done in so many more ways beyond writing. And it's all communication focused. And so they pitched the idea that we are actually communicators: we are interpreters, we are doing things that are more than just about writing. It's about leveraging tools and experience and our ability to understand not only the technical world, but things outside of the technical world, [so] “communicator” seemed to be a better fit. Kate Mueller: [05:57] I like that both as a term, but also as the rationale behind the term. So when we were kind of bouncing back and forth around ideas that we could cover, one of the things I was really fascinated by is, I think because you've come up organically on the support side, you've had to claw your way into getting official roles, you've had to work with a wide variety of tools, you've also had to try to make the case for a wide variety of tools, and I'd really love to pick your brain around a lot of those experiences. So I guess maybe a good place to start with that is for a lot of us, if we're choosing a tool, or if we've come into an organization that already has a tool set, and we're trying to figure out both how to learn that, but also to see if that's the best fit…I think a lot of the place we begin is: what are the needs that we have for this documentation, and does the tool set we currently have meet those needs? If it doesn't, how can I best articulate those needs for us to try to find a tool set that works there? And so, I'm curious if in your experience—I promise there's a question here, Kelton. It's taking me a while to get there—I'm curious, in your experience, how have you gone about trying to identify those needs and whether there's a good tool fit or bad tool fit? Kelton Noyes: [07:28] A lot of it comes from my support experience where interacting and dealing with customers, I’ve offered support in a technical field using phones, through email communications, and even chat-based support. And I started noticing patterns really quickly with my different companies that I had worked with about the types of questions our customers were asking, the repetition of the questions, and then finding ways to answer those questions best. I started looking at ways to not only present the information in a very quick and easily digestible way, but finding ways to update things as I worked in software and tech companies for a while. Updates and changes to the product happen all the time, so I wanted something that was also going to help with ease of updating and maintaining the documentation to keep it current. Talking with managers and other individuals, it's different for each organization. A lot of people like to use almost like a blog style website, or people were less concerned about security features, and so on the main company webpage, they would just update articles, almost like a blog style where you could just refer someone directly to the company site. There were other things as well with companies that if we were more of a third-party provider to the actual company, they wanted to white label everything. They didn't want people to know that they were using our services specifically. And so while a lot of the ins and outs and the particulars of a company's needs were varying, at the end of the day, the customers just wanted to get help and they wanted to know how to solve a problem, how to upload a document, whatever the case may be. Kelton Noyes: [09:16] And at the end of the day, you could do that with a simple Word document if you had to just answer that question. But trying to find ways that you can send out a PDF but you can't edit a PDF well, or at least you couldn't for quite a while. Or if you wanted to include a different type of media coverage, or if most of my companies had training departments, they did a lot of video work, they did a lot of webinar recordings and things like that. And sometimes, depending on the tool that was available at the time, uploading or embedding links to videos or to other services caused a lot of problems. It wouldn't translate well when you sent it out with an email or things like that. And so it became an organic trend and an organic process for me to identify what is the most effective way to answer these questions and how can I share it with them. And then, as I was looking at the various tools, you had mentioned I've worked with several of them, whether it was an internal tool such as Confluence or the Atlassian suite, or using Google sites or another web hosting service such as WordPress, or a blogging focused web tool, they all presented their information in different ways. Kelton Noyes: [10:34] They all secured things in different ways. There are pros and cons to all the tools themselves, but it's being able to figure out, “What did the customers respond to the best?” If I sent out a document and then they gave feedback of, “You sent me a twenty-page document, and I had to scroll down to page 19 to get the answer, that wasn't as helpful.” So I was looking for other options. Can I anchor a page? Can I provide a table of contents that's interactive? Or what does the tool allow for these little things? And then you begin developing this hierarchy of needs, as far as what features are essential that you think to provide quality documentation for our end users, versus what's a nice to have and what is an extra thing that, while the tool does offer it, when am I ever going to use this, and is there a tool or is there another company that offers a service that doesn't have that, but has other things that we would use. And then once you have your list, you can look and see “Does the product I'm working with currently offer all of those things, yes or no?” And if not, it begins a frustratingly wonderful experience of looking for the right fit [laughter]. Kate Mueller: [11:52] Yes, you're like the prince in Cinderella trying the glass slipper on a thousand different women's feet to see if you can find the one that's actually the perfect fit. Except it's not just a single shoe and a single foot. It's like a bucket of shoes, and you're trying them on a whole bunch of different feet and trying to figure out which of those feet are required to be shoed and which aren't. This is a really challenging metaphor. I'm not sure why I went here, but yeah, it is a process. So in defining that hierarchy of needs, it sounds like there's a few elements that have been really dominant in what you're doing. Let me see if I can summarize this effectively. Sounds like a big piece of that has been driven by customer and user needs and feedback in the support interactions. So getting a feel for what that customer base is looking for, comfortable with or not comfortable with, frankly, what sort of their expectations are of how they're going to find the information and/or how it's going to be communicated to them. Kate Mueller: [13:01] Sounds like another piece of that is also some of the—I guess I'm going to call this company ecosystem or environment. So some ideas around security, how available or unavailable some of those things are, whether we want to white label or don't want a white label some of those elements. I'm guessing there's also some stuff in there around almost like patterns of use. Are people comfortable with search? Do they only want to search? Do they want a little bit of handholding in the navigational stuff? How much of it is driven by support agents sending things out, versus you trying to provide a self-service so people don't even have to talk to support? What else am I missing in there? It feels like you didn't explicitly say this, so this might be an assumption on my part, but is there also an element of either author quality of life or author workflow here that different companies, have different people working on documentation or updating documentation, and you want to find a tool that's going to help facilitate that piece of it? Kelton Noyes: [14:13] That absolutely can be the case, yes. I've had some companies where the only people that were writing documentation officially were in writer roles, whether it was through marketing or through sales or support, whatever it was. If you were a dedicated writer for those areas of your company, you were the only one with access and authorization to edit and revise content. But I've had some companies [where] it was more of an organic, free flowing thing. I've worked in startups where they just didn't have the headcount to have dedicated writers. And so it was more of whatever you learn, put it in this hub of information. And there was no quality control, no collaboration effort. It was just anybody that had something to share, just dump it on a page real quick and share it. That works as a quick and dirty fix, but it didn't take very long for people to realize that we have documentation. We have everything in so many different places, with no real conventional structure with how to locate it, how it's worded, anything like that. And so providing a tool or finding a tool where one or a few people can quickly access and standardize and share all the information and curate things, I would list it as a much higher priority than I think organizations, in my experience, have placed it. At the end of the day, an organization, they want a tool that works, but it's the challenge for your role as a communicator to be able to sell that, while we can have a tool that will work for us, that will provide the information, we also need a tool that can make my job more efficient and make my job a lot easier to not only expand and enhance the quality of what's already happening, but also to do it at a much faster pace or a much more cost-effective pace. Kate Mueller: [16:18] Particularly for organizations that are headcount conscious, being able to say, “Hey, if we get this tool, we won't need to hire somebody else to do this because I'll have faster velocity on being able to make these changes.” Sometimes that can be a compelling argument, especially for slightly more costly tools. I guess I'm also curious in your process of trying to figure out some of that hierarchy of needs, what's absolutely required versus a nice to have, versus, “Oh my goodness, we would never use that. It's irrelevant that the tool has that.” Have you had cases where managers or people higher up have felt very strongly that something was an absolute “need to have” requirement, and it wasn't? [laughter] Kelton Noyes: [17:05] Yes [laughter]. Actually, the “need to haves” and the requirements that were presented to me from one company was that we have to find a way to make a tool that we [already have] work. And so that was also a thing where it's like, we're not going to expand our budget, so we need to find something in our current suite of tools that will provide this service, but at the same time, they were asking, saying, “Hey, customers really want this. We would love to deliver this for our customers.” And the two were in contrast with each other because no tool that we had offered the things that the customers wanted and that they were expecting us to do. The way around that one was trying to help revise and present what is actually the need here. We found that if the client is big enough that the position can be changed a lot easier higher up. If we're looking at finding ways of saying, “Hey, if this client wants to have ease of access, so they want their knowledge to include external resources or links directly to our live training sessions, or we want to be able to collaborate and merge two different spaces in one. The integration component that will require that doesn't exist in Google sites, or whatever the case may be. And what we would need to do is we need to start looking around and finding something that can do that. But also, if we look and find, “What are some of your other needs? What are other company needs that we have? What are other departments actively using?” Because what I found is selling somebody on an idea of acquiring a new tool, the more all-inclusive you can find, that will make that tool not only better for you, but for other departments or other groups of people within your organization, the far easier it is to sell people on the idea that this tool is something that is going to be far more beneficial than what we currently have, and it's worth our time to invest in it. Kate Mueller: [19:14] So is that a little bit like, is this something that can help solve a fraction of marketing's problems or a fraction of support's problems, so that they have an easier tool to do this thing? Kelton Noyes: [19:28] Yeah. And that was one of the big selling points actually that I had when convincing the company I was working with to acquire KnowledgeOwl. And we can talk about the investigative process of everything as well. But when we're looking for KnowledgeOwl five years ago, selling them on the fact that we had an interactive glossary was one of the bigger selling points, actually. In the industry there are a lot of acronyms, a lot of high-tech terms that are flying around everywhere in the real estate space. And our sales teams were giving feedback, and our support staff as well, saying that “A lot of our time gets caught up if we're reaching out to a borrower or something and we drop an acronym or we say something and they just have absolutely no clue what it is that we're referring to.” And so finding ways to self-help people, because what I found as well, when creating documentation is nobody wants to feel dumb. They don't want to feel like they need help, but they don't want to approach themselves in such a way that it makes them be ignorant willingly. Kate Mueller: [20:44] We like to feel like we're smart, autonomous people, don't we? To feel that we can solve our own problems, and isn't it great when documentation helps somebody feel that way and solve the problem? Kelton Noyes: [20:55] Yeah. And so that was one of the big things that I found. And I decided to put more emphasis on “This is not only a nice to have, but it's a need for the industry specifically.” I could create a tool and on the back end I would have this list of all the acronyms, all the key terms in the industry. I would provide a 1 to 2 sentence definition and then in the documentation themselves, on the first or several mentions of that term, I would have a little tooltip icon, and all the customer would have to do is hover over it, [and] it would provide the full expanded explanation of what that thing is. Not only did it save me space on the actual page of the document, because I could hide information in the little tooltips, but it provided an additional layer of knowledge that made selling somebody on a tool that much easier. And our sales team started being like, “Look, we have a knowledge base. You can self-help, and if you have questions about something, it's an interactive knowledge base where you can do things, where we're trying to help make sure that the things that you may have questions on, we are giving you as much information as possible, making it as easy to identify as possible. And then if you still have questions, the knowledge base also provides a direct line of communication with our support team, you can send and submit a report request directly to our team. And that way, our support team also knows that they're getting your request from the knowledge base so they can see that you are trying to self-help, and either the answer doesn't exist, or you just may not know what the key term is. And so that not only informs our support staff on what you're trying to do in advance, but it also lets them know that you've made this effort.” And we found as well doing that, our support turnaround on our SLA times went down from a two hour turnaround time window to we could solve an issue with a customer in ten minutes. Kate Mueller: [22:49] There were a couple threads I wanted to pick up from some of your comments here. One of them is: I really like that you pick up on the fact that many of the problems that you end up solving are not problems that initially are identified as lack of documentation or as docs-related problems. It sounds like part of the driving factor behind that, “Let's consider an interactive glossary” was people sending emails that had acronyms that weren't explained in them, which is not necessarily, “Our official documentation doesn't explain what this acronym soup means,” it is, “Hey, as a salesperson or as a support person, I'm realizing that a whole bunch of our customers don't understand what these acronyms are,” and to then make that connection to say, “Hey, maybe documentation can help solve that problem.” Because it sounds like initially that was not necessarily like “We need documentation that will provide this thing.” That sounds like a need that you uncovered at some point as you were having these conversations. Is that fair to say? Kelton Noyes: [23:58] Yeah, it is. I mean, it's something that obviously around water cooler talk and things around the office that other departments and things had also expressed those types of concerns. It means being on a support floor when you're sitting right next to three or four other individuals also on phone calls, overhearing bits of conversation from their end, saying “This acronym means this term” or “This is what it means.” And that repetition was something that to me is always like: “If I have to say the same thing over and over again, how do I make it more efficient? How do I make it better, and how can I avoid saying it all together?” Kate Mueller: [24:33] Yeah. If I've had to say it three times, that's two times too many. How can I handle this in a way that actually scales? Kelton Noyes: [24:42] Yeah. Again, it's more of finding ways to empower people because I found a lot of ways that myself on occasion and other colleagues of mine, when they would communicate things, not only trying to explain what the term was, but how they would communicate that, we received feedback through customer surveys or things like that, where we would get mixed reviews saying, “Hey, this person was super helpful in explaining this piece of content, it was very helpful. It helped me understand the process holistically,” or others were giving the impression that the way the same answer was communicated, that they felt that they were being talked down to, or that they were having this mixed review. But the problem still remained that they did not know something. And so it became very much: “How can I solve this with documentation?” Again, with the focus of reducing support times, reducing the volume that would come in things like that as well. Because at the time when I was doing a lot of this investigative work for a tool, I was still trying to convince the organization I was with that being a technical writer full time was actually a full time job, and in technical writing, as well in communication in general, certain companies look at departments and they look at different things as far as what kind of value do you offer the company from a bottom line perspective, and communication and documentation is a very difficult one to show positive revenue or positive returns on because a lot of organizations I found saw it as a necessary evil or just a sunken cost. It has to happen, but there's no positive return. And so finding little tricks like that glossary feature or finding ways to help not only inform our user base, but to make it easy to answer questions or easy for them to navigate through their own problem solving. Kelton Noyes: [26:39] We could then leverage and say, since this knowledge base went live, or since we really promoted it, here's how our support volume has changed. And if it's shorter support times, fewer incoming emails, things like that, and then also being able to use a tool that has a back-end metric system for user access to a knowledge base or to the content that you've created, you can also support and supplement saying that these trends are going down. And it's not just because we have a really great support staff, but we also have hundreds or thousands or whatever the number is, of users coming and visiting and reading this content, and they're staying on these pages for 5+ minutes, which means they're reading it and they're processing it and they're trying to do things with it. And with the increase of knowledge consumption and the decrease of support staffing, you can draw those correlations and parallels saying, “This is why we have this tool. This is the value that documentation and communication offers.” And at that point, it becomes a much easier thing to fully invest in and say, “Great, how can we make things better?” And then getting other people in other departments saying, “Yes, and now we want more.” And so the evolution of features and needs, and it becomes so much more than just your responsibility as a technical communicator; it becomes a much more collaborative effort across multiple departments within the organization, once you've been able to to get the buy-in. Kate Mueller: [28:09] It's interesting because I think documentation, as well as support, are often seen as cost sinks. You have to do them. And what you're describing is sort of a way of proving the value of documentation by saying, “Look at how much it reduces support costs if we have good documentation,” which changes the nature of the conversation a little bit from, “Documentation is costing us so much money,” to “Documentation is saving us from having to hire ten more support agents” or whatever it might be. If you can have the numbers to kind of prove that once you roll out that documentation, your SLA times improve, or your time to close overall improves, or your ticket volumes in general just drop whatever that might be. So it is definitely one way to make the case. There is something I want to pick up here. You mentioned earlier on the idea of are there ways that we can find additional groups whose problems might help be solved here? So that the tool becomes not just the thing we're using for this, but that it has these ancillary benefits to other teams. And I think that is a great way to make the case for good documentation tooling. But on the flip side of that, I have definitely talked to folks who feel like, “Oh, well, we'll get this one tool and it will solve the problems for every single group that might have to deal with documentation.” They end up coming with this wildly unrealistic set of expectations: the one tool to rule them all will solve all of our problems and life will be great. So I'm curious how you kind of thread the needle between those two to say, “Yes, it will help solve some of these problems, but I'm not going to over promise that it's going to solve everybody's problems.” Kelton Noyes: [30:11] For me, the biggest thing was if I can find a tool that provides a lot of benefit in one or two areas, it's saying that while I'm a dedicated writer for this company, and that is my job to provide technical documentation, depending on the size of your organization, you may not have the bandwidth to provide documentation for every organization. So the tool itself, I've been able to sell it as, this is a first milestone stepping stone towards a goal of unifying communication across the company. That this is a tool that can help provide those services, obviously also understanding and redefining what the end result or the end desire of the tool is going to be used for is a tremendous thing to have to understand, because every organization I've worked for has the Atlassian suite. They've used Confluence, Jira ticketing, everything like that. Engineering lives and dies by their Confluence documentation and their internal docs and things like that. And so, I was very quick to understand and realize that a new software tool for documentation is not going to replace something that across multiple industries is very standard. But what we can do is we can find a tool that bridges a need of centralizing information as much as possible, or what we feel is information worth sharing. Kelton Noyes: [31:43] And so in my efforts in collaborating with product managers, with product marketing, with our training departments and other things as well, establishing a primary focus for the software tool, in my case, it was the end user experience, customer access to documentation to helping support them. But then we were also looking for tools. How can we use the current set of tools to improve our internal experience? And as we were looking through additional tools to find what we can do, it became more of a “Well, if every department needs this information and our sales team is asking engineering all the time about certain questions, certain feature sets or things like that, then maybe what the tool can be is also: I can get information from engineering and then put that in a folder for employees, depending on how you permission set with tools.” And so one of the things that we really looked at doing was a conditioned documentation where we can tag a certain user group where they will have access to certain pieces of content that others don't. And so we had an end user tag set up with the current tool that we're using, which is MadCap. And that is one of the big selling points that they offered for that as well: we can use one tool, we can create and publish content in a knowledge base. Kelton Noyes: [33:08] And then depending on the user level, we could give them access to different levels of information. And so that became a huge selling point and a huge thing of excitement, where not necessarily are we expecting everyone to write their own documentation, we just kind of file it away where it goes, but they can give us pieces of information and say, “Hey, this is great stuff. This is stuff that our sales team or our integrations teams or different things need access to. Their things are constantly out of date, but we're communicating with you on a weekly or monthly basis. And so you have the most current information outside of engineering. Maybe you can use that information and use that knowledge to create a place for other departments to know that you just go here, you can look at this, and based off of the tag that we have set up, you can have a visual representation of: this is the stuff that you're looking for as an internal employee.” And that becomes more of a collaborative space as well with our end users. And our customers had access to everything that they wanted. Our internal teams had access to everything that they needed, and that was something that we found a lot of success with in a collaborative space. While understanding that engineers have their own documents, they have their own processes and things. Kelton Noyes: [34:16] I'm not trying to take over their space, but I'm just trying to show the company that we can have a unified space where the information that we need to share can be centralized and can be focused somewhere, and then at that point it becomes: this is what the tool can do. And then we have a conversation of, now that we have this tool, who are going to be the main players to make sure that that goal can be reached. And so that becomes more of a head count. Or do we have designated writers in different departments, or do we have designated communication points that are responsible for curating information and sending it to myself or one of my other colleagues or whatever the case may be? And that to me, and that approach, is something that really helped sell the idea of the tool. It may in fact be the one tool to rule them all. But we have to use that tool properly. We have to use it with a goal in mind. And then that either should take additional time or additional resources in other areas. And that's okay. But we have the tool that once we get our ducks in a row, when everything is lined up, we have the ability to make that happen. Kate Mueller: [35:34] Out of curiosity, was that idea of group-segregated content. Was that a requirement you defined when you were searching for tools, or did that grow organically after you selected the tool and started exploring the capability? Kelton Noyes: [35:51] It was something that happened while we had an existing tool. And so one of the big things that I found was so helpful in looking for tools in investigating processes was if a software company has the ability to let you demo or have free trial periods of their product, when you're looking at it, you absolutely take advantage of demos, every single time. And during the process that led to KnowledgeOwl being the tool we chose, I had scheduled demos with seven or eight other software companies as well in the early stages, and we weren't sure yet what we were looking for, it just needed to be better than what we had. Kate Mueller: [36:41] [Laughter] Yes, I think many of us start from that place. Kelton Noyes: [36:44] And my managers at the time also had mentioned that they had never worked directly with a technical writer or technical communicator before, and so they could provide insights as to what they wanted or what the company's expectation was that the tool could do. But they let me lead the conversation and exploration part mostly by myself. But having managers and having other people come in for the first, I think, two or three demos. My manager, we had the support manager, and we had someone in engineering come and sit with me a little bit who had been with the company for a while. They had more of an idea of what types of tooling we were looking for, and so being able to take notes and listen as more of an audience member in those first few demos to kind of get a feel for this, these are the points that the company thinks they want. And this is the stuff that they're looking for. And then once I got into the tool and I started demoing things, I started using the free trials to build just really quick documents and then seeing what could happen. That part of segmented content where we could condition things that came during the exploration in the trial process, trying to figure out what I can do with this, because certain pieces of software, they came in and they were offering their services at various price points. And so also when trying to figure out what the best fit from a pricing versus feature standpoint was. Kate Mueller: [38:45] Yeah. Kelton Noyes: [38:18] It became a way of “How do I min/max what we can do with this?” and conditioning content and being like, “Hey, we can do this kind of a thing” and then sharing it to my managers and things like that. It was very quick that we didn't have any idea that that was a possibility because the tooling that we had didn't offer that. And they were inexperienced enough with the documentation creation process that it became almost this revelatory announcement that quickly became a very good selling point in making sure that, “Hey, we want to be able to do this. So that way, not only does it save me time as the writer, by only having to write something once, then I can condition sections out as we go, but it gives the exact audience that we're looking for the exact information they need.” Kate Mueller: [39:10] It's a really good point to note that that requirements definition evolves as you get further into the process. So you start with what you think you want, which is often driven from a place of pain or frustration with whatever your current reality is. So usually those are the things you think of as, “These are the pains that I want to address now.” And then you don't necessarily know the other things that tooling can do because you've been stuck in whatever the world you have is—whether it's the one giant Word document or an existing tool of some kind. And I think sometimes people do not put enough time and energy into, “Let me go to demos and let me actually do a trial of the thing and explore the feature set myself” because that is the moment where you start to put together: here are some of the things that I thought were maybe features I thought we would never use, but now that I'm getting familiar with the product, I can see that this actually helps us solve a problem that we hadn't articulated that we need to solve. And that has maybe shifted some of what our hierarchy of needs is, so that now that we realize that the tooling could help us solve this problem, this has suddenly moved to a need to have instead of one of the like, “Ah, what would we do with that?” I have had a similar experience where it's like until I get into the tool and I try it, I can't make those connections, but once I'm in the tool, it becomes much clearer to me what I'm capable of doing with it, in the constraints of what the problems I'm trying to solve, the content I'm trying to work with. I appreciate that you mentioned it, Kelton, and this is a great note for us to take a break on, so we will be right back. Kate Mueller: [40:50] This episode is sponsored by KnowledgeOwl, your team's next knowledge base solution. You don't have to be a technical wizard to use KnowledgeOwl. Our intuitive, robust features empower teammates of all feathers to spend more time on content and less time on administration. Learn more and sign up for a free 30-day trial at knowledgeowl.com. Kate Mueller: [41:21] And we are back. So, Kelton, there's a couple of threads from stuff you said in the first half of the episode that I really wanted to tug on a little bit and get you to talk more about. One of them is that you successfully made the case for transitioning from being a support person to being like a full-blown writer and having that be primarily what you worked on. And I really want to know a bit about how you did that. Kelton Noyes: [41:49] All right. It became more of a mindset shift on my end. Early in my career with tech support, when I was looking for things, I would try to sell managers and other people on the idea that documentation was important. And I quickly realized that that's kind of a nonstarter, where everyone's like, “Well, obviously documentation is important, so why should I consider you as the guy to do it?” [Laughter] And so it became a pursuit over a couple of different companies of saying, “Okay, what I need to do is look at the documentation that currently exists and see: is there a role even with this company? Does the company value it enough to have something already in place?” If so, great. Let's talk to those people. Let's try and find what I can do to help join your team. And that wasn't the case that I was able to find the in on. It was more of: how can I leverage documentation and my skills as a writer and a creator into showing that there is something more that can be done with documentation, and I am the person that can do it. And so there were a couple of things where I took one approach, where I revised an entire internal training, an internal training regimen from a three week course of learning how to do—I believe it was a customer success role with an organization that I did customer support for a while in that capacity. I had a three week training session to get aware of what the job is. Kelton Noyes: [43:33] I found that 95% of the training was useless to what I was doing as soon as I hit the floor, and it wasn't necessarily anybody's fault, it was a new role in a new position, and people didn't know how to train about it. But as soon as I got into the role, I realized there could be so much more here. So I ended up writing 30 to 40 pages of “Here's actually what you need for this role. Here is how you do things, here is how you specialize and how you can get up to speed.” And then I took that to my manager and said, “Look, the next person that comes in in this role that is assigned to our team, let me take them off of the training floor after like day two, after the orientation and the tooling introduction and things like that. Let me grab them out of the training and go through this process with them. Show them these docs and let's just see what happens”. They bought in on that. I was able to work with a couple other people in my department that were also very good at the job, and that were willing to help spread out the training responsibilities. And it took maybe one or two individuals that we pulled off the floor in a traditional expected three month ramp up time. We had them up and running with 150 accounts that they are responsible for in two weeks. Kate Mueller: [44:56] Wow. And the original training just on its own was three weeks. Kelton Noyes: [45:00] And we had people that were proficient enough at the job, quick enough to know the tools and know how to go about the job, that they were managing over 100 accounts on their own within two weeks. And so that turned a lot of heads really quickly. And in taking that to management, at that point, I had established that I can create value with documentation, and so I was able to sell it. And then the last thing that really got me over the edge was convincing somebody that documentation is a department or is a position in itself, because at that particular organization, they loved the idea, they loved the documentation I was doing. But the feedback I got was, “We're not going to make this a full time position, because you're also really good at your job in support, and you're one of our top performers in support. So how about you just do both and you keep doing these docs and you keep revamping training.” And so it was finding the last piece where my opportunity came when I was hiring, when I was interviewing for other positions, and my current position, I came in with the expectation of being a support representative as well. But my hiring manager ended up seeing that I had a background in English. We started having conversations about documentations if I've used my English degree for anything, and then explaining these things that I've done beforehand, the hiring manager is like, “We don't have this yet, but I'm going to make a budget for it and I think you're the guy to do it.” And so the understanding was, “You are going to be the person I can convince to create the role for.” Kelton Noyes: [46:36] And so all you have to do is be a support rep for a couple of months, learn our product, learn how things go, and then start doing exactly what you just described you did with the training team, and then I can show other people with it.” And they were so convinced and so impressed with what I did and my output that rather than creating a role specifically for technical writing, because that didn't exist at the time, they took the company's budget out of the support role, and they just flipped the title over, and they moved me into technical writing, with the idea that “You're going to be a technical writer three quarters of the time, but because we had to make this roll out of our support budget, you still have to field support calls for a couple hours a day or something like that.” And so it became a quick transition period. And then as soon as I was able to establish finding tooling, creating a knowledge base with meeting the company's expectations on launch, as far as the amount of documents, the amount of things in there, as soon as it went off and the support numbers and everything went down, they're like, “Okay, yep, absolutely. This was the right call. We need to get this guy off the phone right away because this is a full-time gig.” And so they made the official transition to full-time technical writer within about five or six months after giving me about three quarters of the time. Kate Mueller: [48:04] Nice. It's interesting because I've heard various versions of stories like this, and then like, people just get stuck doing both roles for forever. And it sounds like one of the big, maybe two big things that worked in your favor here were: one, that you had that demonstrated example from previous work experience where you could be like, “I used documentation to help streamline this training effort. And here are very specific numbers about how that changed,” which opens the door to that much more nuanced conversation around “What can you do with this?” And then you delivered successfully when they gave you the space to do it. So it helped make the case just by you performing well in that. Which is great, because I do know folks who've been stuck splitting their time for years between the two, and it's so challenging. Kelton Noyes: [48:55] It's challenging and it's very frustrating because I've done that before as well. And it's very discouraging for you as an aspiring writer to want to do both. Kate Mueller: [49:05] Yes it is. Although on the flip side of that, it is great to have a couple of months of support because it helps you really learn both the product and the customer base and that, I think, really does help inform decisions that you make on the documentation side. The key is just not getting mired in that forever. Kelton Noyes: [49:24] Yeah. So like I said before, it was just: people understand that documentation is important. And so it was more of a mental shift, and how do I approach and how do I sell? Not that documents are important, but the work that I do specifically lifts and elevates and makes the documentation perform at a much higher level. Kate Mueller: [49:45] Yeah, you're selling yourself as the person making documentation, not just that documentation matters and is important. Yeah, that's an important distinction. Also, I would think a little bit harder to shut the conversation down because otherwise people will say, “Well of course documentation is important. It's just not important enough for us to fund it. But it's important.” [Laughter] There's also something—I feel like we were getting at a bit in your description of some of the evolutions of tooling choices and where some of those goals went, which is that it feels like some of what you're describing there is a little bit a shift in the culture around documentation, either around how important documentation is or the role that documentation plays in the organization. So once you roll out a successful documentation tool and people get used to it being there, and customers get used to having documentation that will help them solve their problems. As you said, that changes it more from a “nice to have” to a requirement, and sometimes that gets you additional requirements. And this is in and of itself, I think, a cultural shift within an organization to say, “Wow, we don't just say documentation is important. We recognize that documentation's important. We want to put more effort into this.” And that kind of whole culture shift then changes the goals that you have for your documentation. Kate Mueller: [51:23] One of the common patterns I've seen working at KnowledgeOwl is that people come in and their initial goal is like, “I want people to self-serve so that we just get fewer support tickets” or whatever. And then after they've had a knowledge base for a period of time, it becomes not just “I want them to self-serve” [but also] “Maybe I want to put my release notes in here” or “We've been hosting our API documentation in this other tool. Could we host it here so it's with all the rest of our stuff?” Or, like you were describing before, “Can we pull in some of this genius stuff from our engineers without touching their engineering wiki, but getting some of that knowledge into a place so that sales or support or marketing can use some of it?” That is inherently a cultural shift about documentation that then informs new goals. Is that fair to say? Kelton Noyes: [52:21] That's absolutely fair to say. And it fueled a lot of additional conversations that I had as well, where I had sales reps for other people reaching out saying, “Hey, we have this great feedback from a customer. Is this something that the tool allows us to do?” And people not only become more invested in what documentation has to offer, but then they start becoming more invested in, “How do we improve it? How do we make it better? And can the tooling that we have support this?” And everybody became invested in it, where documentation was important and great for our sales team, it was like, okay, the fact that we have a working knowledge base that I can live demo for people is now a baked-in part of my sales pitch. And it wasn't beforehand where I'm like, “I am leveraging like, hey, if you want to come with us, this is like an extra goodie that you know we're not offering. You don't have to pay us anymore for this knowledge base and this knowledge resource. But this is what we have to help you, help your own customers and help your own employees. Everyone can access this.” And it became a massive shift to where people became excited to see what we can do, excited to see where we can take documentation, how things work. As soon as that shift happened, I ended up getting reassigned to work with the training department for a while as part of that. And so I got to sit next to a couple of our company trainers, and we spent hours just debating and figuring out ways to improve each other's lives, from a training and a documentation perspective, where it became a coordinated effort to say like, “Well, I personally don't have a lot of video editing experience or using those tools, but the trainer is a master of it.” Kelton Noyes: [54:11] ”He does it all the time, and he's really bad at writing his scripts or things like that.” And so it became more of an exchange of services where we would talk about trainings, he would demo some trainings for me, and so I would help him revise and edit his scripting to communicate the information properly and basically fact check him on what the tool actually does. And then he would create these great videos and really good walkthroughs, and we would find ways to embed and create that as well. So I would have a document that supported a professional training video and then the written documentation behind it as well, because as people shifted their perspective on documentation, it became more of a “How can we maximize our customers self-serving and learning?” And so instead of just a bunch of words on a page, “How can we leverage our UI to help assist in the learning process? How do we make sure that our UI is up to par? How do we revisit editing and taking screenshots to maximize what people can gain from one screen’s worth of information? Or also getting feedback that we have visual learners, we have audio learners and things like that. So we created multiple types of media to present that information. And it was a really wonderful time to see that shift and that buy-in ways that I hadn't originally anticipated. Kate Mueller: [55:38] Yeah, completely. It's like it grows its own legs and then suddenly entire areas you never thought of open up and you can do stuff with them or collaborate with people you didn't even know existed before. And it also feels like that might be the impetus behind realizing that you need to reevaluate your tooling and potentially pick new tooling, as it's kind of like a docs maturation process. Like: we've solved our initial problems here. We've now built this sort of larger culture around this, which has given us new problems that we want to solve. And maybe our existing tooling can't do that. Now is the time for us to consider additional tooling at this point. Kelton Noyes: [56:25] Yeah, that's exactly how things had happened and evolved, and at least in my experience, that while we had this great tool and people were buying in on it because the buy-in was so good, and because the momentum of working in a startup was so fast, it did not take very long to realize that I could not keep up with the pace and the demands on my own. And so the company reached out and started looking at getting an additional writer dedicated for it, which to me was awesome because every company I've worked for beforehand had one tech writer, one tech communicator, that's all they had. And they're like, “No, the buy in is so big, we need another writer.” And so they brought in another seasoned writer that was in technical writing for 20+ years, that really knew the industry, which was a huge win for me on a personal level, because while I knew I wanted to do technical writing, I've never worked with a professional technical writer before. And so I was just learning as I went. And then seeing his perspective on things was absolutely fantastic. Once he came in, he learned the product as well. And then it became a conversation of, “Alright, how do we use and really leverage a tool? You found a good tool. So now let's look at this.” And we started talking about [how] he saw technical writing as more of an extension of engineering. And so it became more of a “we are building something.” Kelton Noyes: [57:53] “We're not necessarily building the tool that customers use, but we're building the tool that supports the tool.” And so, we need to have a similar workflow and a similar process to this, and it doesn't look good for anybody if we publish something and it goes live and there are a bunch of typos or a bunch of things that weren't coordinated or we missed something, and then we have to hurry and take it down and fix it and bring it back up. What we can do instead is this concept that was unknown to me at the time, of branching work and having a live website and a live knowledge system, but then what we want to do is we want to be able to break apart from that and branch off of the main route. And we have these behind the scenes locations where we can keep building and curating and editing and doing all these other things. And now that we have two writers between us, we can begin this peer editing process where it's not just relying on the knowledge of the product teams and things to verify that the software and the workflows are correct. It became more of a writing focus as well, like “What is our voice going to be?” I tried to maintain a consistent voice in documentation and a consistent style, which was fine, but now we had another writer in place. And so it's like, “Now we need to start thinking about it like a stylistic guide.” Kelton Noyes: [59:14] ”How do we want our official company voice to be? How do we coordinate that? How do we communicate that? And how do we work together as writers to make a better product?” And with those conversations and with the ideas and the other writer's experience, it became very apparent that KnowledgeOwl was no longer a fit, that we were outgrowing what KnowledgeOwl was capable of. And so that, plus the additional requests coming in from our company and our organization and that buy-in, it started the process all over again. He had used MadCap before in other companies that he had worked with, so he was kind of familiar with its capabilities and what it was able to do. And so he led the demo process and the trial process. And then I was able to watch and see additional layers of questioning, additional layers of feature set acquisition with bigger products that were completely off of my radar originally. But then seeing just the power and the ability of what a larger tool can do. And not only was it a lot easier to do some of the basic features that we had already with KnowledgeOwl, but now we could take it into four or five other areas that we weren't able to do previously. And that became a very exciting thing for our organization to hear as well, that we have additional editing and back access and additional metrics to pull from, because the metric system became something that was almost a weekly report I was pulling, and they really wanted to know how many people were using the knowledge base. Kelton Noyes: [01:00:59] And then we got to find additional pieces of content or additional metrics that were offered by these other tools that were so much more impactful from an organizational mindset that it just became a very natural evolution to then have a tool that could grow into what we were doing. And not only were we finding a tool that we could use in the moment, but we were also looking to continue to scale the effort where at this pace that we're going, we don't see a change. We don't see anything but more growth, so will this tool provide for three or four or even a team of like five writers that can all coordinate and work together? And that was one thing that I hadn't thought of when I originally was looking for tooling because the company was small, I had no idea what I was doing. I was just a tech writer. And so it became a very good opportunity to predict the future in a way. Where do we have tools that not only meet our needs now, but we can still grow into them, and we still have years worth of growth that we can make after we acquire this tool? Kate Mueller: [01:02:10] But it's also worth noting that you can only see the future that you can see, right? And so you're picking tooling that feels like it's a good fit right now and for the future that you believe you see coming. But you might get two or three years into that, and the future that you thought was coming is actually really different from the future that has actually come. And that's a good problem. Generally speaking, that's a great problem. You solved the problem you initially had. You solved it well enough that for a couple of years you could kind of just stick with that same tooling set, and then you hit a place where it's like, “Wow, we've been so successful. We have new problems now.” And some of those problems are, “Hey, we're going to bring more people in to do this. Hey, we are expecting this level of maturity in certain feature sets, or we now need features that we never needed before.” And that to me is really healthy growth within a toolset or within a tech writing organization, group, team, whatever, because you don't really know where you're going to go until you have gotten part of the way there. So you're making educated guesses more or less. And sometimes you guess really well, or your company gets acquired and they lay off half the team and suddenly all that fancy tooling you needed, you actually don't need so much now. You need something that's more streamlined for two people or what have you. So it is interesting because you're trying to select tools that will grow well, while also recognizing that the exact nature of that growth is not necessarily knowable. So you're trying to make good decisions, and sometimes you do and sometimes you don't. Kelton Noyes: [01:03:57] Yeah, exactly. And that's part of what we're going through right now: my organization is experiencing yet another transition, just exactly what you talked about, where we're going to be leaving MadCap for another tool. And that was inspired a lot because of company acquisitions and things. And so that is another piece to consider as well, that if you do so well that other people take notice and do something about it with company acquisitions and things, it became a wonderful experience as well, where not only do you get fresh perspectives of other offerings that your now combined company has, but a lot of these acquisitions also came with their own writing team, and so being able to have a combined writing department and learn from all these other perspectives and industries and things like that. It was a very exciting thing to hear about that, and then also to say and realize that we have all this great stuff together. Let's realign style, let’s realign documentation. And because we're making all these different shifts, we didn't do anything for probably about a year and a half or two years after the acquisition, simply because the company wanted to make sure that everybody had time to breathe, get used to what everybody was doing, and we can learn about it. And now that we've had this maturation period where we've been together for a while now, we have an idea of what each other's processes and workflows are. The writing management team got together, and [was] like, “Alright, now we're ready to look at something that's going to work for everybody.” Because where I was working in the space that I was in was focused, and we had MadCap and we had this great tool, that was not the quality of software, that was not the quality of tool that they had access to. Kelton Noyes: [01:05:42] And so it was also a learning opportunity to kind of share, “Hey, this is the kind of stuff that we can do on our end with this tool, and it's different than what you can do, but it's also different because your needs were different.” But now as a way of opening everybody's eyes to: tooling matters and tooling can be impactful, and this is the kind of stuff that we can do, which were things that they weren't either aware of or didn't have the capacity to. And as soon as they saw the value in it, too, it's like, “Okay, well, we're going to use you as a template for a new standard of documentation across every part of the company. But your tool doesn't seem to quite fit exactly what everybody collectively needs. And so let's find a new tool that we can make this plan to transition everybody into, where everything across the board will become far more standardized.” And those earlier goals that were years before of consolidating information, bringing everything together into one centralized place, that there is a path moving forward now where those things can happen. And a lot of it is because of the tooling and the staffing changes, where it's not just me doing my own thing for a whole company, it’s me [plus] a team of other writers. It's so many other people that have really bought in on this idea, and now we have more opportunities for that collaborative effort to happen. Kate Mueller: [01:07:10] Yeah, and in some ways you're revisiting some of those same goals, right? Let's have everything in one place. I'm not sure that goal ever goes away, frankly. It's just that you redefine what everything is and you redefine the place that you want it to be. Kelton Noyes: [01:07:28] It's just like our hierarchy of needs. We redefine what excellence is every year, and that's based on what happens in the world, in world markets, in the marketplace and things, versus internally what happens with companies and our company growth and company decisions and objectives and being able to pivot and leverage tooling as a way of, that was another great selling point and opportunity with the different tools that we had, was if the company needs to change what they align with, how easy is it to use our tooling and leverage that as well. And some tools just don't have that kind of flexibility to be able to pivot into a different perspective, at least as easily as others. And so that was also something that was considered when we were looking at different tools along the way was: if we need to hard shift or hard pivot into something else, does that mean that we have to acquire new tooling for every major shift, or is this something that we can use the existing tooling for to make that shift with us? Kate Mueller: [01:08:34] Yeah, or how creatively do we have to try to use that existing tooling to make that shift happen? Sometimes you have to get very creative to make it work and sometimes not. Sometimes you discover layers to a tool that you didn't know were there because you didn't have the need previously. What would you say, in your experience, have been some of the red flags to indicate it's time for us to reexamine tooling? Kelton Noyes: [01:09:03] One of the initial red flags that I found was knowing the audience that you had to reach out with using your tooling. In my case, with our knowledge base, our knowledge content, one of the big concerns that the organization had was we didn't just want anybody to access our content unless they were a customer of ours. And so finding tooling at the time, like SSO authentication protocols or other ways that we could validate that this is a confirmed account holder with our service. That became a red flag really early when the initial tooling didn't offer that kind of an option, where doing a lot of research and a lot of market research as well in finding what our competitors were doing, and how they were doing things in the knowledge space. We were just making decisions based off of that and realizing that we needed a tool initially that could offer that was a very big flag that became as essential as, if you don't offer this, then we're moving on to a different provider. Another one as well that was a flag was simply just as I mentioned before, the growth opportunity where we got additional writers. How easy is it to collaborate in that space? Is it just a one man show, or is it something that we can have many different people editing and curating content and things? Kelton Noyes: [01:10:44] And how easy is that transition or how or is it just an impossibility? So that was a big flag. And then I think the other major flag that I had found and noticed as well is from an authoring perspective, does this software work within multiple or singular operating systems? And that's kind of a really random thing that a lot of people don't consider. MadCap, for example, is a software tool that's incredibly powerful, but it is built completely on a Windows operating system engine. And so if you're a company where your tech stack is all invested in Linux or in Apple or other operating systems and platforms, is that really the right fit for you? Do you have the ability to acquire Windows servers or be able to work your way into their tooling, or is it something that would be such a hassle that another choice is going to be better for you? And so looking at, I guess system requirements is a big red flag, too, where what exactly do you have and does your company offer even the hardware or the ability to really use the tool the way that the tool is made? Kate Mueller: [01:11:48] Yeah. Or does it hamper the tool’s usage in some way because it's really more optimized for a different tech stack? Those are really good. We've covered so much ground, Kelton and I really appreciate all of your insights and experiences that you've shared. Are there any resources that you think would be helpful to share? They don't have to have anything to do with what we talked about, but I do love to steal resources from other people [laughter]. Kelton Noyes: [01:12:17] Not necessarily related to the conversation we had, but there is a tool set by Sapling that helps improve the quality of writing in general, that one of the big things that I found when collaborating and creating style guides and things was we want to speak, in our particular instance, everything we give from a communication perspective is in present tense with active voice, and that's how we want to communicate to our individuals. And Sapling has a site where they do have a passive voice tracking tool, where if you're writing something and you're not quite sure if your writing is completely consistent, you can just copy and paste what you've done into this tool, and it will automatically flag instances of passive voice. And then you can continue to work through things. They also have other tools, such as a passive to active voice changer, where they can actually modify, and you can leverage ways of helping change your style and your tone and going through things. And that was something that I was introduced to a few years ago that I used so consistently, especially as a way to just to improve my own skills as a writer, because that was one thing I found, was I'm very much a, I will write off the top of my head, and it's a very organic and very natural conversation that I'm having with myself, but I'm not consistent in my voice with myself. And so as I was able to copy and paste my documents through this, I got several instances of, “Oh, this one paragraph I'm speaking in the third person or first person or whatever the case is, and using active or passive voice.” And that really helped leverage that part of sharpening my writing skills is how do I develop, how do I know the signs? And being consistent in tone, in style and things like that. And so that is a tool that I really like. Kate Mueller: [01:14:20] I like it. We will share a link to that in the show notes. And also Kelton, what is a great piece of advice that you've been given? It does not have to do with tech writing. Kelton Noyes: [01:14:32] A really good piece of advice that I had was to simply learn to advocate for yourself, and learn that if you have an idea that is worth sharing, it is worth your time to learn how to share it. Kate Mueller: [01:14:49] I know a lot of tech writers and support people who are very good at advocating for customers, but often not very good at advocating for themselves or their own ideas. And I suspect sometimes we need to be able to say, “You know what, I'm just like a customer. I'm just as deserving of advocacy as a customer is.” Kelton Noyes: [01:15:13] Yeah, or a lot of times where you think that you may have a wonderful solution, but you don't know how to communicate that to other people in a way that you intend or the way that it helps create these culture shifts that we've talked about and things of that nature. And absolutely one of the best pieces of advice I got was: if you have a great idea, it is worth your time to learn how to share and to learn how to communicate it. Kate Mueller: [01:15:44] Yeah. And then lastly, Kelton, if you want people to follow you or get in touch, how would you like them to do that? Kelton Noyes: [01:15:52] Through my LinkedIn profile would probably be an excellent place to go and just reach out. Kate Mueller: [01:15:56] Perfect. We will link to that in the show notes as well. If you want to go hook up with Kelton and pick his brain about any of this stuff. Well, thank you so much for your time and your generosity of knowledge. This has been fantastic. Kelton Noyes: [01:16:10] Yeah, thank you so much for having me. Kate Mueller: [01:16:17] The Not-Boring Tech Writer is co-produced by our podcast Head of Operations, Chad Timblin, and me. Post-production is handled by the lovely humans at Astronomic Audio with editing by Dillon, transcription by Madi, and general post-production support by Been and Alex. Our theme song is by Brightside Studio. Our artwork is by Bill Netherlands. You can order The Not-Boring Tech Writer t-shirts, stickers, mugs, and other merch from the Merch tab on thenotboringtechwriter.com. You can check out KnowledgeOwl's products at knowledgeowl.com. And if you want to work with me on docs, knowledge management coaching, or revamping an existing knowledge base, go to knowledgewithsass.com. Until next time, I'm Kate Mueller, and you are the not-boring tech writer.