Category: processes

Draft.dev creates technical content for dozens of developer tools companies , so process optimization is critical for our success. But process optimization isn’t just about being more efficient. It also helps us deliver consistently high-quality content to our clients, and allows us to bring on new clients more quickly.

Defining what content type a specific article will be—and what deliverables clients can expect to receive as a result—is a key component of this process.

In this article, I’ll break down some of the types of technical content and deliverables we currently offer at Draft.dev and why we use them.

Content Types

Different articles fall into different content types, and these content types determine how we produce each article.

If an article is supposed to be a tutorial, it will include clear, step-by-step instructions for the reader. If the reader can replicate what was done purely from the provided instructions, this article has done its job.

This article by Draft.dev author, Lucien Chemaly is a good example of a tutorial.

On the other hand, articles that are meant to introduce a concept to the reader (rather than provide instructions), are considered “guides.” These might be high-level overviews of a technology or collections of best practices for specific types of work.

This article on technical documentation best practices by our writer, James Walker, is a good example of a guide.

Knowing what type of content each piece is meant to be helps the writer understand the goals of the piece, and it helps us set accurate client expectations. You can read more about the specific content types we use on our Content Types page.

Deliverables

While content types help set the overall article tone and structure, the deliverables define the actual pieces of work that come with the article.

We currently offer one or more of the following options when defining content deliverables:

• Screenshots
• Stock images
• Rough architecture diagrams
• Code samples
• Demo application in a GitHub repository

Typically, articles will use 2-3 of these deliverables. For example, tutorials often include screenshots and code samples, while guides might have an architecture diagram and a stock image. It’s all about efficiently communicating what should be included.

Let’s break down some specific content deliverables.

Screenshots

Screenshots shine when text can’t explain what’s going on, or when a text-based explanation would be too complicated to read. If you’re comparing five different performance testing tools for an article, screenshots would help the reader to distinguish different sections.

Imagine you’re writing a tutorial where you’re teaching the reader to place four buttons in a grid on the screen. You could just include code samples since if the reader copies that code they’ll get the desired result. But oftentimes readers aren’t just copying and pasting your code—they’ll write it themselves as a way of training muscle memory. Including a screenshot of how the buttons should look will let the reader verify if they’re correct.

Stock Images

It doesn’t always make sense to have a screenshot or code samples in an article. This is typically the case for guides or persuasive writing pieces. However, an article without any images or illustrations can sometimes become tedious to read. If that’s the case, we’ll ask for a stock image to be included to hook the reader from the beginning.

Rough Architecture Diagrams

Writing about some topics can get complicated—fast. This complexity can quickly become too much for the reader, so rough architecture diagrams are extremely useful.

As you probably noticed, we specified rough diagram. While our talented writers are excellent engineers, they’re typically not illustrators—at least not professionally. If you do want a professionally illustrated diagram included, we can provide that. Reach out to learn more.

Code Samples

We sometimes ask our writers for code samples. This is common for tutorials where the writer provides step-by-step instructions. In this case, explaining a concept isn’t usually sufficient—we want concrete examples of how something should be written so the reader can replicate it.

Demo Application

In cases where there is substantial code included in an article, we will ask our writers to create a well-organized public Github repository to house the project files involved. Clients can then fork or transfer the repo to their internal team if they’d like to maintain the project.

Why are Content Types and Deliverables Important?

Content types and deliverables significantly help define our expectations for both our writers and clients. Adopting these standard options has allowed us to more consistently deliver quality content without sacrificing speed of delivery.

At Draft.dev, we build growth engines that compound and resonate with developers, search engines and LLMs. Our work has generated hundreds of thousands of leads for our clients. To learn more about working with us, schedule a discovery call by clicking here.

If you’re curious what a completed Draft.dev article might look like, here you have it. This article serves as a visual demonstration of our house style (eg, our default formatting for text, code snippets, and images, as well as a peek into our copy editing standards).

What’s actually written in the text of this visual guide doesn’t particularly matter, but Lorem Ipsum is boring. So if anyone’s interested in why Draft.dev’s style guide is the way it is, they’ll find some insight here.

You can find the in-depth style guide used by our editorial team here, if you’re curious and want to see just how deep our attention to detail goes.

Why Draft.dev Uses Markdown for Technical Content

For starters, all of our articles are Google Docs written in Markdown. This ensures a couple of key functions:

• Our clients don’t have to learn new tooling. The Google suite is familiar throughout the business world, from developers to marketers. So no matter who is handling a client’s content, they’ll most likely be able to easily work with a Google Doc.
• Markdown formatting is universal. No matter the client’s content management system, their text editor will know exactly what to do with Markdown. Providing our articles in Markdown ensures that no unexpected formatting ends up in the client’s published content—no matter where they publish it. Any branded fonts and colors and spacing will lay out exactly as the client expects them to.

Want to see what the Markdown looks like before you put it in your CMS? Check out a Markdown editor like Dillinger for a preview.

Editorial Standards Hierarchy and Style Sources

To ensure consistency for all our clients, we’ve built a robust style guide for our editorial team to follow. Our style includes standards from a few common style sources, generally in this order:

1. House style. These are standards that our editorial team has decided on in-house. If our editorial team is unsure how to resolve an edit, they check this guide first.
2. Chicago Manual of Style. A common standard for long-form writing, the CMoS sets down rules for everything from formatting to comma use.
3. Merriam-Webster. The online collegiate edition is our go-to for spelling.

Note that Draft.dev uses American-English spelling and punctuation.

Title Case Headers for Consistent Visual Hierarchy

If a client’s content marketing has decided on any style standards, chances are they’ve made a decision as to how they want headers to look. Headers are typically a short phrase in a larger/more distinctive font to add structure and context to paragraphs within long-form content.

Draft.dev uses title case for headers of all hierarchy; that means most words (but not all; CMoS is very stern about this, sorry about that) in a header are capitalized.

If our clients prefer sentence-case headers (ie, only the first word is capitalized), we can accommodate that too!

Simple, Effective Code Snippet Formatting

While short lines of code can be kept in-line (eg, <ButtonText>) with the rest of a paragraph, larger blocks of code stand on their own, like this:

<Buttons>
    <Button guid="guidOktaAuthVsixPackageCmdSet" id="MainToolWindowCommandId" priority="0x0100" type="Button">
        <Parent guid="guidSHLMainMenu" id="IDG_VS_WNDO_OTRWNDWS1"/>
        <Icon guid="guidImages" id="bmpPic1" />
        <Strings>
          <ButtonText>Okta Extension</ButtonText>
        </Strings>
    </Button>
</Buttons>

To ensure language-specific syntax highlighting for the code block, a client’s content management system will most likely require a plugin.

Consistent Standards With Custom Flexibility

Draft.dev’s house style promises consistency and standard elegance through a highly detailed set of standards established by a team of experienced editors. However, if a client requires the use of their own style standards we can tailor our services to your style guide too!

Documentation quality can make or break developer tools. Good docs are essential so devs can learn how tools work and which use cases they apply to. Content should be detailed, accurate, and accessible, clearly explaining concepts without making readers spend time hunting for additional information.

This article shares some best practices for creating and publishing developer-oriented documentation. These pointers will ensure your guides, tutorials, API references, and other resources all create a positive experience for devs using your tool.

Why Developer Tools Need Good Docs

Developers use software documentation in two main ways: first, to evaluate the high-level capabilities of your tool and, second, to learn the technical details of how it’s used and integrated. Even the best tools are useless if developers don’t know what the tool does or how it achieves its purpose, so it’s vital to invest in authoring quality documentation that makes dev life easier.

The effects of bad documentation—whether missing, outdated, or hard to find—shouldn’t be underestimated. Documentation issues create developer roadblocks that cause frustration and can lead to tools abandonment. Poor docs also drain your internal resources as support teams field more inquiries from uncertain devs seeking answers.

Best Practices for Great Documentation

Creating effective documentation starts with following standard best practices for communicating information:

• Write clearly and concisely, avoiding ambiguous terms and jargon.
• Adopt or create a style guide to ensure a consistent tone applies across your documentation.
• Ensure your docs entry point is easy to find, such as a link from your website or README file.
• Review your docs and replace any outdated information regularly. (If there’s anything more frustrating to developers than missing docs, it’s docs that prove to be incorrect.)

Beyond these principles of documentation, here are four key features to focus on when you’re writing for developers.

Go In-Depth into Features and Use Cases

Your documentation should be a comprehensive, one-stop place to find any answers that developers require. It’s important to provide in-depth details about all the features provided by your tool in addition to the ways in which they can be used.

Beyond a description of the what and how of your tool, your docs should also clearly explain the why. Detailing your target use cases with the ways in which your tool achieves them and the reasons behind any opinionated behavior enables devs and buyers to easily understand the problems you’re trying to solve.

The exact content to cover depends on the type of tool you’re creating. APIs need a breakdown of every endpoint, the parameters they accept, and the responses they issue, for example, while CLI apps should include a reference for each supported command with its options and how they can be combined.

Such detailed reference material ensures developers can easily discover available functions and learn how to use them. The npm documentation provides clear instructions for every command, for example, offering a clear technical synopsis, a description of the command’s use case, and a list of supported configuration parameters:

Create High-Level Summaries to Help Devs Familiarize Themselves with Your Tool

Technical depth mustn’t replace high-level guides and overviews, however. Introductory tutorials that are relatively light on detail but walk users through common workflows in simple steps should also be provided. In particular, create concise installation or setup guides for all supported platforms and environments to ensure that first encounters with your tool are frictionless.

This kind of content lowers the learning curve for first-time users who aren’t yet ready to head deep into your reference material. The GitHub REST API showcases how both these content types can be presented—the top of the sidebar is dedicated to quick-start guides and explanations of key concepts, while the bottom section provides a feature-by-feature index of each API capability:

Use Examples to Support Understanding

Who doesn’t love a good example? Examples can make concepts and features much easier for devs to understand, especially around areas that are unique to your tool. Even comparatively simple functions should include examples as this provides extra clarity to developers and prevents uncomfortable doubts from arising.

Examples should be easy to find, ready to run, and approachable for those who’ve never experienced your tool before. Incomplete examples can create more confusion than they solve as developers might not yet have enough background knowledge to be able to fill in the gaps.

You should include examples in line with your quick-start guides and technical reference information to help contextualize what you’re describing. It’s also useful to prepare a cheat sheet of examples for your tool’s most commonly used operations. Command line HTTP client HTTPie does a good job of succinctly illustrating how to achieve key use cases, for instance:

Where possible, try to favor the use of interactive examples that are embedded into your content. These allow devs to observe features in action without leaving the docs, creating a more intuitive and satisfying experience. The web platform documentation on MDN illustrates this pattern: examples are clearly signposted in the content, including interactive Play buttons that open the code in a live playground environment:

Provide a Convenient UI/UX

The way in which docs are presented is almost as important as their content. Select a clean UI that’s easy to use and well optimized for readability so developers can easily find and digest your material. Setting up a dedicated docs site provides a more sophisticated experience than relying on wikis and plaintext files while creating an opportunity to showcase your brand style and design expertise.

A specialist docs interface also facilitates the use of more powerful capabilities that produce a more convenient developer experience. For example, you could link your docs site to your developer accounts system, then customize your code samples so they include real account values after developers log in.

The Stripe API documentation uses this technique to good effect. Once you’re logged in, the API keys and other configurable values shown in the docs are fetched from your account. You can copy and run the examples without having to manually alter any options:

It’s also good practice to let developers persistently select the client library, programming language, or integration type they’re using. This allows irrelevant information to be filtered out, making it easier for developers to focus on the steps that apply to them.

Prioritize Search and Navigation

In whatever way the documentation is published, it needs to be supported by a clear navigation structure that makes it obvious how to jump between different content types and topics. Establish a logical pathway for users to follow, from the guide to getting started through to the in-depth reference material, but ensure it’s always possible to skip to specific areas when developers already know what they’re looking for.

Use links—both internal and external—to tie topics together. This lets devs effortlessly discover more information that’s related to the topic they’re reading. Similarly, adding a table of contents at the start of each topic and section aids readers in quickly gauging whether they’ve reached their intended destination.

Discoverability is key to the success of documentation, so it’s crucial to integrate search functionality extensively throughout your docs system. Search needs to be fast, accurate, and capable of surfacing material from all your content sections as users are likely to rely on it to reach the topics they’re looking for. A powerful example is Docker, which lets you open their search panel from anywhere using a keyboard shortcut and then neatly groups all the matching pages based on content type:

Furthermore, optimizing content for search engine visibility provides more paths into relevant content, including when developers are still evaluating different tools within the marketplace. SEO for docs is similar to other evergreen content types: add correct HTML meta tags to your pages, use descriptive URLs and headers, and avoid indexing any autogenerated reference material that might trigger a search engine’s spam or AI detection algorithms.

Shareability is another navigation aspect to consider. Making headers into anchors that act as link targets allows devs to more conveniently reference specific parts of your documentation in chat messages, work specifications, and comments on issues and pull requests. This reduces time spent hunting for information, leading to a more satisfying and productive developer experience.

Conclusion

Focusing on documentation quality ensures devs have the simplest possible experience as they use your tools. Properly formatted, easily navigable docs that provide an exhaustive reference for available capabilities—alongside accessible getting-started guides—keep devs productive, improve retention, and reduce the volume of support tickets you receive.

Creating good documentation takes time, but the benefits more than offset any investment you make. As you’ve seen in this article, many of the most successful developer-oriented tools and platforms have prioritized their docs, ensuring newcomers can quickly find accurate answers to their questions while more experienced users have a clear route to the precise technical info they need. In a crowded marketplace, documentation quality can sell your tool over a competitor’s, so implementing the tips shared here will help improve your business outcomes.

Since I started Draft.dev, our team and the number of clients we work with has grown a lot. With this growth has come the need for robust, consistent processes that help us ensure that each client gets the absolute best, highest-quality technical content possible.

One thing I value in our interactions with clients is transparency. We need clients to be transparent about their expectations, and we have to be transparent about our timeline and capabilities. In other words, if we can’t do what a client needs, we’ll tell them.

Our Process for Working with Clients

In the further interest of transparency, I’m going to share our entire client onboarding process as it stands today. While things occasionally deviate, you might find it helpful to see the whole thing laid out. Hopefully, this gives you a better idea of what to expect as you consider or start your engagement with Draft.dev.

Typically, onboarding takes 6-9 weeks between when we sign a statement of work and when your first article is completed.

The timeline may increase if we’re fully booked though, so be sure to check with us if you need hard deadlines.

1. Discovery Call

Before we begin working with a new client, we want to make sure we’re a good fit for you. In our 30-minute discovery session, we’ll ask you where your business is at, what your content goals are, and the type of content you’re looking to produce.

Based on this call, we’ll follow up with samples of our various types of content and next steps, or we’ll refer you to another content provider who’s a better fit.

2. Statement of Work and Timeline

We almost always have a backlog of new clients waiting to start, so once you’re ready to reserve a spot in our production calendar, we’ll send over an estimated timeline and statement of work. This allows us to ensure we have enough writers and editors ready to help maintain our rigorous quality standards, and that both parties are on the same page as far as the scope of work is concerned.

3. Topic Strategy and Intake

During the topic strategy phase, we’ll define your content goals, requirements, and the preferences of all stakeholders on your team. Your team will be able to provide examples of articles you like and any desired topic ideas you have in mind. All relevant information about your brand and content strategy is helpful to our Technical Content Specialists and can be incorporated into your content plan.

Some clients already have an idea of what topics they would like covered, but don’t worry if you don’t have any; this is not required. Our Technical Content Specialists will create multiple topic clusters through search engine keyword research and community-based research for your team to review and approve. Our topic strategy process typically takes a week.

4. Approve Briefs and Outlines

With topics in hand, we’ll create detailed briefs and outlines for each piece. By breaking down each post and detailing the exact expectations before we start writing, we can ensure that expectations are clear for our writers and editors.

Once you approve the briefs and outlines, we’ll get them into our CMS and send over a finalized production schedule. Typically, this won’t deviate much from the proposal unless you need more time to review and approve the briefs.

5. First Payment

When we lock in your outlines, we’ll arrange a payment method with you. We offer quarterly payments by default or monthly payments for a small premium. Most clients pay by credit card or bank transfer, but we can accommodate custom invoicing options as well. Usually, the first payment is due 30 days after signing the statement of work.

6. Production Starts

At this point, we’ve already started recruiting writers, and now that your briefs are in our system, we will start assigning them to our writers. Because our writers are practicing software engineers (most with day jobs), you’ll likely have several writers assigned to your content over the course of the engagement. Our skilled editing team and technical content specialists ensure that the quality and tone of each piece are consistent with our style guide and your preferences.

Finally, if your piece requires custom illustrations or application diagrams, our in-house team creates the assets you need. The goal is for each piece to come back to you ready to publish.

7. Delivery of First Article

Your first article will usually be ready around four weeks after your briefs are approved. Additional content rolls in after that. While we invest a lot of time planning out content with each new client, we expect to accommodate minor revisions on the first article or two as we figure out your style and preferences.

You have two weeks to request revisions for each article with two rounds of revisions available, as it’s important to us that our content meets your expectations.

8. Content Promotion

Upon completion of your first article, your account manager can provide guidance on how to promote your content through social media best practices, ensuring that you are maximizing your audience reach. We will provide you with social media collateral for each of your articles so that you can easily promote your content across all major social channels, including Twitter, Linkedin, HackerNews, and Reddit. By streamlining your promotion efforts with our recommended social media automation tools, you’ll be able to schedule your social posts within minutes after you publish your article.

9. Repeat

After the first article is sent, you’ll start receiving new content every week (sometimes multiple times a week) based on your production schedule. We work hard in the planning process upfront to ensure we can deliver content consistently. That said, we do occasionally need to swap the order of articles based on writer availability and expertise.

About halfway through your first three-month engagement, we’ll start to talk about coming up with more topics and renewing your plan. Pending a signed renewal, we’ll work with you to start on the next batch of content to minimize or avoid production gaps.

Frequently Asked Questions

While that covers the basics, you may have a few questions. Feel free to book a call with us or check out some of our FAQ below.

How quickly can you get started?

Because we’re a service-based business that relies on real humans to write and edit each article, we can’t start overnight. Typically, it takes six to nine weeks between signing our Statement of Work (SOW) and receiving your first piece of content.

What if we don’t know any topics to write about?

You came to the right place. We use a proven method for generating topic clusters around keywords relevant to your business. This will help you rank highly in search engines for terms that your readers are likely searching for.

What kind of articles can you write?

Broadly speaking, we break blog posts down into four types, and we focus on content aimed at software developers, data engineers, technical leaders, and sysadmins.

Typically, we don’t write content that involves inside knowledge of your company or tool, but we can write tutorials based on public-facing APIs or the documented features of your tool. We can also write comparisons, high-level guides, introductions to technical topics, roundups (or listicles), and persuasive pieces.

Do you do ghostwriting?

Yes, but it follows a different process and pricing model.

Our standard content authors are technical experts who write to showcase their expertise and learn new things.

For ghostwriting, we’ll pair you up with a dedicated writer and account manager who will interview you and work specifically on each piece.

Can I start with a trial article?

We don’t currently offer trial articles to prospective clients, but we are happy to send you additional samples. We also offer revisions, rewrites, or refunds if you’re ever unsatisfied with our work.

How much does it cost?

Our service offering starts at $22,000 – $27,000 per quarter, depending on the scope, but we invite you to book a call for the most up-to-date pricing and service offerings. Most clients start with a quarterly 12-post pilot package and renew according to their needs each quarter.

Do you do video tutorials?

Yes, we recently launched video tutorial creation services to all our clients in the developer tooling space. Each package is custom-built depending on your needs with a minimum package size of $20,000 for 6 videos.

You can see a sample video along with more information here. 

Do you do technical ebooks?

Yes, we do offer ebook creation services, but it follows a slightly different process and pricing model than our technical blog post services. You can find more details and specifications on the process here.

Want to Get Started?

Now that you know exactly what to expect when you start your engagement with Draft.dev, I’d love to hear from you. To get started, book a call with us and learn more about how Draft.dev can help you create in-depth, technical content that resonates with your audience.

With the demand for technical content being as high as it is, you might be interested in turning your software development knowledge toward writing. After all, why not? It can be a lucrative hobby if you enjoy writing anyway. You can build a reputation as a voice of authority. It can pave the way toward speaking and presenting, if that appeals. Some developers have even moved on to writing full-time after getting a decent taste for it.

Of course, to get that far down the road, you need people to want your writing. So how exactly do you get asked to keep writing technical articles?

I’ve got you covered. Take your cue from this article, and technical publishers will be piling requests into your inbox.

Hit Your Deadlines

Hands down, bottom line, if you take one thing away from this article, make it this tip. Effective content marketing means publishing on a schedule. Whoever’s in charge of that schedule (usually a content manager) has their own deadlines to hit. They’re trying to reach their own content quotas.

Help them do their job by consistently delivering your writing on time.

I get it, hitting deadlines consistently is hard, especially when it’s not your day job. Sometimes life gets in the way. If you want to make writing a serious part of your career, try to make sure a missed deadline is a rare exception to the rule.

If you can hit your deadlines and deliver adequate work on time, you don’t have to be the best, and you’ll always have writing work.

Understand What You’ve Been Asked For

Every writing assignment should come with a few basic pieces of information:

• your due date
• your pay rate
• how big the article should be (usually a word count)
• any other deliverables (images, video, author bio, etc.)

Make a note of everything you’ve been asked for and make sure it’s all submitted properly.

Speaking of submission, your publisher may have a specific method for accepting your finished article. Do you drop it into their CMS? Email someone a link to a Google Doc? This, and other information, may be available in a style or process guide.

If your publisher has a style guide, read over it and try to follow it. You don’t have to be an expert on their particular style for your first article, but the more you try to adhere to the instructions you find, the more likely you’ll be asked for a repeat performance.

Be Ready for Revision

Here, I have to expound on the previous tip. Revisions are part of writing, and your publisher may have outlined expectations around that for you. Check your contract—is there language about how many revisions you can be asked to do for the pay rate you’re receiving? One revision is common, but be ready for two if you’re writing for an agency with its own end client.

It’s essential to know your publisher’s revision process for a couple of reasons:

• You can decide if the offered pay rate is sufficient once you factor in revision time.
• You can point to a specific boundary if your publisher keeps asking for revisions.

Note: hitting deadlines applies to being timely with your revisions, too!

Your revision will most likely entail answering questions from either an editor or a technical reviewer. Be sure to respond to every query, even if it’s just to disagree with a suggested change politely.

Communicate—But Be Smart About It

If the organization you’re writing for has an established content publishing system, chances are good they’ll have a lot of answers already prepared for most questions you might have.

Before you send an email to your editor with a list of questions, double-check if you’re asking any of these:

• When’s the deadline?
• When and how do I get paid?
• What’s your editing process?
• How many revisions do you ask for?

All of those are legitimate questions. But first, take a stroll through your publisher’s website or any emails they may have sent you when you first connected. If you have a formal contract (and you should), read through it. All of it.

You might find your answer faster there than sitting in someone’s inbox. And content managers love working with freelancers who can find their own answers.

However, you may have one of these questions:

• Can I get an extension?
• Can I get some help on this technical roadblock?
• I think I need paid access to this tool—can you help out?
• To cover this topic, I think I need a higher word count. Is that okay?
• Can you help with a problem with a payment?

Especially if it may affect your due date, be sure to get these questions asked as soon as they occur to you. Changes are more problematic to accommodate the later in a schedule they appear. You’re more likely to receive a positive response if you’re not putting your publisher into a time crunch.

Learn to Self-edit

Last but not least, perfect your writing. Strive to improve next time after receiving a round of feedback or edits. Pay attention to what’s been adjusted upon publication and, within reason, try to handle that on your own ahead of time.

If you’re being asked to supply a 1500-word article and your Google Doc is well over 3,000 words, go over your article with an eye for cutting out the fluff. Are you being repetitious? Are you trying to cover too much? Whoever edits your article will appreciate you taking the time to clean your work up before it reaches them.

But self-editing isn’t just about making things easier for your editor. It’s also about protecting your work. Your complete message is more likely to make it to publication if you don’t leave a mess for an editor to push into shape.

Think of editing like house cleaning. Sure, you may hire a cleaner to come in. But if your sink is full of dirty dishes, they’re probably not going to be able to clean the sink. If your kid’s toys are all over the floor, the professional cleaner may not have time to vacuum.

Leaving messy writing for someone else to fix is kind of the same deal. Your article will probably not look super polished if your editor is trying to shove your metaphorical toys in a hall closet.

Obviously, the writing that goes into your article is the most important thing to pay attention to here, but don’t neglect your email communication! If you want to present yourself as a professional writer, try to use standard spelling, capitalization, and grammar at every opportunity.

Conclusion

Adding technical writer to your LinkedIn page isn’t as much about being a great writer as you might think. Like most jobs, your success as a technical writer boils down to how difficult you are to work with. Do you make your editor’s job easier? Are you reliable with your deadlines and the completeness of your work? Are you efficient and professional in your communication?

At the end of the day, that’s what will keep the writing requests filling your inbox, I personally guarantee it.

Interested in writing for Draft.dev? Click here to learn more and apply today.

Want access to our fantastic pool of writers? Schedule a call to learn more about what we do.

Ever since I started Draft.dev in 2020, one of the most common requests we’ve gotten from prospects has been video production. Unlike our growth marketing services, video was an area where I had little to no professional experience, so I was wary of taking it on without the expertise available to do it right.

Fortunately, as our team has grown, so have our capabilities. I’m excited to announce that as of this month, we’re offering video tutorial creation services to all our clients in the developer tooling space.

Here’s an example of a video we did for our own content recently:

Learn more and book a call to discuss video tutorials here.

Why Video?

Our success at Draft.dev is largely due to the fact that we focus on doing very few things, very well. We only produce technical content for companies trying to reach subject matter experts.

Most marketing agencies can’t resist the draw to become full-service providers for their clients, offering everything from branding to design to ads to content. Draft.dev is different because we intentionally say no to all those other forms of work in favor of doing fewer things better.

So, I didn’t take the decision to add video content to our list of offerings lightly. But I also want Draft.dev to be the premier content creation company for developer tools brands, so I knew we’d eventually need to have it. There’s a lot of reasons clients want video tutorials, but a few include:

• Supplement SEO – Written content with an embedded video tends to have higher time on page and a lower bounce rate. This in turn helps Google recognize the value of your content.
• Reach younger developers – While my generation learned on text-based platforms like Stack Overflow, developers coming out of school today are more video-native than ever.
• Improve social reach – Social platforms like TikTok and YouTube are extremely popular discovery platforms, and even text-based platforms like Linkedin and Twitter are doing more to support video than before.
• Augment documentation – Text-based documentation is the standard among developer tools companies, but video is quickly becoming an expected addition. Having videos to supplement documentation will be essential in the coming decades for some of the same generational reasons above.

Why Aren’t More Developer Tools Companies Using Video Today?

Video tutorials are incredibly hard to do well and even more so at scale.

Clients are often surprised by how well we do written content because they know writing for developers is notoriously difficult, but video adds another level of complexity. You need at least four different roles to do video work well, but most companies can’t justify making all these hires:

• Engineer to create the tutorial
• Another engineer to test and verify the tutorial
• Editor to create the script
• Engineer to record the video
• Video producer to add visuals, transitions, and effects
• Voiceover actor to read script

Obviously, you can compress a few of these roles, depending on each person’s skills, but then you run into a question of time utilization. Does it really make sense for a software engineer to spend 8 hours editing and producing a video? Can you afford to skip testing when it means you might have to re-record the whole thing because you find a bug in 2 months?

How We Create Technical Tutorial Videos

Similar to how we produce written content, our philosophy with videos is the same:

Find experts in each step in the process and hire them to do the part of the work they do best.

This allows each of them to focus on their area of expertise and ensures that our team can cover a wide range of technologies while keeping costs down.

With over 300 engineers in our writing pool, there were plenty who had some video experience and the software necessary to record tutorials. Two of our editors also had experience writing scripts, so we were able to build that capacity quickly.

Finally, I bought an audio and video production company earlier this year, and part of the reason was that they’d be able to do the video editing and post-production work that I didn’t know how to do yet. Their expertise has been invaluable as we explore adding short-form and long-form video to our offerings.

I’m really proud of all the work our team at Draft.dev put into figuring this out. If you’d like to learn more, please book some time with us here.

Before 2020, remote work existed but was not as prevalent as it is today. Truly remote companies, like Basecamp, were few and far between.

Then the pandemic arrived and everything changed. With people in lockdown, companies had no choice but to adapt. Everything from meetings to collaboration to informal chat was now done remotely. There was an adjustment period, but two years later, the remote-working model has proven to be successful.

By allowing employees to work from their home offices, co-working spaces, or even coffee shops, companies gave employees the freedom to work more productively. For example, people who work from their homes were able to reduce the interruptions and noise that traditionally happen in an office. People with children were able to pick up their kids from school and finish their workday later at home.

Obviously, remote working doesn’t come with benefits alone. When employees could just walk to a colleague in the office, communication now requires a Slack message or an email. If employees are not quick to reply, there can be delays. Loneliness and disconnecting from the mission of the company is something that managers also need to be aware of.

That’s why distributed teams need to have the right tools to keep working effectively. From organizing and carrying out meetings to collaboration, this article discusses seven tools that can help your team succeed in a remote-work environment, including Zoom, Status Hero, and Jira. These tools have been chosen due to their ease of use, customizability, and support for different time zones.

Remote-Working Tools

Since the pandemic, a slew of tools have been created to assist companies and their teams in a remote-work environment. However, not all of these tools are easy to use or customizable. In this section, you’ll learn about the tools that will help your remote team function well.

Conduct Meetings with Zoom

It’s hard to talk about work without mentioning meetings. Even if you are a solo entrepreneur working from your basement, you’re probably subjected to meetings on a regular basis.

Thanks to the pandemic, Zoom quickly became the preferred videoconferencing tool of companies across the world as they needed a way to continue meeting remotely. It offers features like waiting rooms to allow hosts to decide when participants can join, breakout rooms to divide participants into smaller groups, and the ability to record meetings.

Breakout rooms, in particular, are very helpful. In a remote environment, it can be hard to have informal chats with your colleagues unless they are scheduled. This is why if you have a weekly meeting with your team for a status update, for example, it can be helpful to start with a small informal chat. If you have a big team, breakout rooms can be a great tool to divide and let them chat about their weekends for a few minutes before starting the meeting.

The recordings are also beneficial for people who are in different time zones or weren’t able to attend a meeting for one reason or another.

Overall, Zoom is easy to use and comes with a lot of additional features even on the free plan.

Organize Your Daily Updates with Status Hero

Most companies have regular check-ins to follow up on projects and touch base on any questions team members may have. What tool you decide to use will highly depend on your team’s communication style. If you work remotely but synchronously, then your stand-up is probably done with everyone present at a specific time. In this case, Zoom is your best option.

However, if you want to reduce the number of meetings and push asynchronous check-ins, then consider using Status Hero. The goal of Status Hero is to turn long and sometimes unnecessary stand-up meetings into a concise report for all team members to review. What would normally be a twenty-minute meeting where people list what they have done one by one is instead turned into individual reports where people clearly list out what they have done and will do and, more importantly, highlight blockers. With Status Hero’s numerous integrations available, you can integrate data from your other tools such as Zoom, Asana, or Jira and see what your colleagues have done in the last twenty-four hours.

Manage Your Project with Jira or Asana

When it comes to project management, there are so many tools to choose from that it can feel overwhelming. In this article, you’ll look at two options: Jira and Asana.

To say Jira is easy to use would be an exaggeration. The learning curve to getting used to this tool is not negligible. However, once you get used to it, what Jira sacrifices in ease of use, it definitely makes up for in features.

Jira is highly customizable, letting you create fields and automated processes. For example, you could set up a process such that when creating a bug, the technical support has to fill out a few fields like the number of customers impacted or which area of the product is impacted. Once created, that bug could automatically receive a priority (low, medium, or high) and be assigned to the right development team. This kind of process saves a lot of time in the long run, which is why Jira is a popular product among big companies such as HubSpot, Zoom, Bloomberg, CBS, and more.

However, if you’re a smaller company, Asana might be a better fit. While not as feature rich as Jira, it’s very easy to use. It has an aesthetically pleasing and intuitive user interface. Whether you work in IT, marketing, or sales, it comes with a bunch of templates for you to choose from. It’s an excellent project management tool for companies who don’t need all the bells and whistles of Jira but want access to straightforward boards, lists, and timelines.

Collaborate with Google Products

Google products need very little introduction. With Drive, Docs, Sheets, and more, Google offers tons of tools that are great for collaboration. Whether you’re working on a proposal or a presentation, Google has a product for you. Many people use it in their personal lives, so introducing Google products to your team is painless.

With Google Docs, you can even leave comments and suggestions, making the collaboration process easy for teams working asynchronously.

Document with Confluence

While Google is a great tool for collaborating, searching through Drive can get complicated. This is where a tool like Confluence is a great option for documenting processes and more.

When a company reaches a certain size or age, it’s important for employees to start documenting company knowledge. This can include product knowledge as well as processes, technical investigation, and internal decisions. This documentation will be helpful not only for new employees but also for older employees as they leave the company. It’s important to have this knowledge written down to have a better overview of how your product works and why certain decisions were made.

Like Google Docs, Confluence is easy to use. You can quickly create pages, format them, and leave comments to collaborate during the documentation process.

Communicate with Slack

When it comes to communication, it’s hard not to mention Slack. Even before the pandemic, Slack was an incredibly popular communication tool. With its attractive interface, Slack is very intuitive and easy to use. On top of their chat feature, they have recently started introducing more features such as calls and huddles to allow you to organize meetings without leaving.

Slack also supports a lot of integrations, including Jira, Google products, Salesforce, and GitHub. Regardless of the tools you use, you can probably integrate it with Slack.

Conclusion

[Remote working is a great model] (https://draft.dev/learn/becoming-a-remote-technical-writer). It has given more flexibility for workers to do the job in a way that is most comfortable to them and provides for a better work-life balance. However, in order for things to run smoothly, certain tools are necessary.

In this article, you learned about tools like Zoom, Status Hero, Jira, Asana, Google, Confluence, and Slack. All of these tools can help you organize your remote team.

In addition, every tool in this article can be integrated with Status Hero. As mentioned previously, Status Hero reduces the number of meetings by prompting teammates asynchronously for daily check-ins. By integrating various tools, you can automatically get a high-level view of what each team member has done.

Publishing high-quality technical content and getting it in front of your target audience is just the start of a successful developer marketing effort. Having a compelling lead magnet can help you turn that anonymous traffic into known names and email addresses that you can continue to build a relationship with over time.

Our compilation ebook offering at Draft.dev is designed for companies that want to create a high-quality lead magnet quickly without the cost of commissioning one from scratch.

How it Works

After you meet with our editorial team, we’ll take 2-4 of your existing blog posts (either pieces we wrote or content your team created previously) and re-edit them into a single cohesive work. We’ll include a cover (based on a stock image), custom colors, and any relevant screenshots or graphics from the original content.

Once we finish the re-edit, we’ll send it to your team for revisions or approval. While heavy revisions aren’t typically needed since we’re using existing content, we’re happy to include two rounds of revisions in the standard price.

What’s Included in Draft.dev’s Ebook Service?

• Re-editing and restructuring of 2-4 blog posts into unified content
• Professional cover design with stock imagery
• Custom color scheme matching your brand
• Logo placement and basic branding
• Formatting of existing screenshots and graphics
• Two rounds of revisions
• Final delivery in PDF format 1-2 week turnaround after content selection

FAQs

What if we have custom fonts or a style guide?

We offer custom colors and can include your logo on the cover, but if you want more sophisticated design work, we’re happy to share the content with your design team so they can customize it further.

How long does it take?

This process generally takes just 1-2 weeks after the original content is written.

Can I order an ebook alone?

While we don’t offer one-off ebook production at this time, ebooks can be rolled into an existing technical content plan or as part of a statement of work for a new client.

Do you have any examples of this kind of compilation ebook?

Sure! This ebook for Backhub is a good example of our work.

To discuss our packages and pricing, please book a call with us here.

What if we don’t already have content to turn into an ebook?

We’d be happy to help you produce a series of blog posts that will make a good compilation ebook. We produce hundreds of pieces of content for developer tools companies every month, so we’re happy to help with content production as well.

Next Steps

To discuss our packages and pricing, please book a call with us here.

And, if you need a custom whitepaper or ebook that’s beyond our offerings, we’re happy to refer you to one of our recommended partners.

Let me be honest, I don’t like the term, “Thought Leadership.” It’s too vague. Marketing people often apply it to writing that is neither thoughtful nor leading anything.

For example, a lot of people refer to high-level, informational writing (like this overview of Docker Networking we wrote for a client) as “thought leadership.”

While the piece above is excellent, it’s not really conveying leadership. It doesn’t have a strong point of view, and it’s not borne out of a unique perspective on the state of DevOps. It’s just really deep, helpful information on a highly technical topic. Great stuff, but not “thought leadership.”

So, what is true “thought leadership?” And how do you write effective technical thought leadership content?

In this piece, I’ll offer my perspective. As a former CTO turned writer, I’ve written a fair bit of technical thought leadership, but I’m also an avid reader of the stuff. After sharing some examples of technical solid thought leadership, I’ll offer a few tips for writing your perspectives in a way that is both thoughtful and persuasive.

Examples of Technical Thought Leadership

Good thought leadership blends your unique experience and expertise with writing that’s compelling to readers.

For technical thought leadership, that means you showcase an understanding of a specific technical subject while either making your case or showing something you’ve learned.

I’ve noticed three broad categories of technical thought leadership:

1. Taking a Controversial Stand

Not every “hot take” on the internet is thought leadership, but some of them are. You are taking a risk by taking a hard stance on a somewhat contentious issue, but you’re also more likely to generate some buzz.

Some examples include:

• Is it OK to change code for the sake of testing?

• Starting a business around GPT-3 is a Bad Idea

• The bulk of software engineering is just plumbing

In these examples, the writer combined industry and technology knowledge with a hard stance that isn’t universally held. Ultimately, they each make a good argument, whether you end up agreeing with the author or not.

2. Sharing a Unique Point of View

Another way to demonstrate thought leadership is by sharing a unique point of view or insight into something you’ve learned. I like these when they go deep into something I didn’t even know I cared about (like in the 32 bit real estate piece below):

• ​32 Bit Real Estate

• No code reviews by default

• A Day in the Life of an Engineering Manager

These informative articles usually showcase the writer’s expertise to build trust while giving readers insight into their point of view. They’re often popular with others who have experienced similar things but may not have had the skill or time to write them down. For example, my “Day in the Life of an Engineering Manager” piece above made the rounds on Reddit and Hacker News with lots of head nods from other engineering managers.

3. Predicting the Future

Finally, a lot of thought leadership is directed towards the future. Engineering leaders at large companies, consultants, and visionary startup founders often present these kinds of pieces as a way of swaying readers towards their worldview.

• The Future of AI: How Artificial Intelligence Will Change the World

• The Modern Data Experience

Sometimes these pieces are controversial, but they often look far enough into the future that nobody will remember if the author was wrong anyway.

How to Write Technical Thought Leadership Well

With a sense of the various types of technical thought leadership writing out there, I’d like to give you a starting point for creating compelling content like this. Besides getting some of the fundamentals of technical content down, there are a few extra things you can work on to make your thought leadership stand out.

Experience

This might be obvious, but your writing will always be more compelling when you pick a topic you have experience in.

I’m not saying freelance writers can’t write decent thought leadership content, but if you don’t have personal experience, you need to get sources and be ready to dive deep into this topic.

With technical thought leadership, this is especially important. Who wants to read a piece about the future of edge hosting by someone who’s never used deployed something to it before? If your audience is experienced technical leaders, you need to have the experience to back your writing up.

Up-to-Date Knowledge

Technical fields change quickly, so check out the existing content on the topic before you start writing. Books, blog posts, and industry news can all help you understand more of the context surrounding your observations and help you create more complete arguments.

Support a Single Thesis

With experience and knowledge in place, you want to write your whole piece with a single thesis in mind. Many attempts at thought leadership turn into scattered rants that ramble through seemingly unrelated ideas as they go through the author’s head.

Take a single strong stance on each piece. Make sure everything you write supports that stance.

Supplement Opinions

“In the hands of a good writer, data-heavy content is both informational and fun. Research skills are just as important as creativity — together, they make all of your content attractive and engaging.” – Duke Vukadinovic, FirstSiteGuide.com

A lot of the thin thought leadership content is pure conjecture. The author may have personal experience, but it’s tough to take them seriously if they don’t back it up with data, quotes, logical arguments, or respect for the other side.

I have started interviewing a few sources for most thought leadership pieces I write. This almost always results in more robust ideas as I end up collecting multiple points of view that might vary from my own.

In persuasive writing, be sure to refute yourself then resolve the argument. By pointing out that the other side is somewhat valid, you gain credibility with those on the fence.

Craft Strong Conclusions

Last but not least, you need a solid conclusion to drive your technical thought leadership home. In some cases, this could be a call to action or encouragement for readers to consider this topic more independently. In others, it could be an invitation for rebuttals.

Ideally, you want people coming away from thought leadership pieces with a new perspective on the topic at hand.

There’s No Substitute for Experience and Time

While you can research a topic, interview experts, and sink a lot of time into thought leadership pieces, I’ve found there is no substitute for real-world experience. Suppose you’re an executive spending hundreds of hours per month thinking about a topic. In that case, you’re inevitably going to have better opinions about it than someone who just picked up a cursory understanding last week.

If you find yourself struggling to write thought leadership content, you might just need more time to think. I’ve used various tactics to make time for organizing my thoughts, and I find this to be a great time to formulate opinions and arguments that might make good thought leadership someday.

Finally, if writing skill is your blocker, you don’t have to use this medium. Video, audio, presentation, etc., can all be good ways to get your thought leadership out there. While written communication is essential, it’s not the only way to get your point across.

Once you embark on the journey of technical writing, you will discover a few different types of articles. Tutorials, comparisons, roundups, and guides. These all serve a different purpose, and your angle will be slightly different depending on which type you are writing. When writing a technical guide, you need to make sure that you are hitting the right mark and that it makes sense to write a guide instead of a tutorial.

In this article, you will be shown what it means to write a technical guide, why you would want to do so, and you’ll be given some tips on how to make great ones.

Why Write Technical Guides?

The first question you always need to ask yourself is why. Why do you want to write technical guides? Below are a few reasons for it.

1. SEO (Search Engine Optimization)

The first reason for writing technical guides is shared among many different types of articles, and it is, of course, SEO. By writing technical guides, you have the opportunity to include specific keywords, which can be a great way of getting ranked higher on search engines like Google.

Besides using keywords, you can use guides as umbrella articles for other articles on your blog. For example, if you create a guide on how to get started with your product, you can link to specific tutorials on each subject. This will keep the reader contained within your blog and increase traffic on your site.

2. Hitting Your Target Audience

Sometimes you are lucky that your target audience quickly picks up on what you are doing, and you don’t need to explain anything to them. This, however, is not the case for most companies. Usually, you need to make your audience understand why they should listen to you.

By making high-level guides, you are introducing people to your product in an easily digestible manner. It’s uncommon that anyone would sit and read a tutorial for a product they are only considering using. It’s even more uncommon if they don’t even consider using your product. When you produce entry-level technical guides, you allow your audience to digest your product without them feeling like they are doing a deep dive into the mechanics of it all.

3. Spread Knowledge of Your Product

Of course, technical guides do not only have to be entry-level. There’s a definite value in making more complex guides, like how your product integrates with other products and concepts that are only relevant to those already working with your product. This can be very valuable, as it again introduces your audience to something in a digestible manner. Many prefer to read a well-written guide rather than sifting through documentation.

4. Let People Get Started Quicker

This last point is somewhat of a combination of the previous two. By writing technical guides, you let people get started with your product quicker than if they had to figure everything out independently. You may think, “Well, that’s why we have documentation,” and while that is correct, the documentation doesn’t serve the same purpose as guides.

Your guides should be written with a clear goal. “Getting started with X using Y.” This allows readers to find a complete overview of what they need. Documentation will usually include more technical explanations, specific implementations and is generally written much more technically than a guide. A guide leads the reader down one particular path, rather than covering many different scenarios, like documentation typically would.

Tips for Writing Great Technical Tutorials

So, you know why you want to start writing technical guides. Now you need to know the building blocks of great articles.

1. Know Your Audience

Like SEO, this is a point shared among many different types of articles, but that is only because of how important it is. Without knowing your audience, you are writing blind. In the context of content marketing, it’s the equivalent of having the dart arrow without knowing where the dartboard is.

Determining the audience helps you keep a thread throughout your article, and it helps keep you in line. If your guide is aimed at experienced developers, you can use industry terms to describe certain things. If your guide is aimed towards a general audience, you know that you need to keep industry terms to a minimum.

2. Focus on the “Why”

Many writers miss, especially when first starting, that they only explain how things are done. While this can, without a doubt, be beneficial, it doesn’t teach the reader very much. The reader might come away with an explanation of the issue at hand, but they still won’t know why they had the problem in the first place.

Maybe your guide isn’t trying to solve an issue. Perhaps it’s a guide on how to get started. In this case, you must hammer home why the reader needs to use your product. Answering the why, even if the reader hasn’t asked it, will generally always lead to a better article. Not only because there’s more substance, but because you as the writer will have to think about the subject more.

3. Having a Clear Goal

Like with the audience, you also need to set a clear goal for the guide. This will help you keep a common thread throughout the article, eventually leading to a better article. Writing a guide that jumps from point a to point c to point b can have valuable insights, but it will be a mess to read. By aligning the article with a clear goal, you can set a direction and make sure the contents are digestible.

4. Keep it High-Level

The last thing to keep in mind is that you are writing a guide and not a tutorial. Keeping it high-level doesn’t mean you can’t mention specific implementation steps or include code snippets. It means that you shouldn’t be including step-by-step instructions on how to get something working.

This is something that should be built into the goal you set. Most of the time, your goal will be something along the lines of helping the reader get introduced to a subject, more so than helping the reader get something implemented.

Conclusion

Now you know more about what it means to write a technical guide compared to writing a technical tutorial or roundup. It’s a matter of making sure the content is digestible and is open to new members of the audience you are targeting.

On top of that, you’ve got an insight into how you can build a fantastic guide, like setting a goal and focusing on the “why.”

Want to write for Draft.dev?Click here to learn more and apply today.

On the other hand, if you need help writing technical guides, or if you’d like to work with our team of writers to build content that reaches software engineers, contact us today

Most of the developer tools companies we work with generate the bulk of their traffic from two sources:

• Search engines – By targeting the right keywords, you can systematically build a content machine that generates consistent traffic, but it typically takes 6-12 months to see results.
• Social media – If you’ve built a large following of customers and fans already, you can leverage this audience to generate traffic faster but less predictably.

While the most successful companies we work with employ both strategies for each piece of content they publish, I realized that many of our clients were completely neglecting social media.

So, last month, we officially added social media collateral to our service offering. To learn more, book a call with me, or keep reading to get an overview of our service upgrade.

Social Media Marketing for Developers

I spoke to several clients over the past year about how they use social media to promote their content. While a few were effectively using it, the majority did very little to promote their content on social media.

When I dug into this, the most common objection I heard was, “We aren’t sure what will resonate with developers on social media, so we avoided it.” There are really two components to this objection, so let’s dig into this a bit more:

1. Where Do I Post This Content?

The first roadblock our clients had about promoting their blog posts and technical content on social media was that they weren’t sure where to post it.

Twitter? Our company account? Our developers’ accounts? Reddit? Facebook?

If you’ve been in marketing for long, you know that developer marketing is tricky. They have their own niche communities, such as Reddit, Stack Overflow, and Hacker News, that are rarely used by other demographics.

Additionally, some of these communities are rather insular.

Reddit remains a bit of a mystery for most, including most corporates looking to tap into what makes stuff go ‘viral’ on this network…What you get is a potpourri of the web’s most interesting, weird and controversial content. – Business Today

Still, Reddit and Hacker News are powerful traffic generators if you know how to use them. This is where having our industry expertise can help.

2. What Should We Say?

The second problem was that many of our clients weren’t sure how to talk about the topics we cover in a way that would be authentic and resonate with software developers.

Some of our clients don’t have the technical expertise to write social media content for these topics, and even those who do rarely have time to sit down and think about five or six different social updates for each post across multiple channels.

We also find that some of the pieces we write for clients are rather difficult to write social collateral for. If you’ve never used an API to build a Slack Bot, how would you talk about this kind of tutorial on social media? What snippets are worth extracting and sharing?

Again, having subject matter experts who can guide you is the key. If your developers can do it, great, but if they don’t have time, we’re here to help.

Our Offering: Social Media Collateral for Technical Content

To solve both of the above problems, we’re now including social media collateral in our service offering.

For each article that we write, Draft.dev will provide clients with:

• Social media posts that you can schedule on your company Twitter and Linkedin accounts
• Subreddit suggestions and headlines for Reddit
• A Hacker News submission
• A detailed promotional checklist

The idea here is that your non-technical marketing associates can use these updates to help get your content out there. While making an article go viral on Hacker News is not guaranteed, you have to plant the seed if you want any shot at your content taking off.

Does Social Media Work?

We’ve already seen good results using this strategy for our own content at Draft.dev. While Google search traffic is our largest traffic driver, Twitter and Reddit rank just behind it for our developer-focused content.

The truth is that social media can work for developer marketing, but like all forms of B2D (business-to-developer) marketing, you have to know your audience and be genuinely helpful in your approach. Having great content written by subject matter experts is a start, but we’ve spent years learning how to communicate with and grow developer audiences on social media.

Learn More

Having Draft.dev’s keyword research, technical blog posts, and social media collateral is a great way to kickstart or augment your technical content marketing efforts. To learn more, book a call with us today.

When I started Draft.dev, I wanted us to consistently deliver high-quality technical content to satisfied clients around the world. Creating quality technical content requires a deep understanding of the subject matter, as well as the ability to clearly communicate complex ideas. One of the keys to creating effective technical content is to focus on the right topics and keywords that are most relevant to your audience.

Draft.dev provides content strategy services like SEO keyword research and topic cluster generation to our clients to ensure their target audience is engaged with our technical content. In this post, we will explore the concept of topic clusters and how we identify the right topics and keywords for our clients’ technical content. If you have questions, feel free to book a call with me.

What Are “Topic Clusters”?

First, if you’re not an SEO expert, you might not be familiar with the term. A “topic cluster” is a method for intentionally building content designed to rank well in search engines (especially Google).

The idea is that by writing several pieces of content that are related, you can develop a really valuable “pillar piece” supported by a handful of “supporting pieces.” By targeting keywords that have relatively low keyword difficulty and decent volume, you can ensure that some of your supporting pieces rank on the first page of search results quickly.

Then, by linking from those highly-ranked supporting pieces to the more difficult-to-rank pillar piece, you increase its rank as well. The goal is to eventually start ranking highly valuable, high search volume pillar pieces on the first page of Google results.

In this post, I’ll walk you through how we do this at Draft.dev so you can try this for yourself or better understand what you’ll get when you work with us. I’ve also recorded a video version so you can follow along with a real example if you’d like.

Finding Keywords

Writing blog posts that are likely to rank well in Google is a complex process that I won’t dive into here, but I will say that the process always starts with picking the right topics to write about.

The first thing we do is sit down with each client to build a list of ideal keywords. We ask a few questions that usually lead us to uncover lots of areas for exploration, including:

• What would be your dream keywords to rank #1 for? These should be 1-2 word, industry descriptions like “continuous integration,” “automated testing,” or “python IDE.”
• What work are engineers doing when they decide to use your product? What problems might they encounter leading up to that decision?
• What tools would an engineer use alongside your product? Are there specific languages or frameworks they need to use?
• What long-tail searches would you like to rank highly for? (e.g., “how to automate GitHub backups” or “how to pick the right database”)
• Who are some of your direct competitors?

After this planning session, we usually have a list of 10-50 keywords. We then take this list and start exploring. Using tools like ahrefs, Google Keyword Planner, and industry research tools, we then generate thousands of keywords to explore in more detail.

This is where the science and art of keyword research come in.

Ahrefs will give us estimated monthly search volume and difficulty, but it doesn’t necessarily tell us the user’s search intent or how relevant each keyword is for our client. For that, we use our industry knowledge, competitor research, and past experience to cull the list down to a few hundred relevant, rankable keywords.

Planning Clusters

After building this list of relevant keywords that are not overly saturated, we start to comb through them manually, grouping similar ideas and terms into groups. Again, this is part art and part science because you have to understand a lot of industry jargon to do this well.

This is also where specializing in content for software developers gives us a huge leg up on general-purpose SEO consultants. The topic clusters we build are based on a deep understanding of how software engineers and engineering leaders use the internet to solve problems on a daily basis.

Usually, we can build 2-3 topic clusters with a pillar piece and 4-6 supporting pieces in a single round. If we can’t, we go back to the previous step and brainstorm more keywords to find another unexplored niche.

The Final Result

At the end of this process, we supply clients with a simple, easy-to-understand map of our results in a spreadsheet. We’ll review each article with our client and make sure they align with the client’s product and strategy before creating detailed content briefs and outlines.

Sometimes this requires a couple of iterations, but it’s usually a quick process, about one week within our client onboarding timeline.

Once we’ve agreed on topics, briefs, and content types, we’ll start production. With 300+ technical writers in our pool, we can cover almost any software development topic, and we’re always willing to recruit specialists when the project calls for it.

Are Draft.dev’s Topic Clusters Right for You?

Using keyword-based topic clusters like this isn’t suitable in every situation. For example, if you’re hoping to create content as sales collateral, helping your sales team move prospects down the funnel, you might not care so much about search volume or ranking in Google. Similarly, if you’re primarily interested in content that will resonate on social media, we provide community research to create a content plan for our clients.

On the other hand, if you’re hoping to build awareness, generate new leads, or build up your domain authority to make ranking for more difficult topics easier in the future, this strategy is a perfect fit.

By focusing on keywords you can rank for within a few weeks, you won’t have to wait years to see a return on investment for your content. You can attract buyers at the top and middle of your funnel to raise awareness and introduce your solution. Then, by retargeting them with ads or introducing them to your mailing list, you can build a content engine that delivers consistent growth for years to come.

At Draft.dev, we help Developer Platforms & Tools build growth engines that compound and resonate with developers, search engines and LLMs. Our work has generated hundreds of thousands of leads for our clients, helping them rank high on traditional search engines, being mentioned in AI search engines, and getting click-throughs to their lead magnets. To learn more, ask questions, or get started, book a call with us today

With a growing number of writers around the world and a growing roster of clients who rely on us for top-notch technical content, one of the challenges we face is making sure each assignment gets matched to the best technical writer possible. In this blog post, I’ll outline our approach, which we share with writers and clients when they ask about this topic.

About Our Writers

First, if you’re not familiar with Draft.dev, we write technical content (tutorials, guides, comparisons, etc.) aimed at software engineers, data engineers, and technology leaders. Because our content is so technical, we don’t work with typical freelance writers – almost all our writers are practicing software engineers or managers.

Since almost all of our writers have a day job, their capacity is limited. Most contribute 1-2 articles per month, so while some are matched up to the same client consistently for an extended period, many work with several clients per year. This means that we spend a fair bit of time finding the best writer for each article we commit to.

Our Process

Our writers are busy professionals, so we give them as much autonomy as possible regarding the topics they want to write and when they want to write them. On the other hand, we want to make our clients happy and produce outstanding content for them on a predetermined schedule.

So, our process works like this:

1. Weekly Email to Writers

Each week, we send an email to our writers with all the topics we currently need a writer for. We work with clients to determine these topics when they sign on with us, so while writers don’t typically get to “pitch” topics, they have no obligation to take on a topic they don’t know well.

PS: If you’d like to apply to write for Draft.dev, here’s the application form.

2. Gathering Replies

Next, we wait a few days for our writers to read and reply to the email. Then, we create a list of writers who replied and which topics they are interested in. Some writers prefer to work exclusively on topics they already know well, while others take writing as an opportunity to learn new things. Either approach is fine so long as they are realistic about their ability to write on the topic with authority.

3. Matching Writers to Articles

This is where it gets a little fuzzy, and I’ll admit, sometimes challenging. Our goal is to fairly spread assignments out to our writers while ensuring that each writer has the skills to complete the article.

So here’s what we look at:

1. Proven knowledge of the topic – We look at each writer’s past work with us, their writing samples, and their work experience on Linkedin or GitHub to see if they have the technical skills needed for this article.
2. Proven ability for this type of writing – Writing a tutorial is very different from writing a good technical roundup, and that’s very different from a high-level guide.
3. The writer’s current work queue – We rarely give writers more than one assignment at a time because we don’t want to overwhelm them. Most articles require some revisions, so we don’t want writers to overcommit and be unable to handle revision requests promptly.
4. Is this a new writer? – We only accept a few applicants every month, but we try to give new writers a chance to prove themselves within their first few weeks. At the same time, we don’t want to give them an assignment that is out of their depth, so we may reserve some “easier” pieces for new applicants.
5. When was their last article? – As I mentioned above, we try to spread the work around, so if a writer hasn’t gotten an article in a month or two, we might give them a slight priority over a writer who’s just had a couple of pieces recently. This helps everyone get a fair shot and helps us maintain a diverse writer pool.
6. Speed to respond – Finally, if a writer takes 3 or 4 days to respond to our weekly email, it’s likely many of the pieces will already have been matched off.

4. Handling Unmatched Assignments

If, at the end of the matching process, we couldn’t find an interested writer for a particular article, we have a couple of options.

First, we might look through our list of writers and reach out to any with the requisite skills. Maybe they’re interested but can’t start this week? Or perhaps they missed the email? We usually build enough flexibility into our deadlines to accommodate small adjustments for the right writer.

Second, we actively recruit writers with specific skills. Typically, when a new client signs on, we’ll look at our existing writers and any who have applied to make sure we have enough people on board to handle the new work. But, some topics are just hard to find qualified writers for, so we spend time every week actively reaching out to engineers outside our network who might have the skills to write these hard-to-match pieces.

While this process is likely to change as we grow, our philosophy is likely to remain the same. We want to provide engineers with great opportunities to showcase their expertise while giving our clients the best technical content possible.

What Can Our Writers Who Want More Work Do?

Sometimes writers ask me what they can do if they want more writing work with Draft.dev. While all our writers today are independent contractors and we can’t guarantee a specific number of articles, here’s what I tell them:

Do Your Best on Every Article

Delivering your work on time, consistently, and at high quality is the #1 thing writers can do to improve their chances of getting more work. Writers who follow our style guide, self-edit, follow the outlines and briefs, return assignments on time, and respond to revisions promptly will almost always get more assignments in the future.

Conversely, if you agree to write an article about a topic you don’t know, and it goes poorly, you may not be considered for future work at all. When issues come up, or you realize an article is out of your depth, let us know as soon as possible so we can find another author.

Be Flexible

If you want more work and you’re willing to learn some new skills or research a complex topic, let us know. While some articles require previous experience, we give writers a shot at new topics if they’ve proven they can do good work on well-known concepts in the past.

More Articles are Just a Week Away

Finally, we have new topics prepared every week. As they come in, we continue to send out emails to writers, so some weeks might have many options, and others might not. Just keep an eye on your inbox!

Interested in writing for Draft.dev? Click here to learn more and apply today.

Want access to our fantastic pool of writers? Schedule a call to learn more about what we do.

As your blog grows and you get more writers to contribute, you need to build documents and processes to help you maintain high quality and consistent style. To serve this goal, you should create a style guide to help writers and editors stay on the same page.

What Is a Technical Blogging Style Guide?

Generally, a style guide includes expectations for your contributors. Depending on your priorities, you may include more or less information than we do at Draft.dev, but our style guide should give you an excellent place to start. We send this style guide to all new contributors to ensure they are familiar with our expectations, and we refer to this guide throughout the editing process.

Of course, ours is not the only example of a technical writing style guide. If you’re looking to compare your options, check out Google’s developer documentation style guide, DigitalOcean’s technical writing guidelines, and some of the other guides here. If you’re creating a style guide, I’d recommend reading over several and deciding what you want to include in yours.

The Draft.dev Technical Blogging Style Guide

At Draft.dev, we specialize in creating technical blog content for companies that want to reach software engineers. While most of our writers are software engineers first and authors second, we still expect them to follow consistent standards for each of our clients.

Below is our style guide, which is broken up into four sections:

1. Voice
2. Content
3. Conventions
4. Communication

How Should You Write Technical Content?

Write in Second Person

Speak to your readers directly using “you” and “your.” Avoid “we” and “our.”

Good:

You can use a web browser (like Chrome, Safari, or Edge) to access web sites on the internet.

Bad:

We can use our web browsers (like Chrome, Safari, or Edge) to access web sites on the internet.

Use Conversational, Business-Appropriate Language

Read your article out loud and ask yourself, “Would I talk like this at work?” Use your real-world experience, but avoid jargon when possible.

Good:

Experts agree that the internet was not the product of any individual mind, but a series of advances in networking and computer science.

Bad:

Many scholars would agree that, had it not been for active networks, the simulation of Lamport clocks might never have occurred. The notion that end-users synchronize with the investigation of Markov models is rarely outdated. A theoretical grand challenge in theory is the important unification of virtual machines and real-time theory. To what extent can web browsers be constructed to achieve this purpose?

Don’t Repeat Yourself

Eliminate wordiness. You shouldn’t repeat yourself when programming, and you shouldn’t repeat yourself when writing.

Good:

A lively debate rages among software developers. The contentious issue is: tabs or spaces?

Bad:

There is currently a lively, ongoing controversy among many computer scientists and other professional in the field of software development: theories are being spun and arguments are being conducted among them about whether the use of tabs to designate indentation in a document is superior to the use of spaces for the same purpose.

Avoiding Gatekeeping in Technical Writing

Write for an international audience of developers from a wide range of backgrounds, races, ethnicities, cultures, and experience levels. To that end, avoid language that is exclusionary or encourages “gatekeeping.”

Good:

Fork the main branch and make the appropriate changes.

Bad:

Obviously, you simply fork the master branch before making the appropriate changes.

Use the OpenGates Checklist here to ensure you’re not writing in a way that excludes others.

What Content Standards Should Technical Blogs Follow?

How Do You Write Effective Technical Introductions?

Every article should have a 1-3 paragraph introduction. A good intro needs to answer a few questions right away:

• What’s the pain point I’m addressing here? How do I hook my readers? 
• What’s the solution to this problem?
• What am I going to do in this article?

Make sure your introduction is completed by letting the user know how you’re going to teach them to solve this pain point.

How Should You Support Claims in Technical Writing?

For every claim you make, ask yourself, “How can I prove this?” You can do this by:

• Including a link to a reputable article
• Including a quote from another source
• Citing an academic study
• Linking to the official documentation
• Interviewing knowledgeable professionals

Good:

While [Postgres can handle hundreds of columns](https://nerderati.com/2017/01/03/postgresql-tables-can-have-at-most-1600-columns/), it might not be a good idea to take advantage of this feature.

Bad:

While I’m guessing Postgres can handle a lot of columns, it might not be a good idea to use more than a hundred if you can help it.

What Are the Rules for Citations and Copyright?

Written content that is copied directly from another source must be quoted and cited appropriately. Switching out a few words in a sentence is not enough to make the content original, so be sure to put everything in your own words.

Bad:

I’ve always thought that measuring programming progress by lines of code is akin to measuring aircraft building progress by measuring weight.

Good:

“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” – Bill Gates

The bar for using images is even higher. You may not use images from another website unless they expressly allow it. If you need stock images, use a site like Unsplash or one of the options here.

How Do You Write a Strong Technical Conclusion?

Every article should include a 1-2 paragraph conclusion. This should restate the thesis of the article and remind readers what they learned. It may also include other resources readers can reference to learn more.

Good:

While JSON data types come with some drawbacks, they are useful when you need more flexibility in your data structure. Thanks to Django’s native support for `jsonb`, you can get started using JSON data in your web applications without [learning all the native Postgres query operators](https://www.postgresql.org/docs/current/functions-json.html).

Next time you need more flexibility in your data model and want to benefit from the strengths of Postgres give `jsonb` fields a try.

What Formatting Conventions Do Technical Blogs Use?

Why Write Technical Content in Markdown?

All articles should be written in Markdown and submitted in the Google Doc sent to you when you accept the assignment.

Good:

Markdown is a formatting language often *used by static site generators* and *blogs*. If you aren’t familiar with its syntax, you can [click here to learn more](https://guides.github.com/features/mastering-markdown/).

How Should You Handle Screenshots and Diagrams?

If you need to circle something or add some text to a screenshot, please provide a screenshot annotated to the best of your ability, as well as an unmarked copy of the screenshot. This empowers our clients to redesign them according to their own branding if desired.

If you don’t already have a preference, we suggest using any of the following tools:

• dbdiagram.io
• Excalidraw
• Google Drawings
• Mermaid-JS
• Lucidchart

These are also all great options for any rough architectural diagrams you may need to make.

If you have screenshots or diagrams in your article, upload them to Imgur’s free image hosting service and embed them using Markdown. Include descriptive text inside the brackets ([...]) so that screen readers can describe the image.

Good:


Bad:


How Do You Structure Headers in Technical Posts?

Headers make your content more scannable. Use ##, ###, and #### header tags to denote different sections. Headings should be written in title case.

Good:

## How to Use JSON Fields in Your Python Application

…

### The Two JSON Formats Supported by Postgres

…

Bad (not title case):

## How to use JSON fields in your Python application

…

The two JSON formats supported by Postgres

…

When Should You Use Code Blocks vs Inline Code?

Use code blocks when the code is one or more lines long or deserves special emphasis.

Good:

“`

function snafu() {

return null;

}

“`

Bad:

`function snafu() {

return null;

}`

Use inline code when referring to a variable name or short command in context.

Good:

Call the `snafu()` method to exit and return to your command line.

Bad:

Call the “snafu()” method to exit and return to your command line.

How Do You Format Quotes in Technical Writing?

Use blockquotes when the quote is two or more lines long.

Good:

Some text leading up to the quote.

> “The field/element/path extraction operators return NULL, rather than failing, if the JSON input does not have the right structure to match the request; for example if no such key or array element exists.”

Some text after the quote.

Bad:

Some text leading up to the quote. “The field/element/path extraction operators return NULL, rather than failing, if the JSON input does not have the right structure to match the request; for example if no such key or array element exists.” Some text after the quote.

Use inline quotes when the quote is relatively short or when you’re referencing a single word or phrase.

Good:

“There’s nothing to see here,” said Davies.

Bad:

> “There’s nothing to see here.” – Davies

Use Emphasis Sparingly

Use italics to emphasize text or use bold to suggest strong emphasis.

Good:

There is *nothing* as important as using **spaces** to indent your code.

How Should Writers and Editors Communicate?

What Should You Do When You Miss a Deadline?

You will not be penalized for late work if you’ve been in communication with us about the assignment. We can offer technical help and extensions, but you must ask two or more days before the due date.

Good:

Hey Karl,

I know the Postgres article is due next week, but I’m running into trouble. Would you be willing to hop on a quick call and explain the JSON fields in Postgres? Or do you have any resources that might help me out?

Bad:

Hey Karl,

I know my Postgres article was due today, but I’m not able to figure out the JSON fields in Postgres. Could I have an extension until next week to struggle with it more?

Authors that miss deadlines without communicating will not be eligible for future assignments.

How Quickly Should You Respond to Editorial Feedback?

While you have an open assignment, you should respond to emails within 48 hours unless you’ve notified us of your unavailability. If the assignment is overdue, you should respond within 24 hours.

Good:

Hey Karl,

Thanks for the update on this article. I’ll keep that in mind while I’m working on the piece this weekend.

Bad:

Hey Karl,

Sorry, but I didn’t see your email until today and I know the article is due now. I’ll try to incorporate your feedback before midnight if I can.

Authors that fail to respond to emails about open assignments will not be eligible for future assignments.

How Do You Implement a Style Guide for Your Blog?

Creating high-quality technical content requires consistency and clear expectations. While having a style guide may not be necessary during your blog’s early days, it’s an invaluable asset as you grow.

If you’d like to talk about creating content for your blog, you can schedule a call with us..

Hiring is always hard, but the more specialized your hire is, the harder it will be to fulfill. If you’re managing a technical blog and you want to stop writing everything yourself, you’ll need to recruit and hire technical writers to help you out.

While traditionally used in education, rubrics are a fantastic tool for hiring, and I’ve used them for years both as an engineering manager and content manager at Draft. Whether you are bringing on a part-time freelancer or a full-time hire, having a good rubric for content will help you objectively evaluate candidates and keep you focused on the criteria that matter for your job.

What is a Technical Hiring Rubric?

A technical hiring rubric is a document that defines the criteria you use to decide whether a candidate is a good fit for your role or not. It typically includes several attributes upon which you will evaluate candidates and a few levels within each attribute that measure their skill.

Why Should You Use a Rubric to Hire Technical Writers?

Rubrics let writers gain a better understanding of what you’re looking for in a hire. Providing your writing process rubric up-front allows writers to become intimately familiar with your expectations and needs – encouraging them to rise to the challenge. In some cases, writers may even self-screen themselves, which gives you the greatest amount of qualification during the hiring process.

To effectively use a rubric, you need to apply it consistently using measurable and observable behaviors. This means that a good rubric eliminates hiring by “gut feel” and forces you to stay focused on the characteristics that candidates display throughout the hiring process.

The Draft.dev Technical Writing Rubric

As I started hiring more writers for Draft.dev, I began refining a rubric that would allow me to evaluate them quickly and objectively. Today, I’m sharing this rubric with you so you can use it as a starting point for creating your own hiring rubric.

Our rubric currently has ten attributes that fall within three broad categories. Each of these attributes has 3-4 levels we can use to compare writers. We use this rubric to decide which candidates to bring on during the hiring process and as an ongoing evaluation tool for our existing writers. This strategy helps us consistently provide high-quality technical work for our clients.

You can get a copy of the rubric here or read on for an explanation of how we evaluate writers using this rubric.

How to Write a Rubric

Rubrics are designed to make life easier (and far more efficient). At Draft.dev, we believe in cutting the guesswork right from the get-go with blueprints designed for accessibility and success. Here’s how to write a rubric for writers based on our starting template.

How Do You Evaluate Writing Skills in Technical Writers?

Writing skills are necessary for the kind of work we do at Draft.dev, but defining what it means to be a “good” writer is surprisingly hard. Many people use the, “I know it when I see it” test, but I’ve found that insufficient. There are three attributes I look for in strong writers.

What Writing Conventions Should Technical Writers Master?

Grammar and spelling errors can be overcome. With tools like Grammarly, we can edit a writer with decent conventions, but submitting samples full of mistakes points to a problem with attention to detail. Every writer makes mistakes, but that doesn’t forgive sloppiness.

Writers who have mastered conventions will submit error-free work and may even spot mistakes in others’ work during the application process.

How Do You Assess Language Quality in Technical Writing?

English is a tough language to master. As such, many non-native writers will struggle to word things in a way that native readers find natural. For example, the phrase, “Let me explain you the reasons I believe this to be true,” is missing a preposition and somewhat strangely worded. It’s not glaringly incorrect, but it shows a deficiency in language that is common among inexperienced writers.

Writers who have strong language skills use engaging words, varied sentence structure, and stylistically sophisticated vocabulary that isn’t overly wordy. It’s tough to do.

What Makes Technical Content Well-Organized?

Finally, great writers have to be great organizers. While having good content briefs with outlines can help with higher-level structure, the writer will still have to decide how to present sequential information in a way that readers can grok.

To reach the highest level in this attribute, writers must create clear transitions between topics and consistent focus throughout the entire sample piece.

How Do You Measure Expertise in Writers?

As a technical content agency, Draft.dev’s writers must have specialized experience. While not every piece we produce requires deep knowledge about a specific technical topic, writers must research, understand, and speak to technical topics.

How Should Technical Writers Develop and Present Ideas?

In this context, “development” doesn’t mean software development skills – it means the ability to develop and present an idea. A well-developed piece of writing goes beyond the step-by-step “how” and builds the “why” as well.

A writer who can present their main idea and strongly support it with technical evidence while keeping the “why” central to the work will get full points in this category.

What Is Technical Depth in Writing?

Technical depth describes the writer’s ability to go beyond entry-level writing on the topic at hand. Regurgitation of the “getting started” walkthrough is not that useful for the writing we do with our clients. Writers need to show that they understand the underlying technical justification for their decisions.

Writers who display depth of knowledge usually have years of real-world experience and knowledge of the technology’s inner-workings.

How Do You Match Writer Skills With Client Demand?

Technical knowledge is spiky. A writer may know a lot about Rust, but nothing about Python, so while they can display depth by diving into the Rust compiler, if none of our clients need Rust writers, their skills aren’t in demand right now. While technical writers usually have two or three areas where they can contribute, their skills have to match up with our clients’ needs to be a good fit.

Writers with unique combinations of skills or experience that happens to match our clients’ technology stack will do the best in this category.

How Do You Verify Technical Correctness in Content?

Finally, writers must be technically correct. This is usually linked closely to depth – if a writer can’t go deep on a topic, they are less likely to get the details right – but not always. For example, a writer might create some sample code that doesn’t work even though their explanations are on-point.

Writers will get the most credit in this category when they have no factual errors, and all their assumptions are backed up with evidence or experience.

What Work Habits Matter Most for Technical Writers?

The last category is work habits. Even great writers who are technically qualified may be a bad fit for Draft.dev if they’re not consistent team players. Each of our writers works remotely as an independent contractor, so their ability to communicate, respond positively to feedback, and work independently are important to their success.

How Should Writers Communicate With Editors?

While writing skills are evaluated in the first category, our writers must also be responsive, prompt communicators. With clients and writers around the world, we don’t have set “working hours,” but we require writers to respond to emails and requests for revisions within a reasonable amount of time.

The best writers proactively notify their editor with questions or delays as early as possible and communicate their progress along the way.

Why Does Attitude Toward Feedback Matter?

As a writer, you have to be able to handle feedback – both positive and negative. Edits aren’t a personal attack, so we look for writers who actively seek out feedback. Great writers at Draft.dev enjoy the guidance we offer rather than seeing it as a burden.

What Does Independence Mean for Remote Technical Writers?

Finally, our technical writers have to be able to solve problems independently. This doesn’t mean they can’t ask questions – they should reach out proactively when stuck – but they should start projects early in case anything comes up.

How Do You Implement a Technical Writing Rubric?

I hope our rubric helps you hire better technical writers, but I also hope it shows you how tough finding great writers can be. If you’re not sure about hiring your own writers, we might be able to help. At Draft.dev, we write technical content for software engineering blogs using our pool of highly skilled technical writers. We also offer content planning and editing services.

If you’d like to learn more read about our process at Draft.dev.

Technical Writing Rubric FAQ

There are two mistakes that most companies make when they decide to pursue technical content marketing:

1. They don’t have a content plan.
2. They don’t know how they’re going to distribute their content.

I recently wrote about how I recommend starting with a checklist to promote your blog posts. While I could say more, I’m going to focus on the first problem: creating a technical content plan.

What is a Content Plan?

Most companies that start a blog have a higher-level strategy. They know why they want to start creating content but rarely dive into the specific article ideas and resources they want to create.

A content plan is a detailed outline of the content you want to produce for your blog.

If you’re building a technical blog aimed at developers, tailor your content plan to fit (1) your audience, (2) your product/service, and (3) your available writing resources.

I’ll add more about how you can create a content plan later, but let’s start by looking at an example:

Here’s the sample content plan I share with my clients at Draft.

Let’s take a look at the first article in the content plan: How to Deploy WordPress to a Kubernetes Cluster.

The Title

While it may change, the working title tells us what each article’s main keywords are and the tone. Articles that start with “How to…” like this one are generally tutorials, but as you’ll see, we clarify that further down in the plan.

The Pitch

Freelance journalists typically write a “pitch” to sell an editor on their idea. The pitch in your content plan accomplishes a similar goal, giving others a high-level view of the article what readers will learn.

Assets Delivered

I like to be clear about what will be entailed in creating each piece of content I write. Include expectations for the article length, type, and supporting data or code samples that will be delivered.

Audience

If your writer assumes the article is directed at entry-level developers, but you meant it to be aimed at managers, you’re not going to be happy with the outcome. Having a clear audience attached to each piece will also help you think about how you’ll promote it after publication.

Outline

Finally, your content plan should include a brief outline. You can let the writer fill in details or adjust it as necessary, but having some detail shows that you’ve thought about the topic and know what it will entail before you pass it off to a writer. If you’re the writer, you really need an outline.

Why Do You Need a Content Plan?

You might think that creating a content plan with detailed pitches and brief outlines for each of your articles will be a considerable time investment…and you’d be right.

The truth is that if you don’t create a plan, your writing will suffer. You’ll get different levels of quality from various writers, you’ll have to return more work for a rewrite, and you won’t be able to let other stakeholders see what your team is working on.

Before I start working with a new client, I create a content plan for the first 3-6 months of our engagement. Having it is a massive benefit for both my clients and me, so while it’s an investment, it’s well worth making.

Here are just a few of the reasons you should create a content plan:

Aligns Content and Strategy

It’s easy to fall into the trap of publishing anything anyone wants to write on the blog. An unfocused approach like this might occasionally result in a home run, but most of your posts will add very little value. By explicitly defining each piece of content you want to create, you can make sure your posts serve your overarching strategy.

Helps Drive the Plan for Promotion

Having a defined audience for each post you write will help your marketing team decide on a promotional plan for each piece. That allows them to do research before the post goes live to give it the best chance of success the moment it’s published.

Enables You to Find the Right Writers

Whether you’ve got dedicated in-house resources or a large pool of community contributors, writers will struggle to come up with good topics consistently. By having a list of content ideas, you can control the content’s quality and topic choice. You can even start targeted outreach to find writers with specific experience for each post.

Minimizes Back-and-Forth

One of the most frustrating things as a writer is having unclear expectations for your work. Imagine spending 5-10 hours writing an in-depth, technical piece and then being told you missed the mark. I’ve done it; it sucks. A content plan will make sure writers don’t waste their time or yours.

How to Create a Content Plan

Once your team agrees that a content plan is necessary, it’s time to get to work. There are three phases to coming up with a content plan:

1. Defining the content strategy
2. Coming up with ideas
3. Research and add details

Generally, step 1 is done at the top. Whether it’s the Head of Marketing, Community Manager, or Content Marketing Manager, someone familiar with the company’s overarching goals should be responsible for choosing and defining a content strategy. This strategy won’t go into specific article ideas, but rather set the target audience, the kind of content you’ll create, and how you’ll capture readers to turn them into leads.

Next, use the strategy to come up with a list of possible article ideas. At this stage, each idea will probably just be a title and maybe a couple of bullet points. If there are lots of ideas, you may need to rank them and pick the winners. If you’re having trouble coming up with ideas, you might want to take a break and return to it later.

Finally, someone on the team needs to be responsible for researching each idea and adding details like the outline, pitch, and assets. After these details are added, the team should review and approve them before doling them out to writers.

Having Trouble?

If all that seems overwhelming, and you’re tempted to skip the content planning phase, you don’t have to go in alone. At Draft, we help software engineering blogs define and carry out content plans.

Learn more about creating technical content plans at Draft.dev.