Hannah Kirk: Connecting Technical Writing and Content Strategy – Episode 70

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Google Podcasts | Stitcher | TuneIn | RSS

Hannah Kirk has great ideas about how technical writing and content strategy can support each other.

She’s not a typical tech writer. She loves and appreciates technical documentation and enjoys practicing it. But she has always been more interested in strategy. And she has always spent a lot of time thinking about how content is organized.

Hannah and I talked about:

• #BlackLivesMatter
• her background in enterprise technical writing
• her transition to identifying as a content strategist
• the history of technical writing
• the benefits of component-ized content, especially compared to old-fashioned documents and publications
• the shift in the role of tech writers form being publication formatters to folks more focused on writing
• topic-based authoring and DITA and Flare and Oxygen and similar tools
• how she’s not a “typical” technical writer
• the four times she has been the sole technical writer/content strategist in an organization
• a confusing juncture in her career when she went to Silicon Valley and found that they weren’t at the cutting edge of technical documentation 🙂
• tools for technical writers – from Microsoft Word, to Framemaker, XMetal, Oxygen, Markdown, DITA, DocBook, and more
• the benefits of Markdown in tech-savvy organizations like startups
• the importance for technical writers of having a few more technical skills than other content strategists
• how she engages engineers and other sometimes-hard-to-engage folks in conversation
• her message to the content strategy profession: Don’t overlook technical writers as an ally in your work, and likewise her desire to learn from content strategists

Hannah’s Bio

Hannah Kirk (a.k.a. “The Pink-haired Content Strategist”) is a content strategist in Silicon Valley, working primarily with B2B software products. Hannah started technical documentation departments and worked as a lone writer at four startups. She implemented processes, authoring tools, CMS’s, and publishing flows in FrameMaker, DITA, Docbook, and Markdown and integrated small documentation departments into larger companies as a result of three acquisitions. She’s now at Inkling bringing customer content into the Inkling platform and advising customers on best practices of migrating, organizing, and optimizing content. Hannah also started the Medium publication, Content Strategy Adventures.

Follow Hannah on social media

• HannahKirk215 on LinkedIn
• PinkHairedCS on Twitter
• PinkHairedCS on Medium

Video

Here’s the video version of our conversation:

Podcast Intro Transcript

Depending on how you look at it, the profession of technical writing may be the oldest branch of the field we now call content strategy. Technical documentation pre-dates the web by at least a couple of decades. And many of the practices now being adopted by content strategists have their origins in technical communications. Hannah Kirk has been writing technical documentation for more than 15 years. She has some great insights into how content strategy and technical communications can support each other.

Interview Transcript

Larry:
Hi, everyone. Welcome to Episode Number 70 of the Content Strategy Insights podcast. I’m really happy today to have with us, Hannah Kirk. We’ll talk a little bit more about Hannah’s background in just a couple of minutes, but I want to start this episode by just acknowledging that we are in a really fraught time right now. We’re recording this episode on June 3, 2020. We’re just a week or so out from the horrific murder of George Floyd and the ensuing protests and other activities around that. I just want to say, we’re not going to talk about that on this podcast, but I just want to acknowledge upfront that black lives matter. One of the things that Hannah and I were talking about before we went on the air is that how, I think, for people, the content strategy field is a field that’s uniquely positioned or uniquely populated with people who have the empathy and listening and the skills in a sense of camaraderie with their colleagues or whatever their background.

Larry:
Hannah, can you talk a little bit more about what we were talking about before we went on the air?

Hannah:
Sure. I was saying that I attended Confab about a week and a half ago. It was virtual Confab and I haven’t been before, but one of the things that struck me and that was stated more than once and I agree completely is that because the user is central to what we do, user empathy is really, really critical. We are a group of people – we, being content strategists – who are uniquely positioned to be very empathetic and concerned about different types of users and how things are impacted even if they aren’t our issues or our problems or whatever it is, but you’re just understanding their problems. Understanding people different from us is an incredibly big part of what we do. If not, *the* main thing we do and how we also communicate to those people and communicate about people is a huge piece of what we do as well.

Larry:
Great. Yeah. Well, that’s just what content is about. I’ve been in person the last two years. I didn’t attend this year because I’m saving my money up for Button, the new conference in the fall. The other thing we were talking about before we went on the air is, what were you doing at Confab? You’re a tech writer. Stay in your lane lady, but I think you exemplify a trend that we’re seeing in the content strategy field right now that everybody comes to this field from a different direction. You come out of technical writing and you go back to the old days, I don’t know, like 10 or 15 years ago when tech writing was a very different practice than it is now. Can you talk a little bit about your background and your journey from identifying from being a technical writer to your current identification as a content strategist?

Hannah:
Sure. I attended Confab because I started to realize that content strategy is really what I’ve been doing for a very long time. How that began was, I came out of grad school, Muncie, Indiana. There was one tech company. They hired me to be a technical writer because I had technical aptitude and writing skills, which in Muncie, Indiana, there aren’t a lot of technical writers. Everybody has to be trained from the beginning. This was also, at least, 15 years ago when enterprise software, specifically, was more, “We’re just going to make it, and then later, we’ll have technical writers tell you how to use it using manuals.” That has been an interesting shift. Yeah. I found content strategy a few years later after I’ve been doing that for a while.

Larry:
No, that’s interesting because I come out of book publishing and old-fashioned communication stuff. I think one of the most profound fundamental shift, I think, in all of communication and content over the last 10 or 15 years, about the time that you’ve been doing this is that shift from like “Hey, we’re just going to announce and publish.” In the case of technical writing, “Here’s your feature set. Now go explain these features to some users.” We’ve gone from that to a much more empathetic listening, researched, human-centered, customer focused, user research process of getting at things. Was that a smooth line of transition for you or has this been a choppy transition to your current practice of the profession?

Hannah:
Such a good question. When I started technical writing, I remember being excruciatingly bored at times by the research and the writing and the precision of the writing. I remember, also, being really frustrated with engineers who, in some cases, and this is why I think content strategy and technical writing dovetail pretty well is, yeah, at that time, the only people who saw the whole user experience from beginning to end of any product was the technical writers. Maybe the trainers but even the trainers were downstream, a step removed. We saw, we being the technical writers, saw, “Hey, group of people, engineers doing this over here. Did you know that group of people over here is doing the same thing?” This is before product was developed and before sprint and agile were big things.

Hannah:
At that time, there weren’t UX designers that wasn’t really much of a conversation, at least not where I was. Certainly, that happened in consumer software before it happened in enterprise software. Enterprise software, I still see lags in the user experience, but yeah, I mean, it was a very frustrating whenever I’d be like “You guys, the same error message is the same as this one over here. If you just wrote it the same, you could reuse it. It’d be so easy.” It was quite the frustration at times. Imagine my excitement when UX was a thing. It was so exciting.

Larry:
That’s right. Well, that’s interesting because you were in an enterprise, that place in Muncie. What kind of a company was that? Was it a software company or like a manufacturing thing? Or what kind of work were you doing there?

Hannah:
It was a software company. They did debt collection, enterprise software. A company called, Ontario Systems. It was, actually, very advanced in their technical writing processes. I have to say, they had XML, DITA. It was not DITA yet, because it was before DITA, but it was the precursor to DITA of DocBook, using XML and pretty sophisticated tools. Even by today’s standards, they’d be pretty sophisticated, 15 years later.

Larry:
Yeah. That’s interesting. The toolkit that tech writers and technical communicators have traditionally used that you’ve been doing things like that. There’s a lot of talk, nowadays, about structured content and content repurposing and things like that. All of this is old news to you as a technical writer, right? If you’re using XML and DITA to write the documentation, the intent of that was to do what you were just saying. Wait, we’re saying the same thing in multiple places. Why don’t we just use the same little chunk of content to do that? Well, I guess you said you’ve had a product role, subsequently. Have you got into product content, like more UI elements and things like that? Is that part of your scope, of your work now or …

Hannah:
Well, actually, before we talk about that, I’d like to go back just a little bit and talk about the history of technical writing.

Larry:
Sure.

Hannah:
Clearly, it started with, like you were saying, enterprise software. “Hey, we built this thing. We need people to use it. They don’t know how to use it. I’d like ask somebody to write about it in a way that you can understand reading a manual.” Of course, that eventually evolves into how do we make the actual product itself much more usable. I’m so grateful that the conversation today and a big thing today, and actually, that’s where content strategist roles tend to land frequently right now. Yeah, part of my job as a technical writer has always been to pay attention to what the user wants, what the user needs, what they want to do, try to identify those tasks and then write as clearly and succinctly as humanly possible, what exactly they need to do.

Hannah:
Even more so with modular content, there was a push. Once manual stopped being so exciting, people were searching more. We went into web content, which was still sometimes used. It’s called, HTML Help Chm Files, if you’re really hardcore. That has also moved into a web help and webpage space, but let me see. The whole general goal, of course, is to help user use hardware and software, but the other piece of this modularization that’s really important is to understand in a book format. One of the things that’s really irritating to me about a book format is that there’s an overview and then there’s content, and then there’s, maybe, another overview about what you’re going to learn and then a summary of what you’ve already learned and then another transition. Before you even get to the main content in a traditional book environment, you’re six pages in or maybe 20 pages in depending and it’s wildly awful for a user experience.

Hannah:
Our move from user experience from a documentation point of view was going from manual into more of a webpage view with just the one piece of information you actually need, like a procedure, for example. The way that you write a procedure is such that you’re never referencing above or below or before or next. You’re not using any fluff at all. You’re trying to just give them all of the information in a contained piece. That way, you can reuse it in multiple other places, but that’s a skill in it of itself learning to write in that very dry business-like way that isn’t fluffy and also is reusable. That is, definitely, a big thing in technical writing and has actually made a lot of strides.

Hannah:
Also, another piece of that, too, is, there’s a theory that the writer should focus on writing, not formatting. Part of a job of technical writers, for a long time, was also just to format books or to format the way it looks on the website and make it pretty or take an engineering document and then make it look nice, sound better. I’m using air quotes for these because it’s not really what we do in my opinion, but that’s the misconception that we get a lot.

Larry:
No, it’s written. I think in terms of what we would now call, I think, content design, that’s something or maybe content architecture. Our terms are still in precise, but all that stuff you’re talking about going from that crafting an end artifact like a book or a manual to addressing the user’s need to accomplish a task. That’s another thing that we’ve gone from, I think, in reference and technical and publishing to the current day. I hope it’s been gratifying to see that shift. It sounds like, as a technical writer, you have some tools and methodologies to help other people. I’m thinking, for example, right now, of Sarah Richards and her conception of content design and how that works in creating web content. Does that stitching together make sense? I think that came out of a clear need for a new way to write government content for websites. Was there a similar clear need emerging to redo technical content?

Hannah:
Well, definitely. That’s how DITA has become so big. DITA stands for Darwin Information Typing Architecture. It’s, basically, an XML format that is open-source. I don’t recommend anyone, usually, directly out of a box unless they have either a team to help transform it or they personally are very, very good at it because it will take time to do that. There’s a reason why people hire experts. That being said though, the philosophy behind it, it can be applied to all kinds of topic based author. You can use it with other tools. I know we’ve talked about Flare a little bit or at least that’s a big one that’s come from, I think, people at Adobe. Some people left and created Flare, I believe. Oxygen is a big one. All of these provide different ways to write content structured, but the philosophy is essentially task-based content. You start with a task.

Hannah:
When an engineer or product manager is reviewing like this is what we’re going to do in this feature, but the thing you should be thinking about is, what would the user do. The user does this, this, this. That becomes the framework to start your content. After you write procedure, procedure, procedure, the next question is, what does the user need to know to understand this procedure. Again, there’s maybe some concepts in there that they don’t know or they don’t understand. There might be some nuances that are specific to that, but you don’t necessarily cover that in that task. It’s more supporting information that’s available near it but not necessarily itself. That’s the difference.

Larry:
Right. I-

Hannah:
I’ve also seen … Go ahead. Sorry.

Larry:
No, go ahead. No, no. I was just going to say that, it’s really interesting to me that that focus on tasks that seems to be … I think of, for example, Gerry McGovern’s work. I don’t know if you know him, but he does this “top task management.” It’s a very specific methodology for identifying the top task that users want to accomplish like big websites, but I think, also, this goes back to the UX connection that there’s more of a concern with addressing the user needs like “What is it you want to do right now? What’s the task you want to accomplish and how can we help you do that?” Rather than like “Oh, here’s how this feature works. Here’s this marketing message I have or here’s this product information I have.” I guess the thing that I keep taking home over and over again from conversations with technical writers is that the rest of content strategy can learn a lot from you about how to do that task accomplishment.

Larry:
You were talking about DITA and XML and the technical infrastructure to do that. Are there methodological things like the way you approach writing and researching that kind of content?

Hannah:
You mean, technical content in general?

Larry:
Yeah. Or just like when you sit down to write something. I’m wondering if this is one of those things where you’re like a fish swimming in water and I’m asking you to explain the water to me. It seems like you’re just really adept at really clearly identifying the specific task that somebody wants to do and just helping them do that and getting out of the way. Like you were talking about, like when you assemble a manual or a book, there’s all the fluff, the transitions and the introductions and things like that, that just getting to the facts and getting to the thing that … I guess, did that require a transition in your thinking over the years or is just that how technical writers have always done it?

Hannah:
Well, it’s interesting. I think that it’s become clear to me over the years that I don’t represent a typical technical writer because what I like much more than writing content and one of the reasons why I was so bored in my original beginning of this in the enterprise software is that what I really like is more of the strategy and thinking behind how you organize content rather than the writing of it itself. Now, that’s still cool. It’s fun. I like it. There’s certainly a desperate need for it. We absolutely need technical writers, 100%. And also, my specific interest was definitely more in the information architecture piece.

Hannah:
Actually, my journey out of technical writing into content strategy happened when I realized over time, I kept gravitating towards a sole, lone writer roles, which is where you’re the only writer in the organization. I have had four jobs as the sole or first writer in an organization, technical writer specifically, starting departments or processes and winning tools and all of that. Definitely, the pieces that I would say in technical writing, especially in a startup type role or the first technical writing role, maybe 90 to 95% of your job is that organization of content, the tools management, the process management, the education of people around you. These are some of the things I hear other content strategists talking about as well.

Hannah:
When you’re the first content strategist and the first technical writer, you’re typically having to tell people, “What the heck is it that you do? Why is it important? Why do they need to talk to you? Why do they need to add you to these meetings?” It’s when they didn’t invite you to the meeting, continuing to educate them why you need to attend and all of that. Yeah, I think it’s a very typical problem, but anyway, I’ll have to say that going from technical writing into content strategy with … What was the original question again? I lost it, actually. I don’t know how to start it.

Larry:
Actually, you’re inspiring a bunch of other questions, but it was more about that. How technical writers work and especially how they inter … but to what you were just saying, you’ve always thought more like a content strategist than a technical writer. I think that’s a really common thread among almost every guest I’ve ever had, is that you’re doing the same stuff and serving the same business intent and you’re doing your job, but all of a sudden, you’re calling it something different and having a little light bulbs go off as you hear about how other people do it and identify what they do. That sounds like your experience, right?

Hannah:
Yeah. I remember gravitating towards DITA before. It was released by IBM. I believe it was invented in 2005 and then released a couple years later or maybe it was released in 2005. Anyway, I remember seeing a conversation about DITA while I was still working at my very first technical writing gig and saying, “Oh, we actually do that already and using this DocBook thing.” I started to research it more, but my next job was going into a book publishing, which was a manual publishing which I was confused by because I … I actually had gone to Silicon Valley and I was confused how Silicon Valley wasn’t on the cutting edge of the XML-DITA situation and then we’re still using FrameMaker book publishing. I was confused.

Hannah:
They switched into DITA and I had had that experience of seeing such a perfectly wonderful system done by somebody else much before me and then was moving into this book publishing when they started converting to DITA. I was like “No, no, that’s not going to work. That’s not going to work. That’s not going to work. That’s not going to work. You guys need to do it like this, this, this.” They didn’t listen to me. They had all the same problems that I said. Later, when they converted over, because the larger parent company do it in acquisition made them, it made a lot more sense, I think, to many of them. Of course, I, from then on, became a really sold, DITA hardcore person, but what I didn’t realize at the time is that DITA was just one expression of how to create and present content or recon and present that in multiple ways. That’s, really, what I liked, as you said.

Larry:
Yeah, I love that.

Hannah:
I learned that later when I started.

Larry:
No, I just love that the kid from Muncie, Indiana comes to Silicon Valley and shows them how to use leading-edge technology. That’s a great story. That gets into the tools that you use. You’ve talked a fair amount about DITA and you’ve mentioned a couple of others like Oxygen. I’ve heard of XMetaL and things like that. How set is are those tools … Are there a top three or four sets of tools that most technical writers would use or is there a pretty good variety of tools for helping people do their jobs?

Hannah:
There are tons of tools you can use. You could, theoretically, use Microsoft word to do a lot of stuff. I wouldn’t recommend it, but a lot of companies probably still do. FrameMaker is another big one. I think FrameMaker is really good for book publishing. I haven’t used it in the last, maybe, five-ish years to know how it’s doing with responding to modular content, but from my experience previous to that, it wasn’t quite its main use case. I’ve also used XMetaL, which is great. That’s better for people who are a little less technical in their ability to understand how to write code. Oxygen is my personal favorite because it is extensible, flexible. It allows you to be inside of a coding type environment.

Hannah:
Another new-ish trend is markdown content. Markdown is different from XMetaL content like DITA or even a DocBook, DTD that’s customized because DITA and DocBook offer you tagging of semantic content. That is when you have a title, it’s identified as a title, like an H2 and Markdown and then you have, maybe, a sub, subtitle or short description. That’s what it is called in DITA or small explanation of content that can exist. You can’t really enforce that in Markdown, but you definitely can enforce that in DITA. I think also, too, the thing with DITA is that the tools are pretty removed from the structure itself. They’re only really a way to author inside the structure. You can use, really, any code editor for DITA.

Larry:
Got it. Yeah. what you were just talking about is, it reminds me of … You said something. I think you’ve mentioned a few times that you’ve done a lot of work with startups. I know that in that world, I run in that world a fair amount and that a tool like Markdown, they love like sleek slimmed down. . . It’s the opposite of DITA in some ways, it sounds like and DITA is super structured and like you were saying, you need like a team to help you manage a DITA system. Whereas, with Markdown, you can just throw a bunch of stuff in GitHub. You’ve got the version control that the coders are familiar with and all that stuff, but you’re limited. Like you were just saying, how do people handle metadata with Markdown files, for example?

Hannah:
Well, you can implement Markdown in a way that uses a lot of metadata, but you aren’t going to get rich semantic tagging inside of a document itself or I guess document being one code module. You’re not going to get that itself without real intentional work. I did see at LavaCon last year, a demo done by the . . . grid of Markdown. I think it’s called, DITA to Markdown or Markdown to DITA, something very self-explanatory. I can’t remember off the top of my head, but it was a really cool hybrid. Startups love Markdown. I kind of love it too, for this reason because it’s extremely quick to implement. It’s extremely fast to get it going. Almost any developer, not a specialty DTD, XML, DITA author, guy, person, but an actual, just any old developer who’s done HTML or web content can convert that into a really nice website, pretty easily.

Hannah:
My last organization that I was working for, we did something where we converted or we had our content converted into Markdown, which was also an easy conversion from many other content forms. It’s another reason it’s attractive is because it’s very quick to convert that versus converting into DITA can take time because you have to understand semantic tagging and all migrations have their challenges, but this, specifically, was very simple. I could author in a free tool, Visual Studio Code. I could save it, like you said, in GitHub, which also is free. I could produce it using either an internal person or potentially some service to just create this lovely output. Of course, Markdown being super extensible and you could theoretically use that as the foundation for your chatbot or the foundation for your error messages or you could potentially write error messages in Markdown. Also, engineers, developers, fans, whomever is reading your content can also potentially contribute without much actual extra effort. You can duplicate your GitHub repo, make it accessible to the public. Other people can correct your content, push it in. You can create a pull request. It’s great.

Hannah:
I highly recommend Markdown, but you do lose some things. It’s more about how you write and structure your content at that point, which again goes back to content strategy.

Larry:
Exactly. I just wanted to circle back to that too, because as we’re talking, I’m like “Oh my God, we’re getting deep in the weeds talking about tools and technology and stuff.” Whereas, let me run this by you. Many of my guests have observed that their content strategy practice is about 90% people and about maybe 7% processes and 3% technology. Does that ratio hold in the tech content world?

Hannah:
I’d say that, no. I think we’re about … Let’s see. If you are the only technical writer, you’ll spend probably 30 to 50% of your time on tools or structure of content. You’ll spend maybe 30% of your time talking to people. It’s not a precise measurement.

Hannah:
Yeah. I think, also, the other piece though is that you really have to have a pretty deep technical aptitude and knowledge. It’s the one of the few differences I see between technical writers and content strategists is, the technical writers do have to know and be pretty familiar with technical tools, technical concepts, code, even great if you can code, great if you can, at least, read code. You really do have to be able to see engineers language, which, again, this goes to the user empathy, right? We have in common between technical writing and content strategy, user empathy, but also, there’s an added thing in technical writing that I don’t see as often in content strategy and especially in the UX design version or the marketing version of content strategy, which is where you have to learn to understand and talk to engineers really, really well.

Hannah:
In technical writing interviews, I got the question, “How do you deal with hard to work with people or difficult people who won’t talk to you?” It’s a traditional technical writer struggle, probably anyone in the content industry and tech, but it’s pretty interesting. One of my personal favorite challenges is, how do I get a person who doesn’t want to talk to me to talk to me? How do I sit down with them and get the information that I need? That’s probably one of my favorite things about technical writing, in particular, that differs from content strategy where you really get to talk to the engineers. I know that a lot of content strategists don’t get that luxury. That’s probably one of the more inroads that we have.

Hannah:
Another one, maybe, would be like understanding the engineering processes like Agile and Scrum and where you fit in and all of that. It’s very important to understand that as a technical writer because when a sprint ends, your content should be done. Also, you are somewhat downstream versus in the UX content strategy portion. You’re inside the product earlier on, which interestingly, it creates a lot of confusion for startups. When you tell them, “Actually, I need to be involved early to cope with you with your UX content.” Also, later when you’re writing your documentation, but if we do it right in the beginning with the product, we won’t even need documentation or even that much documentation at the end. Let’s get it right in the product itself so that we don’t have to have maximum amount of content at the end. We want users to self service versus having to go hunt.

Larry:
Yeah. That’s another one of those themes that comes up all the time. It’s like “God, if I just could have been there earlier, we could have saved you so much time, effort, money, expense, and yeah, had happier users.

Hannah:
Yeah.

Larry:
Hannah, this always goes so quickly. We’re coming up on time, but I want to make sure, I always like to give my guests an opportunity at the end, is there anything last, anything that we haven’t talked about that’s just on your mind about technical writing or content strategy or the tech world, in general, that you’d like to share with the folks?

Hannah:
I think I would like to send a message to the content strategy discipline that don’t overlook technical writers as ally. We are all content professionals. We all need each other. We can all benefit from each other where a technical writer might know engineering processes. They’re going to have a perspective that you could potentially really use and they could be your ally in getting you involved earlier in UX product content if that’s your role. Also, while we may be less focused on Fluff, we want to learn from you on how to write more friendly content because we are very much trained to write dryly. That is one of the things that I’ve had to transition my mind a little bit is that when you’re in marketing content strategy, there’s a lot of “fluff of oh, please and thank you and nice words.” That’s all considered extra whenever you’re a technical writer.

Hannah:
Keeping in mind how telling us how tone can change and impact a user is fantastically valuable information because as time goes on, I see these fields really converging more and more and more. I see technical writers needing to know more about UX product content strategy and understanding how to write a little bit more friendly in different tones. And I see that as a very important role, the UX product content strategy as an important role in avoiding additional documentation. We can learn from each other and help each other a lot and I very much dislike when people pigeonhole technical writers because they are really important. Just like you, you being the content strategy, people, we all have to care about the user and user empathy. We have deep user empathy. It’s the same goals, really. Enable the user.

Larry:
Yeah. No, I love that. I think, to that, just to what everything you just said, I think if you just think from that perspective of the user journey, a lot of like that, you need a different tone at different points in the journey but the voice should be the same. The technical tone is, maybe, a little more dry, but I think that also would fall in that, like what Sarah Richards would call, you’re not dumbing down. You’re accessing up or something like that.

Hannah:
Yes.

Larry:
Yeah. Hannah, how can folks get ahold of you if folks want to follow you? I know you write on Medium sometimes. Tell me how you’d like to connect with people if they want to stay in touch.

Hannah:
Sure. Well, anyone’s welcome to reach out to me on LinkedIn. I’m HannahKirk215. I’m also on Twitter as the @PinkHairedCS, also known as Pink Haired Content Strategist. Although, I didn’t want to write all that out of my Twitter handle, so here we are. I also have a publication on medium called, Content Strategy Adventures. I’m under the same handle as Twitter, PinkHairedCS on medium as well.

Larry:
Great. I’ll include links to all those in the show notes. Well, thanks so much, Hanna. I really enjoyed the conversation.

Hannah:
Thank you. It’s an honor to be here.