January 18, 2018
Ep. #14, How Slack Stays Secure During Hyper Growth
In the latest episode of The Secure Developer, Guy is joined by Geoff Belknap, Chief Security Officer at Slack. Geoff discusses what drew hi...
It’s been a little over two months since your last blog post. You look down your task list, which has plenty of things on it that are not “Write Blog Post.” Yet, you know how important it is to engage developers, and that good technical content is a great way to do that.
A developer audience can be hard for writers to understand. Developers tend to bristle at marketing. Products for developers are often highly technical. For all these reasons, founders of technical SaaS think that only they can write for their blog and that each post must be perfect. At the beginning, it will likely be a founder writing. But, like your early product, the content won’t be perfect.
If you waited for perfect, you’d never publish. And regardless of who is writing, you need a plan. You need to create your editorial strategy, measure its impact, and tune your content engine over time.
But first, you need to start.
The best way to begin is to take a first step. If your blog is empty or it’s been more than six months without a post, publish this week. Don’t worry about topic or volume or cadence—we’ll get to all that. There’s nothing like publishing to create momentum that will lead to future and better content.
If you’re like most dev-focused companies, you have a post titled something like Why We’re Building DevProduct.io. It’s great to have this artifact, but the well runs dry pretty quickly on this type of content. A core foundation of an effective technical SaaS editorial strategy is to focus outward, not inward. You’ll find many more ideas in your developer’s problems than your own solution.
Yet, often content leans toward the product. Especially in the early days as it evolves, you’ll find yourself wanting to post what’s new. You’ll have a big feature you want to highlight and you may use the phrase “proud to announce.” Let that be a signal that you need to figure out how to share knowledge, not features. Remind yourself the problem the new feature solves and write about that for your announcement. This same approach works for everything you publish. Look to educate and inspire. You don’t ignore your product, but also don’t focus on your product.
Finally, in everything you publish, include your company’s point of view. Think back to the reason you exist, what your product makes possible for developers. Within that purpose are viewpoints on your technical corner of the world. In every problem you write about, tap into those opinions.
Content marketing is a long game. You’re planting a lot of seeds that may not be harvested for months. Some of those will grow more rapidly than others, but you can never be certain which those will be. Therefore, it’s important to start early, be consistent, and think about what would be most valuable over the long run.
To start, you can look at pageviews or unique visits to your content. You want to beware of how much focus you put on these metrics, but they are especially useful early on. You want to get feedback on the content you produce. Comparing views across multiple blog posts will help you see what’s resonating with readers and what’s getting picked up by search engines. Ideally, you’re seeing overall traffic to your content growing each month, and your baseline for a typical post should also increase. If some topics outperform others, this can be the first sign of an area to give more attention.
Once your content engine is operating, start to look at metrics that will make more of an impact than simply views. For example:
Be on the lookout for topics or types of content that impact your metrics. Do more of those.
It’s hard work to build a reliable content engine for your technical SaaS, but it is worth the effort. Content scales much better than events, a common developer outreach approach, which require human presence. With content you can iterate quickly and get help from others without a lot of training.
You’ll want to figure out a target cadence for your developer content. This should be based on a realistic assessment of what you can consistently hit. If you’re currently struggling to publish, start with one post per month. Ideally, you’d have new content twice a month, or even weekly. Consistency is most important, because it helps you deliver on a repeatable schedule. Work toward one to two posts per week or month, whichever you can handle, then stick to it. You can always accelerate later.
Once you’ve determined your cadence, it’s time to plan your first several posts in an editorial calendar. No need to over engineer this at first—at a basic level, it could be pinned in a Slack message. Your list of topics should be specific—give each a draft headline, assign a writer, and declare a publication date. Then make sure others in your organization can see this list, so everybody knows what’s coming.
Eventually, you can move your editorial calendar into a more structured tool. You can use a spreadsheet, a workflow tool like Trello, a task manager like Asana, or a more structured project management tool like Jira. Just make sure it’s visible to the people involved in your developer content.
Early on, you may be working from a backlog of post ideas. As you list them out, make sure you intersperse similar posts with different types. It can be helpful to decide on categories of posts—use the specificity to spur ideas. You can also look to developer conversations, support tickets, and public forums like Twitter for potential posts. Finally, taking your core concepts and performing keyword research will both generate ideas and ensure that your posts are search engine friendly.
After you’ve managed a few posts, it’s a good idea to look for external help. Reach out to members of your community, look for freelancers, or engage an agency with both technical and writing chops. Fresh content from a different perspective makes for a better publication, and it also saves your team from getting burnt out.
Underlying all the editorial strategy recommendations is someone’s effort. You’ll need someone in your company to guide the process. The very best person to own the editorial plan is you. If you’re reading this post, you’re likely the best choice (and if someone else sent it to you, that’s a pretty funny joke).
Ownership of editorial will depend on your company’s stage, but you should be thinking about it as early as possible. That means the first owner is almost certainly one of the founders. An early marketing or community hire is good next choice. And eventually, you’ll have a developer relations team to either own or significantly contribute to your editorial strategy.
Keep in mind that the owner may not contribute all the content, but they’ll need to shepherd the calendar. When things get busy and others forget the blog, you are the one who keeps beating the content drum. You help maintain the quality, either with your own eye for detail or through the services of someone else. You help promote the content, measure the impact, and keep your ears open for new content ideas.
The prospect of taking on editorial strategy (likely in addition to many other hats) can be overwhelming. As with anything, taking imperfect action is the key, and then make sure you aren’t doing too much at once. A single, thoughtful post each month is sufficient to show movement and build your war chest of content. Be consistent, measure your progress, and work from a team-visible plan.
There are a lot of competing priorities in any company. For technical SaaS, content will help you engage with developers. If you make regular efforts, the work is bound to become a real business driver.
Do you have valuable insights and experiences in the developer tool space that you’d like to share with our community? We want to hear from you – join our contributor program today.