A consistent drum beat of content is a healthy sign of a developer tool. It shows that you’re not just building, but that you’re also thinking about how people use your software. Your content can grab the attention of developers and help them trust you. Even better, your content should help developers get better at exactly the problems you solve.
In order to consistently publish, you need a process that will help you get and stay on track. And you need to communicate your plans to collaborators. In this post, I’ll share how your technical editorial calendar does not need to be a complex system. In fact, if you start simply, you’re more likely to continue.
Your technical editorial calendar is a memory assistant, a communications vehicle, and a commitment device. Doing triple duty doesn’t mean you need advanced tools. The best tool is the one you will use. Often, it’s the one you’re already using.
I’ve started several content programs from zero at different companies. To do so, I’ve used many different tools:
- Google Docs
- Shared spreadsheets
- Trello and other Kanban
- Asana and other task managers
- Pinned Slack messages
- Email threads
Each of these has their advantages and complexities. For those just starting out, I recommend starting in Google Sheets. It’s simple, flexible, and easily shareable.
Start with some simple headings:
- Publication date
If you’re the only author, you can remove that column until you get some writing help. There are also plenty of other headings you could add, including category, draft due date, code review, SEO keywords, published URL, promotion checklists, and more. You can get there, but right now you need some momentum to ensure you keep using this editorial calendar. Try to keep it simple. And remember one advantage of a spreadsheet is that you can easily expand it later.
The primary reason people don’t stick to their editorial calendars is they don’t look at them. You’ll need to post it in visible locations and build the habit of reviewing it. If you’ve chosen something other than Google Sheets, your tool may have notifications built-in. If not, create recurring reminders for yourself, so you’re always checking it.
One great way to make your technical editorial calendar useful is to fill it with ideas, then give those ideas specific headlines and due dates.
It’s really easy to create a spreadsheet in a moment of inspiration and never look at it again. We’ve all done it. You need to make your calendar real by making it specific: fill in as much of the details as you can, including a targeted publication date. Then share that with your team, especially if you’ll be asking them to contribute.
The two most important things in a technical editorial calendar:
- Make it specific topics and timelines
- Make it visible to others
One common issue I’ve seen is to use vague topics. Something like Python post doesn’t help anybody understand what’s expected. That makes it difficult to get started, even if you’re just using the calendar for your own posts. Instead, write out a full headline like Make API Calls with Python.
Similarly, you may want to get others onboard to write posts. It’s tempting to create placeholders like Nick topic. Instead, discuss potential posts with Nick and build out full headlines with realistic draft dates. That’s exactly what I did with an actual Nick and almost a dozen others when I ran developer content at SendGrid.
Finally, make those topics and publication dates visible for anyone in the group or company to see. You open yourself up to more collaboration opportunities if others can see what’s coming. It’s easy to make a Google Sheet visible to anyone in your organization or even anyone with the link. Choose the settings that meet your security needs, then post the link prominently where collaborators can find it.
The only way you will trust your technical editorial calendar is if it stays current. You want to be looking out to several upcoming posts with specific topics and dates. And if something planned doesn’t reach your goal, you need to update it with a new plan. When anyone else reviews your calendar, they should see your vision for the future.
You can help yourself stick to the new schedule by making it realistic. Sometimes people will attempt to start with a post every day or every week. If you aren’t doing much content, it can be difficult to get to that volume immediately. Good technical content takes time, so you should build it into your schedule.
When we start with clients, we ease into publishing. We’ve learned that there’s a feedback loop as we “boot up” a project. If we rush into high volumes, some of the content misses out on the early learnings. You want to publish enough to learn what’s working, but not so fast that you rush to get non-strategic content out the door.
An updated technical editorial calendar helps you plan your developer content program. The most important early metric—more so than volume, pageviews, or signups—is consistency. Look to your calendar to guide you as you build up technical content.