Caity Cronkhite is the CEO and Founder of Good Words, a technical communications consulting firm based in Seattle, Washington and remotely around the globe. She attended Carnegie Mellon University and moved west to work as a technical writer and eventually as an entrepreneur. She also serves as Communication Chair for Seattle’s Entrepreneurs’ Organization and is on the Leadership Council for the National Small Business Association.
Caity is passionate about using her personal and professional experience to uplift others, which includes advocating for rural policy change, increased labor protections for freelance workers, and empowering employees with meaningful career opportunities.
Here’s a glimpse of what you’ll learn:
Caity Cronkhite explains how Good Words helps people
The keys to excellent documentation
How do you differentiate yourself in the documentation market?
Caity shares the best practices that apply to anyone writing for customers
Good Words’ customer success stories
How AI is impacting technical writing and documentation
In this episode…
Technical documentation plays a crucial role in any organization. It can make life far simpler for your customers, developers, and employees while also contributing to the success of your organization.
With technical documentation, Caity Cronkhite recommends hiring experts who can deliver world-class API, product, and internal documentation. They ensure that your documentation is quality and is easy to understand at each stage of the process. If you haven't already, it's time to invest in world-class technical documentation and see the difference it can make for your organization.
In this episode of The Customer Wins, Richard Walker sits down with Caity Cronkhite, CEO and Founder of Good Words, to discuss how companies can thrive through good technical documentation. Caity shares the keys to documentation, the best practices for writing for customers, and the impacts of AI on technical writing and documentation.
Resources mentioned in this episode:
Sponsor for this episode...
This is brought to you by Quik!
At Quik!, we provide forms automation and management solutions for companies seeking to maximize their potential productivity.
Our vision is to become the leading forms automation company by making paperwork the easiest part of every transaction.
Meanwhile, our mission is to help the top firms in the financial industry raise their bottom line by streamlining the customer experience with automated, convenient solutions.
Go to www.quickforms.com to learn more, or contact us with questions at support@quikforms.com.
Episode Transcript:
Intro 0:02
Welcome to The Customer Wins podcast where business leaders discuss their secrets and techniques for helping their customers succeed and in turn grow their business.
Richard Walker 0:16
Hi, I'm Rich Walker, the host of The Customer Wins, where I talk to business leaders about how they help their customers win, and how their focus on customer experience leads to growth. Some of our past guests have included Randy Cass of Nest Wealth and Patrick Meyer of Docusign. Today I'm speaking with Caity Cronkite, founder and CEO of Good Words. And today's episode is brought to you by Quik! the leader in enterprise forms processing. When the last step to earning your clients business requires processing forms, don't ruin a good relationship with a bad experience. Instead, get Quik Forms to make processing forms a great experience and the easiest part of your transaction, visit quikforms.com to get started. I'm really excited to talk to Caity today. Caity Cronkite is the founder and CEO of Good Words a technical writing and documentation consulting firm that's on a mission to rid the world of bad docs. We need that mission. Good Words delivers ongoing strategic management and implementation support for some of the most technically sophisticated companies across industries. All the way from Fortune 50 companies down to five-person startups. Caity graduated from Carnegie Mellon University with a degree in technical writing and communication. Caity loves talking about the intersection of writing and technology and convincing skeptical people that good documentation could change the world. Caity currently lives in Seattle, Washington, and when she's not running her company, she enjoys gardening, bodybuilding, road trips, mentoring, and restoring her historic Seattle home. Caity, welcome to The Customer Wins.
Caity Cronkhite 1:47
Thank you so much for having me Rich, excited to be here.
Richard Walker 1:50
Now, if you haven't heard this podcast before I talk with business leaders about what they're doing to help their customers win, how they built and deliver a great customer experience and the challenges to growing their own company. Caity, I want to understand your business a little better. How does your company help people?
Caity Cronkhite 2:04
Absolutely. So as you introduce my company has Good Words. And we write documentation primarily for very technical companies. So most people think of documentation as this boring thing that they have to do that's necessary, but a necessary evil. And we like to put a new spin on documentation, I truly do believe that good documentation can change the world. And we like to bring that ethos to our customers. So, when our customers bring us in to help write docs, we really are there to act as advocates for their customers, how are their customers using their products or engaging with our services? What does the customer need to know? What do they need to do to be able to be successful and to get on with their day. So that's kind of the cliffnotes version of what we do and how we like to help.
Richard Walker 3:01
It's funny, when you bring this up, like documentation is boring, who wants to read documentation, I even make the joke, not a joke. It's actually part of our own company culture that our software has to be so easy to use, it does not require a user guide, because I just have the belief that most people don't want to have to go to that level of depth. But you're bringing up an opposite perspective, which is, you know people have to go to that level of depth to how do we make it better and easier for them to get the information out of the documentation? And what do you think some of the keys are to great documentation?
Caity Cronkhite 3:31
Absolutely. I mean, one of the keys, I think, is to keep in mind that people hate reading docs, nobody is going to the docs, because they want to be there. Right. So, as you mentioned, ideally, if your customer is working with your product, or implementing something or trying to learn a new skill, they should be able to go to your product or app and just do it, right. And people only go to the documentation when they get stuck. So they're going through a process, they're trying to do something, and all of a sudden, they don't know what to do next, or something's not working the way they expected or something's broken. And then they have to go to the documentation to try to figure it out. So it's really important to keep in mind, like the customers mindset, when they're approaching your docs, they're probably already frustrated. They're probably already impatient. They're only here because they have to be not because they're here for fun. And so one of the things that we work with our customers on a lot is we do a lot of documentation rewrites. So what I think is really funny about some of our clients and some of our prospects that we've spoken to over the years is sometimes they're a little bit in love with their documentation. They think their documentation is awesome, right? They're like, oh, we've got it all documented. We've got it all written down. We've spent so much time on this so much effort, like it's all there in the docs. And then when you go look at the docs, it's kind of a love letter to the back end development process of an app or this software, right that some engineer and bless them worked so hard on and is so proud of. But what's in Congress about that is your customer doesn't care, your customer just wants to find an answer. And if they're going to this giant corpus of documentation, that's hard to navigate or difficult to find information or full of stuff they don't need to know, that only serves to undermine your brand and your customers experience, your customer is already not having a good time, probably when they're in your doc's, harder for them. They're not going to have more fun.
Richard Walker 5:49
That's such an important point that you bring up because, look, the corollary to having great software that doesn't need a guide, is to have excellent service. So when people need help, they can get the help, right. And oftentimes, my own team thinks about service in form of email, response phone, picking up the phone, even chat on Slack. But I also think about documentation as one of the response types. Because you want to be able to navigate and get to an answer quickly. And sometimes you can't do it, I want to tell you a funny story. Back in the 90s, when I was first became a technologist, I was tasked with learning Lotus Notes. I don't know if anybody remembers that. And I was given a project that seemed impossible. And I read the documentation. And Caity, I kid you not the documentation said, it can be done for these core functions. And the three different documents said the same thing. It can be done, nobody could explain how to do it, and like, terrible, terrible docs.
Caity Cronkhite 6:43
Indeed, it can't be done. But who's to say how?
Richard Walker 6:45
Yeah. So I'm really glad that you're thinking about it from the standpoint of you are improving customer experience with the documentation. So I'm then curious, who do you give it to to write, because you give it to the engineer, they don't want to do it. And then that's not their forte, give it to customer success people, they don't know the tech. And I suppose this is how your team comes in. So how do you blend these two perspectives into a great document?
Caity Cronkhite 7:14
Indeed, so there's a whole industry and discipline, technical writing, that sort of sits in this seat. So that's what I did in my career before I founded my company. And that's what my company does now is we are a company of technical writers who sit in this really unique spot and have this really unique skill set. So what makes technical writers a little different from your customer success people, or maybe marketing writers or other writers that you've worked with, or your engineers in this case, is that we have the experience in the technical development lifecycle software development lifecycle. Most of the time, great technical writers are actually embedded on engineering teams working right alongside with engineers, they understand the development lifecycle, they understand how software works, they understand the technology behind it, because they've been embedded in that world for their entire careers. And they bring this specific industry best practice knowledge about documentation and communication through the role as well. So they're also great writers, they're great technologists, and great writers. And in our seat, everything we do is through the lens of who is the customer? And what do they need to accomplish? What do they need to do to be successful and happy as possible? So that's kind of what we do. And it really depends on the product, it really depends on the customer, it really depends on what they need to be doing with your product or service. So check writers write API documentation, developer tutorials, sometimes UI text, error messages, user guides, end-user documentation, and pretty much everything in between. So that's kind of where we sit and how we're different and kind of a unique role on these teams.
Richard Walker 9:15
So that makes a lot of sense. And I want to bring this around to another perspective, because I think a lot of the people who listen to this podcast are in financial services, they may not be technologists. I mean, certainly all of our tech partners should be listening to this because I think a lot of them need help with their documentation. However, how does this then apply to non-technical writing? Because this is still about communicating, right? If you think about like internal processes or how you work with your customers, do you have some corollaries that you could share?
Caity Cronkhite 9:42
Absolutely. So a couple of notes there is, we tend to be focused on software and technology at my company. However, there's a whole sub-discipline of technical writing that is focused on the financial services industry. There are people who completely spend their career I was writing for FinTech, writing financial policies and doing things like that for big finance companies. So that is sort of a sub-discipline there. But some of the best practices that I think apply for anyone writing for any customer, are, as I said, what is your customer need to know, even if you are working in let's say, financial services or something like that, what questions do your customers ask over and over again? What are you constantly getting on the phone to explain? What do they get frustrated by in your process, maybe just using, you know, financial services as an example, maybe your customer, maybe all of your customers ask, what exactly does this investment vehicle mean? And how does it work? I don't understand. If you're constantly answering those questions, that's a customer service problem, right? At that point, you can basically view that as a support request, like if we were thinking about it analogously to like tech support or something like that. So essentially, your customers are picking up the phone and filing a support case, or like, I don't get this, and I need to understand it. So those are basic questions that I think anybody in any industry can ask, is just like, where is your customer getting stuck? And what is the most efficient way to get them the answers that they need to get unstuck? So another comment you made earlier reminded me of this, but what we like to say is that documentation is your frontline defense against customer problems. So, a lot of people that we talk to are like, well, if the customer has a question, they'll just pick up the phone. It's like, yeah, but where does that start to fall apart, you probably only so many hours in the day, when you can pick up the phone, when you're answering a customer call, or answering their questions over email or something like that, that's time that's taking away from the rest of your role. And whereas documentation or good writing, good communication is available 24/7. Your customers can go to that information, and get the answers they need without having to worry if they're going to be put to voicemail, or without having to worry if their emails gonna get lost, or without having to wait 24 hours for somebody to respond. Right?
Richard Walker 12:37
That's the worst the wait time for the response. And I feel bad when customers send me a message yesterday at three o'clock, and I don't get back to it till 10am today, for a question that was so basic, I'm like, we should have this documented better. It's impossible to think of every question that's going to come up, but I think you're representing if a company takes a mindset of documenting the questions that are coming in so that customers can do self-service, then you're incrementally building and growing your body of information, and therefore your ability to serve clients better, right?
Caity Cronkhite 13:08
Yeah. And I think that gets to another good point that I like to emphasize for people we talked to about this is, documentation and your written communication is a living and breathing thing. One of the problems we see, when prospects or customers come to us and they're talking about the problem of documentation, is they see it as this one-and-done thing. They're like, oh, we just need to dedicate a month to writing it all down, and then it'll be done. And then we never have to think about it again. And that would be great. That would be phenomenal. But that's not really how it works. Because product changes or services change, your UI changes, if you're working on an app or product, your services change. And every time there's a change, your documentation has to be able to reflect those changes. And also, on the flip side of that, as we were just discussing, you can update and change and manipulate and form your documentation to be useful to your customers as they go along their journey. You don't have to get it all right, or all written down the first time. You can document most of it. And then just start paying attention to the questions you get like, what are customers asking about? Where are they getting stuck? What don't they understand? And then you can start incorporating that information and making your documentation a little more useful for them and a little more usable?
Richard Walker 14:37
Yeah. All right. So let's switch gears a little bit. I would love for you to tell me a really favorite customer success stories, how Good Words and better documentation improve their business. Do you have any stories like that you can share?
Caity Cronkhite 14:50
Oh boy, I do. I have a recent one that I love to talk about. So we are working with a quantitative trading firm. This is a pretty large but private company on the East Coast. And our customer came to us. He was the leader of a team of about 60 quantitative traders. They call them quants. So this might also be relevant to some of your financial services folks might be an interesting story. But at this company, they had these 60 quants who are working with these internal proprietary tools, they've got a couple of API's they've developed, they've got some, internal products that they use to sift through these massive, massive amounts of data, so that they can try to make better trading decisions. And they've developed these products over several years. And the whole point of these products is that the more the quants use them, and understand them, and the better they are able to apply them, hopefully, the company makes more money, right? And so my customer came to me, and he was like, hey, we've got these internal tools that aren't documented. And I have a hunch that that's holding us back as a team. And I was like, yeah, you're probably right. And so we kind of dug into it, I was like, how are they being document now is they're being documented at all. And he told me a very familiar story that we hear from a lot of our customers, the engineers internally had developed these tools, the engineers were expected to document it, the engineers, one weren't good at documentation, two had no time for it. Three, it wasn't in their wheelhouse. And four, they absolutely hated it. So it was never documented, nobody was doing it. And even though they were supposed to, and no matter how much willpower, they tried to apply to the problem, it was never going to get documented, essentially. So I kind of helped talk them through the pros and cons of maybe bringing in a writer to actually document these products. And eventually, they decided to bring in somebody from our team to document a couple of these internal API's. And they were skeptical at first, they really did not want to bring in someone externally to do this work. Because they felt that they should do it internally, they felt that the engineer should be doing this themselves. And that it was ridiculous that they weren't. So we started with a really short project with them. I think we were in there for a few months, just kind of documenting some of the basic functionality. And over that time, they were like, yeah, it's nice that our engineers don't have to worry about this. So they wanted to keep going. They wanted to keep documenting their products until it was done. And the greatest thing happened after we had been working with them for about six months. One of the stakeholders who's a manager on this team called me up and he was like, Caity, we are seeing a monetary return on investment from just the documentation that we've written. So because of the documentation, the engineers were working more efficiently, they're onboarding new hires was more efficient, it was going more quickly, people had fewer questions for the senior people on the team, they were making better trading decisions and things like that. And so we actually modeled this out of how much was the documentation actually saving them per year by investing in it. And it came out to this crazy number, it was like $2 million a year that this one documentation project was saving the company, and then was going on to help them make more money because their revenue-generating employees were more effective and more efficient at their jobs. So that's like my favorite story ever. It was so great, and they're customer, we're still very excited to be kind of embedded there and working with them on these really interesting technical problems. But it made my heart sing when they told me like, we're quantifying it, we can see how this is changing things for us.
Richard Walker 19:19
That's truly amazing. And the image flashing in my head is you took a muddy road and turned it into a paved road. So nobody gets stuck in the mud. They're no longer slowed down and just the pathways, and they can do things more efficiently. That's worth so much more to them. That's amazing.
Caity Cronkhite 19:35
Well, and one of the things I think is interesting too, is initially they were like oh, we really don't want to like set this budget aside. It doesn't seem worth it to us. And that budget that they needed to actually document these products was a fraction of what they're saving year over year, and over five years. It was something like they were going to be saving and making up about $11 million. So it was wild, just to think about it in kind of those ROI terms like there is truly a return on investment of just writing stuff down and writing it down well in a way that people can actually use it.
Richard Walker 20:15
I think it's fascinating when so many companies will spend a fortune on process and procedure guides, but not the technical writing of their products or their internal decisions they've made. And I get it. I mean, I do I run a software company. I know how hard it is. But I've been a big fan of documentation my entire career. That's part of it. Part of it for me, though, because I was a software developer, only because I was a business person first part of it is writing down what I intend to build. So I'm clear about what I'm building two months later, or six months later. And if you build really good functional specifications, and technical specifications for the product you're trying to build, the technical writing becomes so much easier, because you have this body of information that is partially written for the API guide or the technical guide later.
Caity Cronkhite 21:03
It's true. Yeah, it's true. There is one caveat, I would say to that, and which is sometimes you have to be very diligent about what goes from your technical specs into your documentation. So a lot of what's in the tech specs is the decision-making behind the decision, how the back end is going to work and things like that. And so I was kind of talking about this a little bit earlier in our conversation, sometimes, we go into these environments where we basically see people who have taken the text back and made it their docs. And it's somewhat useful for the customer. But there's a lot of other information, again, this sort of like love letter to the back end, that we see. So you do have to be really diligent about kind of stripping out and distilling down like, this is what the customer is going to want. This is what the customer is going to need when they come here. And this is what they're not going to want or need. And basically, kind of taking ego out of it and being like, I'm going to remove that, because the customer doesn't need it.
Richard Walker 22:08
Yeah, and I also think it's important to consider what shouldn't show up in a final document, because an engineer may think it's important because it was important to their work. But we don't want to expose it to the customer. We don't want to show them trade secrets or security or other types of private information, intellectual property even. I think it's really, really fascinating. So let me ask you a different question. Because AI is all the rage, right? I mean, how fast people can write things with chat GPT, and other systems out there. Now, a lot of that's from marketing, I'm wondering how you're seeing AI impact your business and the experience that you're creating for customers?
Caity Cronkhite 22:47
Absolutely. This is such an interesting question. I've been doing a lot of research and a lot of talking about this lately. And I have some, it's a rapidly evolving space, obviously, chatGPT, and these large language models just appeared on the scene all of a sudden, and they have changed everything already. So it's interesting, though, because it's not impacting technical writing, and the documentation space in the same way that I think it's impacting marketing. And there are a couple of reasons for that. So, I think we probably all experienced, asking ChatGPT to like, write a thought leadership blog on x. And it can do a pretty good job of that, actually. And the reason that it can is because it is gathering all of this past research and information that's been out there that the large language model has been trained on, right. The challenge with documentation now, in my experience, is a couple of things. The first is that much of the information that we're writing about is proprietary. So it's actually not a good idea, we actively advise against our customers using chatGPT to write proprietary information, at least public versions of the product. We always recommend like, at the very least use chatGPG with a license use a pro-level of one of these products so that you're protected in the event of a breach. I don't know if you heard about that. The Samsung case where a bunch of product information leaked through chatGPT, about six months ahead of a major product overhaul hadn't seen that, wow, it was a mess. It was a whole mess. So you got to look that up. But so we advise against that. That's one of the challenges is that most of the stuff that we're writing about is proprietary information. And secondly, we're also writing about new things. So when you're a technical writer when you're working on in technology and innovation, as you have seen In your role to developing new products is you're writing about things that hopefully don't really exist yet, right? That you're solving a problem within the marketplace that hasn't been done before. And chatGPT and these large language models, right now at least, can only write about past about things where there is a past corpus of information to pull from. So it's not super effective currently at writing about new things. So there is that I do anticipate, however, that I think the most likely scenarios that I'm seeing right now about how it's going to impact technical writing and documentation going forward is I do think that AI is going to be incorporated into a lot of those authoring tools, I think it's going to make our writing process more efficient. I think it'll be great for things like, writing outlines, or maybe marking up content, for single sourcing or for tagging content, things like that. I do think it'll be pretty effective there and will make writers more efficient in that arena. But honestly, the most impactful use case I see for AI in docs right now is for companies who have existing corpuses of information. So documentation, user guides, maybe a knowledge base, maybe customer support tickets that they've responded to, to build a chatbot on top of that entire corpus, that can then run and be trained on your internal information to serve up better answers for our customers. So yeah.
Richard Walker 26:40
No, I'm glad you bring it up. Because I actually did want to ask about this, because that was one of the things I kept thinking about, if I want to improve documentation, really access to information, and the ability for a customer to find it couldn't I use a chatGPT or similar product against my documentation to get out that answer faster. So if that's true, and you're helping customers do it, how, how do you set it up for that to work?
Caity Cronkhite 27:05
Yeah, absolutely. So a couple things, just some kind of historical information and context is, for decades, the biggest problem with documentation has been searchability and find ability. So particularly large enterprise companies, which are some of our customers as well, they've been writing documentation for years and years and years, on dozens, even hundreds of products, and then their customer goes to their help site. And they have to find one topic that describes the exact problem or goal that they're trying to achieve. Right. And that is really, really hard. That's a hard problem to solve search functionality has been a real challenge here, particularly if you have documentation living in separate systems, right. And so the big opportunity that I see is, I think that these MLMs, and AI is hopefully going to solve that problem. I don't know yet. If there is a product that is kind of bespoke out of the box that you can just run on your corpus of information that will solve this problem for you now, but I anticipate that it's coming soon, if it's not in the works already. So right now, if you were to do this today, for example, as far as I know, what it would require is basically building a custom chatbot with like GPT four that would then pull in all of these inputs from your various documentation sources. So your Doc's that could be a knowledge base that could be your ticketing system, or what have you. But then, once you get that set up, your customer can just ask you a question like, hey, how do I do this thing? Or why am I seeing this error message? And then if you train the model, well, it should be able to surface better answers for you.
Richard Walker 29:07
Do you think a lot of your business going forward is going to be to help customers frame their documentation to be trained?
Caity Cronkhite 29:15
I think so. I think our business going forward is going to be helping customers to either build or implement these chatbots on their existing docks or, and or I don't think they're mutually exclusive, to get their documentation into a good place so that it can be used to train the model. That was the next thing I was going to say, which is, the model is trained on the information that you give it. If you feed it crappy information, or stuff that's out of date, or inaccurate or isn't well written, it's going to surface answers that are inaccurate, out of date, not well written, right? Because it not a brain, it's only reacting to what you train it on. Right. And so one of the things that I am emphasizing with people that I talked to right now is the underlying information you're going to train a model on has to be good for it to surface good answers to your customers. So a couple of things, I think, I anticipate this is sort of forward-looking and just kind of my own speculation, but I think that information that is structured well, that is potentially structured documentation as opposed to unstructured documentation. And what I mean by that is, there are documentation frameworks, where you can tag the information, kind of identify what sort of information that it is, you can do all sorts of cool stuff with that. But I do anticipate that that will actually be more important going forward in training these large language models. I think it'll make the training of those models better. And I think the models will kind of start to look for that information in order to surface the best answers to questions and things like that. So that's the big opportunity that I'm talking to people about now is think about how you're structuring your documentation and make sure that it's good. So that when the time comes for you to pull it into a large language model, and I think it's coming, I think almost everybody is going to be doing this in the next couple of years, if I had to predict could be wrong. But that's what I'm guessing. So when the time comes to actually do that, your content is going to be ready for it. And in the meantime, your customers are just going to get better documentation and better service. Because you've written better documentation in the meantime, before AI comes for us. Right?
Richard Walker 31:54
So I'm thinking back over time, because man, I started developing software in the 90s. And you might have had a help file from some product, but more likely went to a book. And then eventually it turned to PDF. And then it turned into wikis and forums and things like that. And now what you're really going after, could potentially just be a large language model that you get to ask questions. How do I do this? How do I do that? Show me this, give me an example of that, etc. So that you're not actually reading a traditional guide, you're asking questions and getting feedback that helps you navigate the process better. This is really fascinating. Caity, we're gonna have to wrap up here in a second. So I'm excited for your business, because you're not gonna be out of business by AI whatsoever. And in fact, I'm guessing that the companies that choose to work with you sooner than later to adapt to AI, and they deliver documentation about their products through AI-involved tools are going to be the leaders, they're going to have the strategic advantage, I'm guessing.
Caity Cronkhite 32:52
I think so. And I certainly hope that AI doesn't completely take our jobs anytime soon. I do think it's going to change how not just writers, not just technical writers, but how everybody kind of in these white-collar technology jobs work. I think we have to be ready for that. But I sort of liken it to, if I were living 600 years ago, right, and I were a scribe, and then all of a sudden, the printing press came along, like I could view that as, oh, man, there goes my job. Or I could view that as an opportunity to learn something new, and to make my work more efficient. And so I'm trying to lean towards the latter. And I think that there will certainly be a place for all of us, but I do think it's gonna look different.
Richard Walker 33:38
Oh, good for you. All right, so look, I have another question before we do wrap this up. But before I ask it, what is the best way for people to connect with you?
Caity Cronkhite 33:46
Absolutely. So you can check out Good Words at our website goodwordswriting.com. LinkedIn is a great place to connect with me love making new connections on LinkedIn. So I will provide the link to my profile there. Or anybody can reach out to me to at ccronkite@goodwordswriting.com. And I will provide that information further notes.
Richard Walker 34:08
All right, here's my last question. Who has had the biggest impact on your leadership style or how you approach your role today?
Caity Cronkhite 34:14
Let's see who has had the biggest impact. I think the person who's had the biggest impact on me, in my leadership style is my very first manager at the very first tech company that I worked out. So my first job out of college, I worked at Salesforce, and I was a technical writer there. And I remember, I was kind of a workaholic. I really loved to work. I worked all the time. And I had just moved to the Bay Area from the East Coast and I didn't know a lot of people but I was spending a lot of time working. And I remember my manager pulled me into his office one day and he was like, Caity, you're young, work isn't the only thing out there. Like he said to me, he was like, if I see you in this office for more than 40 hours a week, I'm gonna put you on a pick. He was like, get out there, go experience your life, live to work, no, the opposite work to live. And I remember being really mad at him at the time when he said that, but it has had the longest and most impact on me, as a professional and me now as a leader as well. So one of the things is really important for me, in my role and working with our team is, not obviously do great work, be really committed to our craft, but also be a joy to work with. Have a life, have fun, doing what you're doing, have positive impacts on our customers and the customers that they serve as well. But also to be able to create opportunities for my employees and the people who are in my network to thrive as well. Not just work.
Richard Walker 36:13
I love that. I love that. It's so easy to forget those first experiences for others when you're a leader, how you might be impacting something they're going to do 20 years down the road or something. So it's awesome to hear that I love these types of stories. Thank you. All right, I have to give a big thank you to Caity Cronkite, CEO of Good Words for being on this episode of The Customer Win. Go check out Caity's website goodwordswriting.com and don't forget to check out Quik! at quikforms.com where we make forms processing easy. I hope you've enjoyed this discussion will click the like button, share this with someone and subscribe to our channels for future episodes of The Customer Wins. Caity thank you so much for joining me today.
Caity Cronkhite 36:51
Thank you so much for having me Rich, this is a lot of fun.
Outro 36:56
Thanks for listening to The Customer Wins podcast. We'll see you again next time and be sure to click subscribe to get future episodes.
Comments