5 Steps to a Quality Edit for Your Technical Blog
If your core audience is technical, you already know that your readers won’t pay attention to any content that’s not written by subject matter experts.
Your audience needs to know that your company understands the industry and its particular niche in it. However, this prerequisite can put a bit of a hiccup in your content publishing pipeline: subject matter experts aren’t always expert writers.
Fortunately, with a robust editing process in place, they don’t have to be. At the end of your content workflow, your writers should feel confident that their point is being conveyed clearly and efficiently, and your audience should be able to trust that your content is easy to understand and correct.
For example, Draft.dev’s multistage editorial process includes at least three rounds of edits before content reaches the final audience:
- Technical review
- Developmental edit
- Copy edit
And sometimes even two more:
- Author review
- Stakeholder revisions
Want to develop your own editorial process for your technical blog? I’ll guide you through all five of our steps here at Draft.dev in detail. By the end of this article, you should be well on your way to a thorough and efficient edit that you can recreate with each new post.
1. The Technical Review: the Red Flag
Edits should always progress from the biggest picture to the finest detail. There’s no point worrying if commas are in the right place when the piece has huge inaccuracies.
The first person who looks over a draft should be reading for technical accuracy. They don’t have to be as deeply expert as the writer, but they should be able to tell if any gaps need to be clarified for readers or, heaven forbid, the writer has oversold their expertise and is in over their head.
This does not mean “I would have written it differently, therefore it’s wrong” or “their grammar is sloppy, so the whole thing needs to be redone.” Your technical review should answer these questions and these questions only:
- Is the content inaccurate or misleading?
- Does the target demographic need more or less information to absorb the point of the content?
If the answer to one or both of these questions is yes, then this article may need to go back to the writer immediately. You should have someone in your editorial pipeline able to make this judgment call.
If the answer to both questions is no, then proceed to a more fine-grained edit.
2. The Developmental Edit: the Architect
I know I said “fine-grained,” but a developmental edit is still a rather big picture edit. Here, you’re examining the content for efficient organization.
Does the information flow well? Do paragraphs need to be moved around? Are readers helped through the article with a clear introduction and headers that make sense? Does the article conclude in a way that answers any questions that have been posed? There can also be some overlap with a technical review here—is the article speaking to the main point? Does the title reflect the focus of the piece?
Experienced writers working with experienced editors may not need to address the article again at this point. It’s very possible that they’ve nailed the subject matter, and the editor was able to make any necessary adjustments themselves.
However, a developmental edit can definitely poke holes in an article. Perhaps wordy sentences deflate into nothing, or a critical section of the proposed outline has been missed. In those cases, the article needs to head back to the writer for an author review.
3. The Author Review: the Checkpoint
An author review is not a complete rewrite (your publishing schedule most likely doesn’t have time for that anyway), so make sure you communicate clearly what you need the writer to focus on at this stage.
Do they need to address a bug in some sample code? Does a screenshot need to be remade? This is the time to ask your writer to address specific changes to the content.
4. The Copy Edit: the Quality Control
When you’re confident that the actual subject matter is as accurate and efficient as it can be, it’s time for a final polish.
A copy edit is a very fine-grained edit—you’re looking for spelling, grammar, capitalization, punctuation, and that’s just a start. If a writer’s first language isn’t the one they’re writing in, your copy edit may need to be a bit broader and take care of some awkward wording.
Don’t forget to run an eye over formatting as well. Are your header styles consistent? Did the writer use italics and bold for emphasis? Do you need author bios to follow a certain style? Having a technical style guide can help, but you still need to check these tiny things here.
Note: Some editors can handle a developmental edit and a copy edit simultaneously, but if the writing is in rough shape, this can be difficult.
5. The Stakeholder Revision: the Stamp of Approval
At Draft.dev, our clients are the final review before publication. The content should be tight enough that they can easily see the big picture and point out any areas where they want more or less information or a different nuance.
We can expect the content to consistently be at that level because each editing stage beforehand is very intentional. Something specific is being addressed at each point. The content is not being aimlessly tossed from person to person to see what they think.
In fact, if you’re handling your content in-house, you should avoid having reviews done by everyone from the CEO to the marketing VIP to the tech lead. This is expensive in resources—hours and wages and lost progress on other projects—and it usually ends up diluting your message.
The phrase “too many cooks spoil the broth” is highly applicable when it comes to producing a piece for publication. If you pass your content around to everyone with an opinion, you’ll never publish it (and after everyone’s put their mark on it, you probably wouldn’t want to).
But Remember…Start with Good Writing
To recap, you can make your technical content publishing pipeline a lot more painless and more consistent with a solid editing process in place. Put someone in charge of your content. Give them the authority to call a piece finished. Make sure your process is repeatable so there’s no wondering about “who needs to see this next.”
Of course, it helps to remember that an excellent writer leads to an excellent edit. Going back to our cooking analogy, you can rescue a lot of bland dishes with good seasoning, but you can’t save something that’s burned beyond recognition.
That’s why at Draft.dev, we vet our subject matter experts and use an objective rubric so you don’t have to, and then we put their work through our multistage edits.
It’s not easy to build a consistent, reliable content publishing process when it’s not your core business; you can always find room on our calendar to talk about whether or not Draft.dev is a good solution for your technical content creation.
By Chris Wolfgang
Chris Wolfgang was the first editor at Draft.dev. She’s been writing and editing for tech for longer than she would care to remember.
Build a Blog that Software Developers Will Read
The Technical Content Manager’s Playbook is a collection of resources you can use to manage a high-quality, technical blog:
- A template for creating content briefs
- An Airtable publishing calendar
- A technical blogging style guide