Creating Content that Connects with Practitioners: Cody De Arkland (Part II)
In part II of our interview, Cody De Arkland, Director of Developer Relations at LaunchDarkly, shares some advice for marketing teams that are struggling to produce good technical content consistently, how to tailor your content for software practitioners, and how content creation teams can work effectively with demand generation teams. Finally, he asserts that all marketing activities - whether it be advertising, nurturing leads, or writing a blog post - have one fundamental goal: to create the next interaction.
Read Part I - The Core Tenets of Technical Marketing: Cody De Arkland
InfoQ: Content creation continues to be an ongoing challenge for many marketing teams; however, if done right, it still remains one of the most rewarding investments of time and resources. What advice would you give to marketing teams that are struggling to produce good technical content, consistently?
De Arkland: A lot of people say they want practitioner-focused content, but in reality, they want more leads, or they want more response to ads, as just an example. Those two things aren't necessarily married to each other. If your technical content is a path to get those things, then you need to invest in the technical content.
There are a couple of ways you can do that.
You can bring on headcount. You can look and say, I want really good technical writers to build this for me, but you're going to pay for it. Now you're paying someone on salary to be a content creator for you, as opposed to paying an agency or paying a group to help source that for you. That's the other path: paying someone to actually do that, and having people internally who can help you review. That said, I think it’s really important for there to be a sense of authenticity to your technical content.
I don't want to name drop, but I've worked with companies before who are not very technical companies—their product is not very technical—but they know that technical content wins practitioners, so they really want technical content.
But the message that you're putting out about your product isn't that, so it's hard for me to be authentic about something that your product isn't authentic about. That's the thing— be intentional about the content you want to create. If you want technical stuff, hire technical people or work with technical firms who can help you. Do this while still being rooted in who you are and what you do.
InfoQ: When targeting practitioners, what’s the ideal level of complexity for a message or content piece?
De Arkland: I think that people often go for the complex use cases, because they look cool, but they're not always grounded in reality of what people are looking to consume. Understand your market and understand who your practitioners are. If you're an infrastructure company, but you're positioning a ton of coding things or a ton of real development, code push, Git, stuff like that, it's probably not going to land the same way as introductory content would.
Your content should meet your customers where they’re at. If your company is a young company in a newly defined space, most of your practitioners are going to be newer practitioners in that space. Doing the 5% use case versus the 90% how-to-do-thing use case is important.
I'm always a fan of quality over quantity. It sounds like an obvious thing, but in my experience, it comes up a lot. There are a lot of what I would call traditional marketers who are like, "More noise is better. Let's do the 10 blog posts."
For me, I'll get turned off by a brand if I go and see five blog posts that are half complete or that are two paragraphs long. My impression will be, “you guys didn't even try. You didn't even put forth the effort.”
However, if I go somewhere and I'm getting three blog posts, but they are high quality, I can follow them. I can execute on the steps. I walk away learning something. I'll remember that. My impression will be that this company produces good content, so I'm going to continue going there and look at more of their stuff. Being aware of your reputation with your readers is important.
InfoQ: How can content creators and contributors work effectively with demand generation teams?
De Arkland: There's a cool story here that I think is worth sharing. I tend to be a contributor. Within the marketing group here, I was one of the earlier, deeply technical people. I quickly got really close to the people who were doing demand, not intentionally, but just because they were producing a lot of outbound content.
However, they were having to work with a lot of recycled content. They were taking other stuff that had been written, rewording it a little bit and trying their best to put it forward because that's what they had.
When I came in, they're like, "You like to write. You like to talk about this stuff. Can we try some things?"
They're now my favorite team to work with, because they come with clear asks and they know what their mission is. They know the campaigns they're trying to run, the outreach they're trying to do.
They're also open to ideas. When I come in and say, I'd love to just get on a video for three minutes and talk about app modernization and talk about the differences in pipeline strategies, they're like, “yes, we love that idea!” So I record it. Maybe they’ll put it in the newsletter and in a few other places. They essentially ‘scale’ the content.
As I bring on new hires, I ask them to work closely with the demand gen team, because they're going to amplify whatever content you create widely. We can post it on Twitter, we can post it on LinkedIn, and that's going to have a life of its own. These people are paid to amplify your content. I've done a lot of tech marketing but this is the first time that I’ve intentionally spent a lot of time with the demand gen group. It's one of the biggest lessons I've learned—people that amplify your efforts are gold.
InfoQ: Can you walk us through the typical customer journey for a lead or prospect that comes in: how do you nurture them, educate them?
De Arkland: I have this foundational belief that all of us in marketing, our job is to create interaction. That's the core job. We all have different ways of doing that. Demand gen might do that via ads. Cody might do that via blogs, and videos. Everyone's job is to create interaction. What I tell my team is we're trying to create the next interaction. When you write the blog, what's the handoff to the next interaction point?
I think some people do this in the spirit of, “I write the blog and I hope they sign up for an account.” I'm not saying that's wrong. I do believe that if I give you five things, and you step through all of them, and you're doing the next thing every time, my percentage chance of you signing up for an account is much higher than the one-shot approach of, "I wrote the cool blog, go try us out." If I do, I wrote the blog and the blog had you do a thing.
Then, the next one is maturing that thing. The next thing is another way to grow that thing and roll that out to people. Then, the next one is how to store it. The next one's how to pipeline it. Now you know the whole journey. Throughout that I peppered in a free trial so that you can sign up and take it for a spin. You can see a visual here. Look at all the interaction we're creating there.
I think that being aware of how many of those interactions you complete, and how much they build on each other, increases your chance of success. I try to do that in the content stuff I coach my team on.
InfoQ: New job titles and roles are always emerging in our industry. For example, we’ve recently seen the emergence of the staff-plus engineer role. The idea of the staff-plus engineer is that you can move into a leadership role while still staying on the technical path in your career. The staff-plus engineer or principal engineer provides an alternative career path to people that want to move into senior, decision-making roles without having to lose their technical chops. From a marketing perspective, how would you message your product to a staff-plus engineer?
De Arkland: I think of the problems that that person is solving. The people who report to them are probably in high demand. They're probably working a lot of hours. They're working on highly complex, high cognitive load tasks. These are people that really value to-the-point content. They don't have the time anymore to read the long-form blog posts on how to do the thing. They will just want to know what the thing does.
I think of the small infographics that people sometimes create, showing how something works. That's valuable content for them, like straight to the point. It's an amplification of the practitioner messaging. It's even less about how to, but what does it do? How does it reduce the pain points on my practitioners?
I think developers get a lot of content pushed at them, that is, the message that “using this tool makes your developer life easier so you can deliver for the business.” Developers get that message a lot. As much as people say that developers work in a closet away from all that, they're still acutely aware of what the business needs; they're just working with the code side of it. I think the staff-plus person is really focused on, “what does the thing do, and what's the value to my teams who use the tool?”
InfoQ: In addition to creating a ‘bridge’ between the business and engineering, it sounds like the staff-plus engineer also helps to empower developers in various ways.
De Arkland: They understand the business side and they value that, but they're also trying to make sure their engineers are successful. They're trying to create career paths. They're trying to reduce friction. They're trying to make their engineers’ days easier, fewer 2 a.m. calls, fewer weekend shifts. Let them have the freedom to go and learn technology.
Reducing the burden of pressure on engineering teams is the content that they're going to want to see. For an engineer, I might say, “Here's how you use LaunchDarkly. Here's how you build a feature flag.”
For that staff-plus engineer, I'm going to say, “This lets them move tasks like user targeting back to product management, or out to other groups so they can focus on shipping code, and they can focus on just developing applications instead of supporting all these other groups as well.” It’s a very simplified example but that's how I look at content for them.