This is the second part of the recent DevRelX session summary. In the first part, we covered the importance of documentation, keyword research and where to start building your content. Before continuing, you can read Part 1 here.
To participate in future sessions, join the DevRelX community.
Session participants were:
Ash Ryan Arnwine, Director of Developer Relations at Nylas
Vera Tiago, Manager of Developer Advocacy at OutSystems
Alvaro Tejada Galindo, Senior Developer Advocate at Nylas
Elvis Kahoro, Developer Experience Engineer at Warp
3. Community Research
The other side is community research, which is a little less predictable because you're going to go out to where communities live, like Stack Overflow, Reddit or Slack groups, and you're going to see what people are talking about. Let’s make it more tangible. If you're a CI/CD tool, what are the common questions coming up on Stack Overflow around CI/CD or around your competitors? You can answer those with your content and then direct people from these channels over to your blog and get organic traffic from search engines as well.
Both are good options but there are trade-offs.
Ash: The community side sounds like the underlying goal when you are trying to build an audience on your own channels. Have you seen success with first going to where the community is and building up reputation and content? For example, instead of publishing to our blog maybe we could publish to a Dev.to.
Karl: Distribution is another point when it comes to content. There are pros and cons of doing it on your own site versus doing it on third-party sites. The pros of doing it on your own site in the long run - building up domain authority, organic backlinks and reputation for your website is really valuable from a long-term SEO perspective.
The downside is you don't have a built-in audience. That’s when publishing content on a third-party source such as Medium or Dev.to with a built-in audience will get you a lot further by adding that extra push.
Here's also the best of both worlds approach where you could syndicate content by writing it on your own blog first and publish it on other platforms a couple of weeks later and backlink it to your original source or use the canonical links. You can learn more about syndicating developer content here.
Typically we focus on long-form content, such as 2000-word articles, but long-form is not the only approach either. You could go out to Reddit and be answering questions instead. It’s not an uncommon practice in developer advocacy and it’s an effective method to build up awareness. It’s up to you to decide what are some of the key metrics you're trying to improve. If it is traffic to the site, then you absolutely should be writing on your own site and building authority and backlinks there. If instead, it is broad general awareness or you're trying to contribute to existing communities, then do some content externally. If you can blend and do some of both, that's the best approach. But if in the early days you may not have the resources to do it all and so you have to decide where you want to spend that time.
The ideal approach is to publish in your own blog first and syndicate out to other places. There's a popular method in digital marketing when you publish content on your own site, the big long-form piece, and then you slice that up into a lot of bite-sized pieces that you can put out into Reddit threads, Twitter threads etc.
The other thing you can do is write guest posts for a variety of publications you can backlink. SEO is an important part of building up traffic over time and one of the important things in SEO is building backlinks. You could, for example, do guest posts on one resource and link it back to other posts you’ve written on the same or other sources. This is helpful in building up authority because you are contributing good content with organic linking without making it spammy. If you can create content in a way that's helpful then it's absolutely a great way to build up domain authority.
4. Unique perspective
The last method of coming up with content ideas is using your unique perspective to drive interest or to talk about something controversial. This is often called “thought leadership content” or point of view content. It is based on the unique thing that you know about your industry, market or customers that the general population might not agree with or might not have insight into. This could be your CEO writing an authoritative piece on CI/CD ecosystem trends, how they think it's changing, and what new developers care about. These are opinion-based pieces. Another good example would be a deep dive piece on a technology that almost no one knows about. Going into a subject deeply, blending good research with a personal experience. This is the high level of content that takes a lot of specific experience and point of view that you're almost never going to be able to outsource even to a good agency. If you can produce such content, it can easily get on the front pages and be picked up in a newsletter.
Such unique content produced in a great way and blending in with some other topic ideation methods is the type of content that is scaling up content production altogether. Let's say you publish one to four of these big heavy hitter posts from an executive or manager level authority every month, and add four to twenty day-to-day blog posts with tutorials or other basic explainers, keyword-focused articles, listicles, and comparisons.
Understanding Trending Topics
There are a couple of ways we see organisations trying to understand what topics are trending among developers. One would be going to their engineers, especially the CTO or a Director of Engineering who oversees broader trends and might have some insights into where the industry is going or where their niche of the industry is going.
The other way goes back to that community research bit, where you keep an eye on industry news, follow newsletters and see what's coming up regularly and you'll start to notice some trends in developer conversations. This should be part of any community-based job like developer relations. You have to be plugged into this community, especially your core developer community. One thing that a lot of people outside the industry don't realise is how nuanced the different kinds of developer communities are. There's a whole crew of DevOps and Sysadmin types, there's a crew of Machine Learning and Data Engineering types, and they're different. And then there are crews of front-end and back-end engineers and full-stack engineers. They all have different philosophies on how they're supposed to do things. It is not a single-minded group, unfortunately.
Community Discussion
Vera: Although we have a very well established developer community, when we tried to ask what are the top trends you are interested in this year, they said “we hate trends and we don't want to talk about that”.
Karl: My advice is, before coming up with articles around very buzzwordy topics, talk to engineers on your team and see how they really feel about that term or topic. Because whatever may seem like a “hot” topic, it doesn't mean developers who are actually writing code everyday care or think about it.
Ash: How do you put your finger on the pulse of where developers are going to consume media? Are there emerging new types of media and networks to be on?
Karl: You have to be out there talking to users. Now that we're coming back to live events, it has always been a really helpful way for me to keep up with what developers actually talk about in the real world. And you'll notice some stratification too. We have the old guard of developers who still really like written content, long-form tutorials and documentation, and then we're starting to see more younger people coming out of boot camps or college in the last five years who are video natives. They do almost all their content consumption via Youtube videos or other video-first social networks.
It is gonna come down to who your target market is, and yet most organisations are still targeting senior engineers and care more about the long-term written content. But you should keep an eye on video content for developers because it will be a huge area for the next generation.
Vera: Are developers consuming content in a different way? Should we explore different media? Besides the educational content, you need to build a reputation and get attention. If you do for example small funny videos empathising with the struggles that software developers have, you will get more attention quicker, and once people will know your name, then they will read your content. Even if I was sceptical at first, I see some value in this approach. In reality, people are consuming content differently which means that probably people don't have the time to read the documentation on our entire blog.
I think we should be aware, pay attention to different types of media and do experiments around it before making it a full program or initiative.
Karl: You bring up a really good point there. It's easy to spread thin or get distracted if you do everything at once, but if you intentionally go to a new channel and say I want to experiment with this for two or three months and see what happens, that's a smart way to approach new things without blowing your whole budget on a bunch of different channels.
Finding Writers
We talked about content ideation methods, the other side of this that gets really tricky is finding writers. This comes back to what sort of content and how much of it are you trying to produce. There are a few ways you can approach finding writers.
Most frequently organisations start with their internal engineering team or getting a first-ever person to write some articles. But pretty quickly you will realise how much content you can realistically produce in-house. That's where you will need to decide, do you want to build up a community writer program by hiring freelancers? Do you want to work with an agency or do you hire full-time technical writers? All are valid approaches and I can give a few pros and cons to each.
I really like community-driven content, whether you build your own program or use a provider like Draft.dev, you'll get real engineers with hands-on experience writing for you. If you can engage your engineering team, that's great. But their primary goal is building the product, which is why it will be hard to get them to consistently contribute more than a few times.
Vera: I’d like to bring up Elvis' question which is related to not only leveraging the engineering team to write content but also leveraging the community. This is similar because that is not their main focus. Do you have any tips or frameworks around engaging volunteers? For example, we help them with proofreading or have experts help them shape the content. But is there a more specific method to be more successful in leveraging volunteers, whether it's internal volunteers or community champions?
Karl: Engaging volunteers is always going to be the toughest because at the end of the day you're asking for their time and people are busy with other commitments. You could try offering some kind of nominal stipend if you have the budget for it. Or look for other ways to show that you value their time and their effort that isn’t non-monetary. A lot of programs offer donations on behalf of volunteers or gift cards, it can be something really simple. Show the engineer that you respect their time because it’s likely they make way more than that per hour, so it's not really about the monetary value, but about showing you care.
There are some other motivating factors you can highlight. One is if you have a really great product and you've got a lot of people already naturally talking about it and writing their own articles on their personal blogs or social media, you should absolutely reach out.
It’s a great alternative if you don't want to build your own in-house community writer program yet. It may sound simple, but giving them bylines, helping them out by promoting their work and promoting them as people and what they do doesn’t cost you much. But a lot of engineers who will write on another company's site are trying to build a reputation so that when they apply for the next job, they have a catalogue of work to showcase.
Another method you can try to use with either external or internal writers is intrinsic motivation. We know developers love to share their knowledge, so you should be supporting them along the way and offering opportunities to write about subjects they are experts in.
Vera: What works for our community is of course the sense of community and intrinsic motivation of helping fellow developers to understand more about their topic. But also swag! It won’t work at all times but developers appreciate cool exclusive stickers or a t-shirt.
Karl: Another idea is pairing up a writer with an engineer. For example, you could have a writer with a journalist or communications background who then goes and interviews a few of your community members and adds their quotes to the article.
This way you combine your own experience and back up with their words and elevate their work.
Then the other thing you can try is hiring full-time dedicated technical writers. Though “technical writer” is a tricky term because, typically, it is someone who writes documentation; they would work with your engineers to write it but they're more of a writer type. But also has got a blended meaning these days. There are some technical writers who are actually programmers and can first-hand use your API and write tutorials and documentation for it. It is really hard to hire this type of technical writer full-time and they're pretty expensive because you're competing with a full-time engineer salary rather than a copywriter. So keep in mind your budget for these hires and how many pieces of content you want to produce every month.
Elvis: I have a question - how does this work look logistically?
Karl: This is an example of how we’d work with a client. Typically starting with a list of ideas, then doing keyword or community research and ideation, and then we create outlines and briefs.
This is a really important step if you're working with any external writer, make sure you have really good outlines and briefs for them. You might think that an engineer knows how to write articles but they may have only written a few, and they may not know what you're going for. I used to think it wasn’t as important, and with the first two writers I hired I only gave them a quick sentence about “here's what I want the article to be”. And the articles that came back were completely different from what I had envisioned, which made me realise that you have to give people a lot more context on: who's the audience, how long does it need to be, what assets should they include, e.g. screenshots, code samples etc.
So start with outlines and briefs for your community writers or your engineering team. It's going to help quality and consistency a lot and it's going to lead to a lot fewer back and forth and save your and your writers’ time.
Ash: Have you done any writing on those best practices for creating outlines and briefs?
Karl: We have an article that shows key things that we include in the outline and how you can go about that. You can learn more about it here.
Elvis: I have one quick follow-up question on the brief side. How do you standardise the briefs? Are you making a kind of playbook to ensure the information is consistent?
Karl: We've standardised four or five key types of content, where each type of content has standard deliverables like outlines and all sorts of things that come along with it. We then tweak it to each piece. For example, if you're writing a tutorial, things you need to give to a writer are a little different than if you're writing a high-level guide or a roundup. In case of a tutorial,, you would need to give them access to documentation and similar things to help them see where to go. On the other hand, if you're doing a high-level roundup and you want to focus on the difference between different tools in your industry, you want to share with the writer the tools they might look into.
It's helpful to have guidelines and the best work tends to happen when people have a good specifications.
Ash: When you're sourcing community members to make content, where do you go to search for the right ones? How do you keep track of your community members and their activities?
Karl: There are tools out there for community management that can help you identify community champions based on the levels of engagement in a community.
What we do at Draft.dev is, for example, we get a new contributor that wants to work with us, we add them to a big email list and give them access to our writer portal where they can see all available assignments that fit their skill set, and they can request to write.
Vera: For this, we have a specific tool for the online community, one we built with our own product. This tool helps us with the engagement data and identifying the most active community members. We created a champion program where we award them with titles and special badges on the online community, and they can feel the importance of their involvement. There are many types of contributions and one of them is content. We always try to foster their ideas and then we shape them a bit to align with what is important to us. And we also do that by nurturing a list of topics like Karl mentioned.
Karl: I would love to go on forever but we’re up the time. Let’s connect and please get in touch if you have any questions. Like DevRel, we're very community-minded and want to help everyone do better developer content!
Kudos to Karl and the rest of the group for a session filled with learning. You can reach out to Karl on Twitter, LinkedIn as well as DevRelX Community’s Slack.
Top comments (0)