Subscribe
Share
Share
Embed
Looking to scale an SEO channel and generate more traffic to your website? You are in the right place with the Optimize weekly podcast. Hosted by Nate Matherson, a content marketing and SEO leader, we go in-depth and tactical with an amazing selection of guests ranging from in-house SEO teams, agency folks, and solo practitioners who are crushing in their respective niches. Whether you are building an organic search channel for the first time or a seasoned pro, the Optimize podcast helps you keep up in the ever-changing SEO space. Our episodes are released each week on Wednesdays. For more information visit us at www.positional.com
Karl Hughes (Speaking)
00:00
They'll sign that out to their engineering team and they get probably one article a month back because their engineers, A, they're busy, B, they're not professional writers, and C, they gave them just a keyword and like a loose idea of what they wanted because they didn't really understand the topic in depth anyway or what the search intent really was for that keyword. So there's a lot of steps there. And this is where, again, most people think I can just toss an idea to an engineer, they'll give me something that's ready to publish, but that is very far from how everybody who does this professionally at scale does it. And so you need to be aware that there's a lot of pieces that go into this if you're going to do it right.
Nate Matherson (Speaking)
Hi and welcome to the Optimize Podcast. My name is Nate Matherson and I'm your host. On this weekly podcast, we sit down with some of the smartest minds in content marketing and SEO. Our goal is to give you perspective and insights on what's moving the needle in organic search. Today I'm thrilled to sit down with Carl Hughes. Carl is the founder of Draft.dev, a content creation agency focused on creating fantastic content for companies in highly technical areas like developer tools and software. Carl and his team have worked with a number of incredible startups like Snick, Earthly, and Contain IQ, my previous company, where we worked with him to create over 100 technical blog posts on our website. I always tell our customers to create fantastic content, but what does it mean to create fantastic content? In our episode today, I'm excited to learn more about Carl's approach to creating engaging and helpful content at scale, including his processes like content outlines, the editing process, and the cost of creating content in 2023.
Ad Spot
01:32
This episode of the Optimize podcast is brought to you by Positional. At Positional, we're building tools for content marketing and SEO teams. We've got a great selection of tools for everything from content optimization to keyword research and technical SEO, and you can visit our website at positional.com.
Nate Matherson (Speaking)
Carl, thank you so much for coming on the podcast.
Karl Hughes (Speaking)
Yeah, it's always good to see you, Nate. I'm really glad we could do this.
Nate Matherson (Speaking)
02:04
Yeah, and you and I have worked together. I've been a customer of yours for a few years now.
Karl Hughes (Speaking)
And we're a customer of yours now. Yeah.
Nate Matherson (Speaking)
02:11
Yeah, and it's been great working with you. I think out of all the content agencies I've worked with over the years, I think working with Draft has just been a total pleasure and one of the best. So I'm excited to dig into everything content creation and how we should be creating content on this episode. So Carl, the first question I always like to ask our guests is how did you get into content marketing and SEO and how did that ultimately lead you to starting Draft.dev?
Karl Hughes (Speaking)
02:36
Yeah, so I have a pretty non-traditional path into this field. I studied, I'll take it all the way back, I studied mechanical engineering in college, but I always liked writing. And so this was kind of where I started to learn about online marketing. Because towards the end of college, I realized I didn't want to do mechanical engineering. I wanted to do software engineering. Facebook had like gone public around that time. And it was kind of an exciting time to be like looking at web and what the, you know, social networks and what the future is going to look like for news and the internet and all that. So I got really jazzed about that. I got into software engineering, kind of started as a hobby and taught myself enough to be dangerous. And so in the meantime, while I was doing all this and learning to be a software developer, I was also really interested in writing. I actually spun up a group blog at my college and got like 30 of my friends and classmates to contribute to it. And we had a few viral hits here and there. And so I started to learn about SEO and content marketing, what all that means in addition to news and virality and all that stuff. So anyway, it just kind of happened out of curiosity and me playing around with things. And then for about 10 or 12 years of my career, I spent, you know, the kind of bulk of my early career, I was in software development, actually as a software engineer, engineering manager and then CTO at a small startup. And so I really got deep into the tech weeds and kind of got a little bit out of the content game. I wasn't keeping up with it religiously, like many of your guests and you were at that point. But then what happened was during the pandemic, the last startup I was working for started to shut down and I was like, the writing was on the wall and I was looking for something to do and something to maybe like supplement my income as we were sort of winding it down. So I started to go around to other tech blogs and talk about like freelance writing. And would you be interested in having me write some things? So I had a big, a deep bench of like things I'd written on my personal blog, things I'd written here and there for like DigitalOcean and Okta and some places like that, that were, I just had connections at. So anyway, I kind of like shopped that around and pretty quickly I had a ton of clients like ready to pay me to write anything. You know, like I just realized there's this huge demand in content marketing for technical content, like deeply technical content, like how to spin up a Kubernetes cluster, how to solve certain like technical bugs and all this. And it was all new to me. I didn't realize this was such a, like a highly demanded service. And so that kind of got me into realizing maybe there's something here, I'll start a business around it. So it started off with just me freelancing and then pretty quickly I had to hire on more writers and editors and a whole team. And so Draft.dev grew really quickly, you know, around the time we started working together, Nate, this was probably two years ago, we were just four or five people. And then last year at peak, we had at least 12 full-time and then several more contract and then 350 writers. And so it's been a little down this year, tech being a little slower than it was last year, but still it's been a really awesome business to run and just see it grow that quickly. So anyway, I've learned a lot just as I go. And honestly, resources like this show and just talking with you and working with you, Nate, was helpful at some points too, but then also we've worked with over a hundred clients now. And so we get to see the results of our work with them. And that's taught me a ton about what works and what doesn't in this kind of technical SEO work.
Nate Matherson (Speaking)
We first started working with Draft because we wanted to create highly technical content in the Kubernetes space. If you remember, we built ContainIQ. That was the company I started before Positional in the Kubernetes observability space. And I saw a clear opportunity for us to build out a portfolio of content in the K8 space. And it didn't look all that competitive and like the SEO in me, like knew how to do keyword research and figure out what to write about. But being non-technical as a non-engineer with like fairly limited knowledge and Kubernetes itself, I couldn't have my co-founder, Matt, fact-checking all of the content we were creating and making sure that it was accurate from a technical standpoint. And so I knew that we had to hire an agency if we wanted to get to the scale that I wanted to get to. And at ContainerQ, we published something like 220 posts over about 14 months. We grew our Kubernetes blog to about 200,000 readers per month. And Draft definitely played a big role in that in terms of helping me scale. And so my first question to you, because I always tell our customers, like the first most important thing is to pick the right keywords or right topics. And then the next most important thing is to create great content. And so I wanna ask you an intentionally broad question. To you, what does it mean to create fantastic content?
Karl Hughes (Speaking)
07:08
Yeah, yeah, it's a good question because I think it has changed over the years. Even in my casually keeping up with SEO, there was a time when you could just kind of stuff keywords into a like mumbo jumbo article and like rank in the top 10. Like that did work at one point. It was a long time ago, but like it did work. And it's totally different today. I mean, the tools are all way more sophisticated that Google has, but then also the public facing tool. So anyway, the point being that now today, I would call fantastic content, content that genuinely helps the reader either solve a problem or inform them about an issue. In the technical world, what that means is it's nearly impossible to have a freelance general purpose writer write you a really fantastic piece of technical content. Even something as simple as like, what is Kubernetes networking? It's a high-level term. You would think maybe a freelance writer could write this, and maybe a few could do a fairly good shot at it, but they wouldn't have any personal experience to layer in there. They wouldn't have any idea of current best practices from experience or from the real world or how it actually works in practice because it's all just theoretical knowledge of kind of going out and reading a few articles and then regurgitating it. And I think the search engines are all better now at understanding that that's not fantastic. That's just reformed content and it sort of doesn't stand out. So that's one thing where, to me, with Draft.dev, that's our whole goal is like stay a cut above the stuff that you could do with a non-technical freelancer or AI generated content or something like that, and always be going a level deeper, more personal, more interesting than we would outside of our scope.
Nate Matherson (Speaking)
And walk me through the content creation process. It could be internally to draft or if I was going and building a freelance team and owning this process internally, can you walk me through how we create a piece of content?
Karl Hughes (Speaking)
09:01
Yeah. First, I'll tell you how most people start off doing it and it's just wrong. You mentioned keywords. Let's skip that part. Let's assume you did good keyword research and then we'll come into writing the content. A lot of dev marketing or dev rel teams that get tasked with going and creating a huge backlog of content. Let's say you want to publish once a week even, which is not that frequent in terms of like scaling up, but at least it's a starting point. They'll often go to their engineering team and sign out these blog posts and just say, hey, I want a topic that covers X keyword. It needs to be at least 1500 words. Could you write me something? They'll sign that out to their engineering team and they get probably one article a month back because their engineers, A, they're busy, B, they're not professional writers, and C, they gave them just a keyword and a loose idea of what they wanted because they didn't really understand the topic in depth anyway or what the search intent really was for that keyword. So the right way to do it, and this is the way that we do it at draft.dev, but I'm not making this up whole cloth. This is the way all of our competitors do it. This is the way DigitalOcean does it. This is the way all the big tech companies that produce content do this. First is beyond the keyword research, let's go create really detailed outlines and briefs that are covering what we want, not just from a high-level SEO perspective, but from a technical perspective. What are we trying to offer to other engineers? That's really valuable here. So that's the first step. The next step is finding a writer who is qualified to do this sort of work. And so it's gotta be someone with some real world experience in that field, or at least, you know, works very closely to it and can research enough of it. For example, let's say, you know, you've got somebody who knows react, but maybe they haven't used Redux. Could they write an entry-level article in Redux? Absolutely, they could go research it because they know React, they know the fundamentals behind Redux, and that needs to be true for this writer. Now, ideally, you get somebody who's, especially if you're going to write some senior level content, you really get a writer who knows the depth of it. They use that outline that we give them as a starting point, but they're really just going to take that as a framework for how to get started and what gaps they need to fill in the reader's knowledge and then go deeper into their own personal experience. They need to add a lot to it. And then the next part is, these are not professional writers, these are professional engineers, and so they're not going to bring you professionally written work that looks like it's ready to publish in most cases. I mean, there's a few, there's exceptions occasionally where you'll get an engineer who's a great writer and that's great, lean into it if you can get it, but it's rare. So typically what you need to do is have some sort of editorial process where you not only check like did they cover what we wanted them to cover from the outline from SEO perspective, from a non-technical business perspective, but also you need some quality control around the technical side. Like technically did what they write, does it match up with what other engineers might say? Did they make any assumptions that other engineers might say is wrong? So we do both a developmental edit and engineering edit essentially where technical review is done so we actually run the code to make sure all of it works and all that before we get back. We also do a copy edit, which is like a little bit more of a stylistic and spelling and grammar check at the end. And that, that helps with, again, a lot of our writers, not native English speakers, um, or they maybe just aren't great at writing in general and because it's not something they do every day. So we want to make sure they, they look and sound as polished and professional as possible. So there's a lot of steps there. And this is where, again, most people think I can just toss an idea to an engineer, they'll give me something that's ready to publish. But that is very far from how everybody who does this professionally at scale does it. And so you need to be aware that there's a lot of pieces that go into this if you're going to do it right.
Nate Matherson (Speaking)
And how long does it take to like go through this process? Like from like ideation to outlining to editing, to writing, and then to editing, and then to having like that final piece that could be ready to publish on my website? Like, how long does all of that take?
Karl Hughes (Speaking)
12:29
Yeah, in our world is typically four to 12 weeks, depending on how much back and forth there is with clients on different things. We have a few different checks throughout the process where we're getting feedback from a client, right? We create this outline in brief, we wanna make sure the client and their client's tech side sees it first so that they know what they're getting at the end of the day. We're going to give the writer a couple of weeks to write at least because these are typically people with a day job that are writing on the side. They're engineers. We want practicing engineers who actually have time in the field. So it takes a lot longer than a typical, you know, typical like throw something over to a freelance writer, they get it back to you. You know, it's totally different than writing about like picking the best bar of soap in 2023 where, you know, somebody can kind of make that up or do some really high level quick research. And it doesn't, there's not a lot there that you have to know about soap and the inner workings of its chemistry. But it's definitely, that's another thing that shocks a lot of people. And I think this is where it gets really hard for startups. And I don't know, we can dive into that because I know you guys work with a lot of startups too. Just to like, that timeline can be really tough to work around when you're on a funding cycle where you need to show results in 3 to 12 or 18 months.
Nate Matherson (Speaking) Karl Hughes
Yeah, I totally agree with you that taking a step back, that content outlining is an incredibly important part of the process. I think it's the most important part of the process because if you don't sufficiently outline a piece of content, you're probably going to be unhappy with it when you get it back. So I think the more time you spend in the outlining and briefing and then reviewing those outlines, like it's only going to save you time later on in the editing process or the reworking process. Whenever I assign a piece of content to a freelance writer and I get it back and I'm not totally happy with it, it's usually my fault because I usually probably miss something in the outline or I could have done a better job at being more specific in the outline. And so an outline, like it should take in my experience, 20, 30 minutes on an outline. How often do you guys usually spend when you create an outline?
Karl Hughes (Speaking)
14:36
Yeah, same, same. It's 30 to, I've seen some outlines an hour and a half because there was maybe more in-depth research that needed to be done before we could really write it in the right way. But typically I would say 30 minutes to an hour is not unusual. Especially, again, it depends on how deeply you, the outliner, already know the topic. So how much research do you need to do into what this is and getting all the ideas across? But also how deep is that topic? How big is this article? Lots of things like that. But yeah, I've done many in outline for draft.dev and almost never do I get them out in less than 20, 30 minutes each.
Nate Matherson (Speaking)
15:15
And a question that I'm asked once a week, because we work with a large number of companies in the developer tools and SaaS spaces, is how do I find freelance writers? Like these founders that we work with, they've got a lot going on. And like my recommendation to them is to stick to like one article per week. Because if you can commit to like one article a week and do that for an entire year, you're going to have like 52 awesome pieces of content in a year from now and I think be pretty happy with where you're at. But then they always ask me like, hey, Nate, like I don't have time to write like one article per week. Like I need to hire someone to do this. Where do I find like these engineers or these highly technical people to write for me? And so I know that they could work with an agency, but I guess my question to you is like, how do you find talent? And if I was going to build this channel with a freelance team, how would I actually find people to write content for my website?
Karl Hughes (Speaking)
16:08
Yeah, very good question. And to be fair, a lot of our clients will work with us to get started or maybe it's as an augmentation of their existing team and they also have freelancers that they work with. There's trade-offs to freelancer versus agency and agency is not right for everybody by any means. We had a huge markup on everything because that's what we have to do, because we have all these operational overhead costs, but we get you more consistent polished pieces. And so the hidden cost of freelancers are a finding them, like you mentioned, but then also the editing and cleanup and review and keeping them on track with deadlines. Again, if these are full-time engineers with a day job, this is second priority for them. Anyway, to go back to your original question though, because it is a good one is how do we start finding these engineers? So when I was starting draft.dev, I'll tell you how I did it. First step was go to my friends and people I knew in my network, people I had interviewed for jobs in the past I knew were kind of interested in writing, but were also engineers, people in Chicago here where I live that I knew were kind of in this world that could do this. And then started to branch out and go out to individual people who were writing on the internet and cold outreaching to them. So if a software developer is writing consistently on HashNode, Medium, Dev2, you can guess that they're either interested in writing, and that's why they do it for themselves, or they're interested in the personal branding aspect of writing, and they might want to get paid to go get their byline on your website as well. Now, that's kind of the, that's the brute force method. That's how you start, because everybody has to start, you start with no reputation, and you have to get some things going. As we've grown, what we've been able to do is build an inbound pipeline of writers, because we pay well, we have a good reputation for working with writers, so we get a lot of word of mouth, as well as, all the time we see the writers come in through YouTube videos, or through listicles online that other people have published. So it just, it happens, it can happen organically over time, but you definitely won't get that on day zero, that's like day 360 or day 720.
Nate Matherson (Speaking)
Yeah. And that phenomenon happened at ContainIQ, actually. We would get at least one person reaching out per month saying to us, like, hey, love your blog. I don't know if they did or not, but can I write content for your site? Over time, we built out our own freelance team as well, like you described. So we worked with both three or four freelancers pretty consistently and then we worked with draft. And I agree with you, like working with an agency is a lot more expensive than kind of owning those relationships with freelancers directly. But me and my time, I would have to spend a lot more time like managing the entire editorial process with a freelancer. And so the reason that we worked with both a freelancer and an agency is because it just helped us to move faster. Like we were averaging over about 14 months, like three to four pieces of content per week, which was just a lot of content. And so there would have been no way that I could have owned a freelancer team publishing three to four pieces per week while trying to ensure everything's accurate without also working with an agency. And so for us, it just helped us scale, but there was definitely the downside in like the additional cost of doing so. My next question to you is like a little bit more specific on like hiring a freelancer. Like do you ask them for like writing samples? Do you have them go through a test? Like how do you screen these candidates once they've kind of showed up or after you've reached out to them?
Karl Hughes (Speaking)
19:29
Yeah. So I'll tell you how I used to do it again. Like I feel like I'm just sharing what I used to do that was wrong and what I do now that's like much better because that's really like we've learned a ton just like in the doing of draft.dev. So when I first started, it was just send me some samples and if they look pretty good, then I'll let you give a shot at an article. When I did that the first few times, I got good looking samples from people and then their articles were just completely night and day different. They're just terrible. I realized what was happening was they're sending me samples that had been heavily edited and revised by their clients or by some website that they wrote it for and not original writing samples. So now, unless they've given us work that is definitely not revised, like for example something they published on their personal blog and they did that consistently and it's in the same topic area, we almost always require a paid trial assignment is how we do it where we'll give them an article that's due several, several weeks out, like way down the line. That way we've got plenty of time to fix it and rewrite if we have to. And we will give them the expectation that if you do great work, you're going to get paid. If it's as good as your samples you sent us, you're going to get paid, and here's how much, and here's what it's going to look like, and you'll get accepted into our writer pool. And if you don't do great work and it's not on the level that, you know, like your samples are clearly and like, you know, that it's going to take a ton of work to fix or you don't finish it on time or you don't finish it at all, then you're going to get like either a minor pain, like a small payment, like a token of thanks for trying, but like, you're not going to get, you know, you're not getting full article. You're not going to get the byline. You're not going to get everything else like you got that. So anyway, we, we've gotten a lot stricter about that because there's so many writers come in just with edited samples that look good, but then you dig in, you realize they didn't really write that well, that a really good editor worked with them, or maybe even somebody else behind the scenes had to fix it for them.
Nate Matherson (Speaking)
21:21
Yeah, I think that's a really good point. I've seen something similar, like the samples are always better than what you get back. And I actually really like Upwork. I've used Upwork to hire freelancers for 10 years. And whenever I'm like trying to hire a freelance writer on Upwork, I'll typically post a job and then hire four people. I'll have each one of them write a slightly different article, so a different primary keyword so we're not writing the same article four times. But then I'll usually pick one out of the four to build that relationship and keep working with. After you get a piece of content back from a freelance writer, how important to you is sourcing? Is that something you actively focus on with the content you create?
Karl Hughes (Speaking)
22:06
Yeah, and the editorial process. Yeah, we do. We sorta, like I mentioned, we kinda have two layers of tech review and editorial review. And so that tech review is the first thing we do. And this is where it most often comes up. Like an engineer will say something like, Kubernetes is just better than Docker. And it's like, well, you definitely need a source if you're gonna say that, or you need to explain what the hell you mean. I mean, cause that's not like objectively true or well accepted or whatever. So that layer happens. And then the editorial team as well, will kind of look at the client's preferences around sourcing material or sourcing links and things. Now this gets really tricky and I'll give you my opinion, but we've also got clients with very different opinions. My opinion is you cite the best source available, whether it's a competitor, whether it's a like, you know, competing blog, maybe not your primary keyword competitor or whatever it is, but like at least cite useful sources. We have some clients that never want a source cited at all. Other clients, unless it's internal to their blog and only build internal links. And then other clients who will say, you know, you can source things, but they have to be completely non-competitive. They have to never step on our toes, be very careful about that. So we go through it on a client by client basis and decide. Again, I look at it as Google wants to reward or SEO is all about rewarding content that is genuinely the most helpful content on the internet. And if you think that like skipping over a source because, or just not having a source because all the sources are possibly competitive, I think you're getting way too like jealous about readers like time and you're not really respecting their intelligence.
Nate Matherson (Speaking)
I agree, I always say to do what's best for the reader. And if actually sourcing to another webpage that might be slightly related or competitive to you is a better experience for the person coming to your website then I think including that source would be the right thing to do. Early in my career, like we had that policy of not linking out to very many websites, unless you were like the Wall Street Journal or the New York Times, we weren't going to link to you. But then over the last four years, I have not worried about that at all. We just try to source the best information, whether that's a piece of content on our site or to a report or study done by a competitor. At least in 2023, I have no problems linking to a large number of other SEO focused blogs and tools on the positional blog. So it's not something that I actually worry about. And I have to ask, because you mentioned it, I wasn't gonna bring it up, like AI generated content. Should I be using AI generated content? Is that something that like your clients should be using? What are your thoughts on AI in 2023?
Karl Hughes (Speaking)
24:45
Yeah, man, I have a lot of thoughts. I'd be curious to hear if we diverge on this at all, but we probably, again, because I think our philosophy on content is do what benefits the reader most. And so I think we probably will share a lot of the same thoughts here. So I don't believe that because AI contributed to your content process, your whole content, like every piece of every article that has any AI written content, it must be trash. Like that's probably not true. And I think that we can probably say that there's some articles out there that, you know, if the goal of it is just basic definitions, maybe they could be written largely by AI and cleaned up by a human or something like that. Maybe. Now, it gets tough in a technical realm, like, and this is where we, for draft.dev, we've not had success writing articles with AI. I'm sure I've tried it. I've got a couple of YouTube videos where I was, like, playing around with this stuff last year. The tools are cool, they're getting better, but we don't use it for writing articles whole cloth. The things that I have found it useful for, and this is me on a personal level and less about how we institutionally use this through all writers. One is helping you generate background research for articles and outlines for articles. Now, you do have to fact-check the current iterations of GPT. Maybe that gets better in the future where they're going to get better at sourcing things and all that. I'm sure that's coming. But for today, you really do have to be knowledgeable about the topic or at least double check that this AI gave you something that's true. Because it often, its dataset is still not all necessarily current, especially when you talk about really cutting edge technical topics where the information around it might be changing on a monthly or six month basis and maybe GPT's model hasn't been updated with the latest six months of articles and so it'll give you things that are very out of date. So you gotta be careful with that. But it is good for some background research and creating, like helping you start outlines and coming up with ideas there. Now, on the writing side, I've had much less luck with it doing things like writing whole articles, but could it write you a transition sentence between two sections of content? Yeah, absolutely. It's pretty cool to do that kind of thing. And of course, I think I always clean it up after because it doesn't do a great job like matching tone of voice or the way I would write, but it's at least a starting point where you're kind of like, okay, I see that that transition makes sense. And it's kind of useful. It can also be useful for generating, say, like, and again, you have to back check it. So I'm like, put the asterisk by this every time generating a code sample that's just going to help readers show how to like import a library, something really simple, right? Like a simple if statement or something like that, you can do that kind of thing with AI content, and it actually does a fairly good job of it. So there's it's, you know, my views on it are, I think that 10 years down the line, whatever, 5, 10 years down the line, maybe, it will be baked into all writers' processes, just like QuickBooks or Excel is baked into every accountant's processes. Now, to what extent it will be the human versus the computer and how much of each will be doing the work, I don't know, but it's going to be a paired process. And so, to me, what that's exciting about is we spend a lot of time on helping engineers write better. If the AI tools get to a point where they can help engineers write better without us having as much human intervention, that's going to solve a ton of cost challenges for us and make our process way more efficient. So that's my perspective on it. But you can come back to me in five years and see if my prediction holds up or not.
Nate Matherson (Speaking)
27:58
You're starting to sound like Google search guidelines, Carl.
Karl Hughes (Speaking)
28:02
Because it's a little ambiguous, right? I'm not telling you black and white, it's good or bad. I think it's, again, it comes down to human usability. If AI generates useful, high-quality content sometimes for regurgitating a well-known fact, okay, fine. But the problem it has right now is it doesn't learn the same way a human does. It doesn't have personal experience. It doesn't have any cutting edge knowledge or the ability to filter out knowledge. It's just purely taking in massive amounts of data and trying to make a best guess on what should be the correct answer here. So we're gonna run into big problems as it comes to content around like people poisoning the well essentially for AI content. If it keeps scraping all of the Internet and saying all of this is equally quote unquote true. It's never gonna be able to figure out what's right and wrong because it doesn't have the same capacity that a human does to filter. It's just that they're big models that just suck in data and give you the best guess on the output. So unless we start to build in filters there, somebody's supposed to do some kind of human checking on it. And again, this is where I think it's always going to be a paired process with humans and the computer. Just like AI code writing, it's not going to replace a software engineer who understands architecture. It's a totally different kind of learning and skill set.
Nate Matherson (Speaking)
29:12
That actually wasn't where I was going. I think ambiguity is certainly something that Google search team is good at, but I think where I was going with that, sounds like what you've described is that like AI can be an incredibly helpful tool for creating fantastic content, but we're not actually writing like full blown 2000 word articles, copy and paste from a tool like chat GPT. Yeah, I think that's really what Google said in its guidelines. Like they came out like earlier this year with some updated guidelines, which were essentially saying like AI is a very helpful tool. And if it helps you create better content then you should do it. But I think they, how I took their guidelines was that like we shouldn't just be copying and pasting from chat GPT on our website. And we get asked for an AI writing tool by our customers every single week. And they keep asking me like why we haven't built one. We haven't built one for a couple reasons. One, I think it's a really competitive space right now. The other reason that we haven't built an AI writing tool just yet is I think in most cases, when I've seen companies embrace AI as a way to create content for their website, they tend to fall into that camp of copy and paste. They don't actually want to do like the work of editing and improving and using it as a supplement, they would want to lean in the direction of copy and paste. And I don't know that I want to incentivize our customers to copy and paste AI onto their site because I'm not confident that that is like the long-term best thing to do. Like I've seen it work for short periods of time. I've also seen like companies really struggle to get like heavily AI written articles indexed into search and they've experienced a lot of indexing challenges. I'm certainly not the anti-AI guy. I just think that the companies that are using it best are really using it as a supplement to be more productive and not to replace an editorial process or to replace an actual expert who knows a lot about a subject who can actually create a fantastic article that's really in-depth and really helpful. Maybe like taking a step further, like after we've created a fantastic article, like one, we can post it on our website, we can wait for like Google to index it and ultimately rank it in search, but is there anything else we should be doing on like the promotional side? Like is there any tips or recommendations you have for like your customers after they've created a piece of content? Like where should they share it? What should they do with it?
Karl Hughes (Speaking)
31:37
Yeah, yeah, so this comes up a lot because I think a lot of marketers struggle with where to reach a technical audience. You know, like in maybe some forms of content marketing, there's easier distribution channels than in the tech world. So I'll give you some specifics for our industry, and then this might translate to some other industries too. So obviously you can do the simple stuff like post it on your own company's social media, your founders' personal social media, maybe some of your engineering team's social media, like all that, that's fine. I think personal accounts are getting rewarded way over company accounts these days on all the big platforms that I see, so LinkedIn, Twitter, like you get almost no interaction off of like a company account, but personal accounts can still get some on links. And then the other big ones that people miss are pitching it to newsletters. So this is a handy hack that has basically always worked if you're doing good content is you go to the five or 10 newsletters in your space, you sponsor them monthly. So you're paying them a little bit of money, a couple hundred bucks or something like that. And then you pitch them every week on the new content you have coming out or whatever the frequency is. Maybe you sponsor them every six months and you pitch them once a month, whatever you can decide on how to tweak those knobs, but they're going to take some of your pitches because a lot of them are, these are like the list newsletters that just show up and share a bunch of links, right? Easy way to get stuff placed and to get more, like more juice on your content. And then similar is syndication. And this is another one that a lot of people outside of dev world don't know is that there's a actually a fair number of platforms that take syndicated dev content for free and just publish it. And you know, some of them are more, I don't know, more active than others, but like Medium, for example, you can syndicate, you can have canonical links to make sure, you know, it doesn't get dinged. Dev2, you can do the same. Hashnode, you can do the same. There's probably others. D-Zone, I think you can too, depending on the subject matter. And so anyway, I would definitely, like, there's no reason not to syndicate to those when it makes sense. And then you can even publish some original content there and see if that helps, whether it's building links or just building awareness and getting more spread. Those are the big ones. And then, you know, we've had clients do other things like actually run paid ads or promotions or, you know, Reddit ads to content. All that's pretty tough in the dev space because we use a lot of ad blockers and like this, it's kind of a, it's a more, it's a competitive world, but I'm sure there's people who figured out how to make that work too.
Nate Matherson (Speaking)
That's a really great point on the newsletters. We would, at ContainerIQ, post our content to Reddit, and sometimes you would hit a double. But 80% of the time, the posts weren't that successful on Reddit. But we had a really high hit rate and a lot of success with newsletters. And at ContainerIQ, we actually didn't sponsor any newsletters. And every month I would send them like three or four links from our blog and say like, Hey, I think these would be really interesting for your audience. And almost all of the time, like they would pick one and include it. And sometimes we would get like thousands of clicks, actually like a couple thousand, two or 3000 visitors from just getting included into one of like the bigger newsletters organically without paying them. And this was also great for building some backlinks to our site. Our customers always ask me about building backlinks and there's a lot of ways you can build backlinks, but specifically in developer tools, it's actually really easy to build backlinks from newsletters. Because once they create the newsletter, they then post that newsletter to their website. You get the benefit of the backlink. You also get the benefit of being in that newsletter and driving some traffic. I would definitely recommend to our listeners, if you're in the DevTools space, to be thinking about what newsletters you could be pitching with the awesome content that you're creating. Okay, so we've created a fantastic piece of content. We've pitched it to some newsletters, we've posted it on socials. Six months has gone by. Should we be going back to that previously published content and reworking it, improving it, or should we just be focusing on new content from here?
Karl Hughes (Speaking)
35:34
You know the answer, but I think we also, we've talked about this before. Yeah, so this is really interesting and unique, especially unique in DevTools, where if you're writing about something like Kubernetes, it's a constantly changing ecosystem. And so things you wrote six to 12, 18 months ago could get out of date pretty quickly. And in order to maintain your top five or 10 ranking or whatever you're going for, you're probably gonna have to update things pretty regularly. Google tends to reward fresh content, especially in a high-tech field where it knows things are changing a lot. And so you do need to kind of go back to pieces every six to 12 months and start to update them. Now, there's probably a order of operations or like a priority order that you should take when you do this, because if you are publishing one, two, three, four times a week, you're gonna have a lot of content to go through as you make updates. And so what a lot of our clients will do, which I think is probably the right move, is they'll pick their sort of highest potential pieces. So they've already, you know, say they wrote a piece a year ago, it's ranked in seventh spot on Google, but they've noticed it start declining in traffic or something like that. That's a great candidate to go refresh. And so figuring out which articles are on the, like potentially on the decline, or, you know, might be like out of date and you know it, but it's a pretty well ranked one and it already brings you good traffic, definitely worth reinvesting in that article. The breakdown of how much to update and refresh versus write new stuff, it depends. If you're just starting out, just focus on new, obviously, because at the end of the day, it's stuff that if you don't have anything that's over 12 months old, you're gonna get the most ROI just continuing to push out new stuff. But then once you're a couple of years in, it's almost always better to be splitting your time at some ratio, 30-70 or 50-50 even on updates versus new content because you really do get a ton of value. I've seen this a lot with our clients and myself personally on my blog, just going through and refreshing pieces can bring you a couple spots in search rankings and sometimes even more.
Nate Matherson (Speaking)
Yeah, anything stuck on the bottom of the first page or on the second or third page, I think is a prime candidate to come back to and think about how can we make this piece better? How can we optimize it? That's where I would start. Like you described, and customers always ask me where they can get that data. They probably have it just in Search Console. So if you go into Google Search Console and you go to specific pages, you can see the average ranking position as well as the impression changes and ranked position over time. I typically recommend to them like once a quarter trying to pick out like 10 posts that might be are stuck and on the cusp. Because if you can go from like the eighth spot for a keyword to the fourth spot or the third spot, you're gonna like double or triple the amount of traffic you're getting. But if you go from the second or the third spot to the eighth spot, you're on the other side of things going to lose that traffic. So I'm a big believer and I asked this question on purpose just to kind of reiterate this point to our listeners that you should definitely be going back to the content you've already published. And I always like to say, I try to treat every piece of content as if it was published today and a new article that I'm proud of on our website.
Karl Hughes (Speaking)
38:41
I'll say one more thing about the content updates and refreshes and all that. There's one level of just making sure it's up to date and current, and that applies, especially in an engineering context. But other things you can do, there are quick wins on a piece of content that's say starting to lose traction, add more media to it. We find that often can help with rankings because Google likes media. You know, it likes to see a post with like three or four images or diagrams or screenshots, something in it. And then video is great for lifting content up. So if you can go through and record a video about a piece of content and push it back out to the readers. A, it adds more value to readers because they're now able to watch or read. But B, it's gonna increase time on site in most cases or time on page and it's just more engaging and Google's gonna see that. Plus, they like to reward embedded YouTube videos because it's more views for them and more ad dollars for them. So at the end of the day, there's a lot of ways you can refresh it. It's not just going through and rewriting the article.
Nate Matherson (Speaking)
39:36
That's a really good point you make on video. And you're actually like the second or the third guest on our podcast who's stressed video as an important media to include within blog posts. One of our early episodes we did on the podcast with Akash from Windley. He ran like a number of interesting experiments where they added like video content to 20 or so of their blog pages. and they actually saw a really positive organic lift in organic search for those pages once they added video. Whether it's Google's algorithm preferring a video or just Google's algorithm seeing a better time on page or an improved scroll depth or improved bounce rate data, I'm not entirely sure. From your view, how should we think about creating video content and how can we use that alongside the blog content that we're creating?
Karl Hughes (Speaking)
40:27
Yeah, there's a couple of ways we've seen clients do it. So it kind of depends on the kind of content. So if you've got a tutorial, like a walkthrough of how to solve a specific technical problem, how to use our product, whatever, those are great candidates for just tutorial videos, which are a little more straightforward. You get an engineer to record their screen going through it and then do a voiceover if need be. We just started this month basically offering that as an add-on to clients. And that's been really, we've got a lot of interest in that because obviously everybody knows, the people who are doing content at scale know the value of video and how hard it can be to produce it at scale too. So I think that's gonna become a big part of our business down the line. But then it gets a little trickier, a little grayer with some kind of content. For example, like if you have a piece that's more of a high level overview of a topic, or you have a piece that's kind of like a broad explainer of something, just kind of, you know, like whatever you want to do there. So you can have a talking head video where somebody just talks about what this topic is, or you could have two people have a quick conversation about it, or you could try to do like animated videos. We've got clients who do that and have animation resources that that's pretty cool too, but just depends on the level of work and your production quality and level you're trying to go for.
Nate Matherson (Speaking)
41:42
Creating videos is not easy. Frankly, it's exhausting. I believe that if you've already created a lot of great video through maybe a company webinar or a podcast, or you're creating video content on another channel already, maybe there's an opportunity for you to then cut or splice that content or segments of that webinar into a blog post.
Karl Hughes (Speaking)
42:04
That's a good point. So that way we're not having to go and record like an entirely new video. Maybe we covered a topic in quite a bit of depth in a webinar and maybe we can just cut out that section of that video and repurpose it into our blog post. So I would encourage our listeners to think about what video already exists and then how they might be able to repurpose that into their blog pages or for like another shot on goal since they've already done the work. And I do want to ask you two questions about running an agency. I hope that there are some agencies listening to this podcast. What's the number one challenge or number one and number two challenges that you face as running a content agency? Yeah, so for a lot of content agencies, I'll speak secondhand here because this is always the number one question people ask. The number one challenge I hear in content agencies is how do you get clients or scale up your client base? Like how do we make it more predictable and get more of them? And the answer that worked for draft.dev was niche down really hard. So we're never compared to general purpose SEO content agencies because what we offer is a totally different game. Now our target market is much smaller. So in the end of the day, we can't be as big as the biggest like general purpose content agencies probably, it's just never gonna, the market's not there. But as an agency owner, from my perspective, I care much more about having a defensible little niche that we can be the best in, and that people will always come back and remember us because that's all we do, than I care about being the broad general purpose agency that is kind of everything to everybody. So that's my number one challenge that most agencies have that we've solved really well. And by leaning into this niche, we've grown really fast. We've been able to just like carve out a little space where we get tons of word of mouth and referrals as well as backlinks, everything else that comes with it. It's just, it's so much easier when you're in a small niche. And then the other part is that it's a people business. Like ultimately we can use tech to make ourselves more efficient. We can use tech to better prospect for new clients. We can use tech to like make our writers like faster or whatever, but there's always gonna be a ton of people overhead and relationship management and things like that. And so a lot of people who are freelancers really struggle to move from freelancer to agency because you have to become a manager primarily. And so my role has shifted a ton since day one where I was down in the weeds writing articles. And now I am like just trying to convince other people to write articles and convince clients that we can write articles. So it's a totally different game once you move from freelancer to agency. And there's nothing wrong with staying a freelancer. There's nothing wrong with staying small or wanting to be in a business that's low touch and doesn't have a lot of people contact. But if that's for you, don't go into the agency world.
Nate Matherson (Speaking)
44:44
Some of that resonates with me. I think at our first company, the first company that Matt and I started, my role changed quite a bit. We weren't running a content agency, but I saw my role change pretty dramatically from years two through five of our first business. And that was something I really struggled with because in the very beginning, the number of hours I worked equaled our revenue. So I could just work more hours and get more revenue. But then once we got four years in, I couldn't work more hours and drive more revenue. It just didn't work that way. The math no longer worked out. And so, personally, I've struggled quite a bit over time with keeping up to how my role needs to change and then thinking about it. I think thinking about it is something that can be helpful. I've really enjoyed having this conversation with you. If it's okay, I'd love to jump into a rapid fire round. Does that sound good?
Karl Hughes (Speaking)
45:36
All right, let's do it.
Nate Matherson (Speaking)
45:37
All right, on the agency side of things, have you ever had to fire a client?
Karl Hughes (Speaking)
45:40
Absolutely, I've got lots of stories about this. How rapid do you want to be? No, I remember this, I was just telling this story yesterday. We had one that they had all the red flags coming in and we told them, man, we're probably not a good fit and they moved on. They came back two weeks later and said, okay, we'll work within all your constraints. We found nobody else who can do what you do. We want to work with you, we're ready to go. So we said, okay, great, we'll get you up with an account manager to get started. Immediately, within the first two emails, they were pushing this account manager to break all our normal processes, to push them to the front of the line, to go faster, to like, just abusing, like, and honestly, being verbally abusive. We just said, nope, we're done, here's your refund, we're out of here. That's a pretty extreme example, but it definitely happens, and you have to be able to call that and just say, like, this is not worth my employee's mental health, or the pain that this person's gonna be, clearly.
Nate Matherson (Speaking)
I know Developer Tools is a high-cost content creation industry, but in developer tools, can you give me a range? Like what does it cost to create like a fantastic piece of content if I'm the client? Yeah, 500 to $2,500 per 2000 word blog post. Speaking of word count, how long are the posts you see your clients typically creating? Like how long do they need to be most often?
Karl Hughes (Speaking)
46:47
It's hard to get into much technical depth with less than 1,500 words. If you're doing anything shorter than that, it's probably just a glossary piece. It's kind of like, here's what a, I mean a very high level definitional piece, very high level. So 1,500 words is kind of my floor. I would almost never, we would almost never write something shorter than that. It wouldn't be worth our rates and it wouldn't be worth working with a technical writer. On the high end, we do plenty of tutorials that end up being maybe even multiple parts that are 4,500 words or 5,000 words or something.
Nate Matherson (Speaking)
E-books, I see a lot of companies in the developer tool space have e-books. Should we be creating e-books?
Nate Matherson (Speaking) Karl Hughes (Speaking)
47:24
Depends on your market a lot. So if you are selling to a higher level C-suite, I see a lot more use of e-books than in the bottoms-up approach where you're selling to hands-on practitioners. I think there's a pretty good reason for that. Like C-suite type customers, that's an expectation at that level is that they expect to go download a white paper and e-book and learn in-depth about your topic. Bottoms-up developers expect to get their hands dirty and try it out. So knowing your customer matters a lot and it varies a little by industry too. I see more white papers in and eBooks in, I wanna say like security, especially enterprise security, and then fewer in things like CICD tools, because a lot of those are just adopted by developers if they're taking a bottom-up approach. So, man, it just, it depends.
Nate Matherson (Speaking)
How can our listeners get in touch with you, or how do they find out more about Draft?
Karl Hughes (Speaking)
Yeah, so draft.dev is our domain, but I'm also available at Karl, K-A-R-L, at draft.dev. My Twitter and everything is at Karl L. Hughes, so you can always look me up there too. I'm pretty active there, interacting with Nate on his stuff. And then, yeah, I'm always happy to answer questions, whether it's about content, technical content, or running an agency, or buying an agency, because I just did that too.
Nate Matherson (Speaking)
48:47
Well, thank you, Karl, and you will get a backlink from us. So we'll include a link back to your website, as well as your Twitter and your LinkedIn in the show notes that will go live on our website. So everyone will be able to find those links there. And thank you so much for coming on the Optimize podcast.
Karl Hughes (Speaking)
49:02
It was great to have you on. Thanks, Nate. Good to talk to you, as always.
Ad Spot
49:04
This episode of the Optimize podcast is brought to you by a special sponsor. If you're anything like me, you've probably got a lot of content that's not very well optimized and it can be a total pain in your butt to optimize it and ultimately get it to rank better in search. And that's what Positional does. Positional has an incredible tool set for everything from content optimization to technical SEO and planning your editorial calendar. And if you don't know by now, I'm one of the co-founders of Positional and I'd love for you to check it out.