Recently, I was asked to help another team's manager to publicize some work done by two members of her team. The team had done something amazing and she wanted to make sure the world knew. How could I say no?
The background is simple. Kurt and Wes had developed a new testing method using an Amazon Web Services (AWS) product called Lambda. The new method cut their testing time down from over 3 hours to about 30 seconds. That averages about a 360x improvement in speed. If this approach was truly new and amazing, people should know. We approached our contacts at AWS, told them what the two had done, and asked whether they liked the approach and would give us a guest spot in their blog. AWS jumped at idea. So Kurt and Wes put together a blog post. I worked with them and our marketing team to get the text and images ready for primetime. AWS published the blog post. We all shared on our social networks. We watched as the views clicked upward and as people swooped in to view our profiles.
So how does this work? Here are the three steps that helped Kurt and Wes go from rockin' it to being rockstars.
Step 1. Do something awesome.
Alas, this is the part that I can't help you with. I am not very creative and I don't know your field as well as you do. I can only encourage you to take every problem you encounter as an opportunity to find a new, cool solution. You will think of lots of weird before you strike gold. That's fine. The world is saved by weird.
Step 2. Find out who cares about awesome.
This step is important because it shapes the rest of what follows. In the case of Wes and Kurt's great idea, it was pretty clear who would care:
- people who do automated testing, particularly of web apps
- people who are use AWS as their platform for development or testing
The outlets we wanted to target needed cater to those people. We thought about general developer portals like dev.to, which I love. That's a cool portal and platform for great ideas, but it's more about developers and development, and it's not very specific to AWS or its Lambda tool. We also thought about Blackboard's own blog, but decided that elsewhere would be better. Wes and Kurt work at Blackboard, but that blog aims at Blackboard clients. The natural choice was to go for one of AWS's blog - especially because AWS has blogs that cater to things like QA and DevOps. We spoke with our contacts at AWS and offered the idea. We agreed that the AWS DevOps blog would be the way to go.
Step 3. Write about your awesome.
Knowing where the post would 'live' and who it would target were important for writing and editing it. As an pretty experienced technical writer and API docs writer, I already had a good idea on how to get Kurt and Wes's blog article ready for prime time. Below is a summary of the steps
Pointer: look at existing content on your chosen outlet.
Your chosen outlet might have a style guide. Look for one or ask for one and if it exists, use it.
If an outlet has no style guide, there are still a lot of quantifiable criteria, metrics, and tools you can use. These will help you calibrate your writing to match that of your chosen outlet. For example:
- Do existing articles speak directly to the reader by writing things like, "You can do X" or "Do Y"?
- Do they take a more formal, third-person approach like, "The developer does X"?
- How long are the sentences?
- How do they use images?
In my own blog, I've mentioned two great readability tools. Readability is generally scored as a 'grade level'. Readability tools calculate grade level as a function of the number of syllables per word and number of words per sentence. These tools apply penalties for things like:
- using too many adverbs
- using too many passive voice constructions ("mistakes were made" instead of "Bob made mistakes")
- parenthetical clauses.
These hinder reading and there are studies that prove it. Run existing content through a readability scorer and work on yours until it fits in. Generally target the 7th-9th grade reading level. If you go much lower, the text may feel dumbed down. If you go higher, educated adults start having to work to understand it.
Calibrating your piece to the outlet's existing style will help you win acceptance.
Pointer: start with an outline.
Just do. Otherwise, you'll ramble. You really will. You'll forget things and just chuck them in wherever your cursor is when you happen to remember the things. Your readership won't know what the hell you're getting at and they will stop reading. Please. Make an outline. If you're an engineer, you'd plan your project in advance. Telling people about your project is worth a bit of planning.
Pointer: your baby is uglier than you think.
We all have babies that we love and even sacred cows that we don't want touched. Especially with our writing, we tend to get attached. We also tend to feel competent in places where we're not actually professional.
Get feedback.
Ask people to tell you where and how your ideas are weak. Ask them to read your writing. Give them a red pen and beg them to draw blood. If you want your idea to be really great and your writing about the idea to be really awesome, easy to understand, and get accepted by publishers and readers, you just have to let people hurt it. But really, your writing isn't actually a baby or a cow. It will only be improved with manhandling. Stake your ego in the finished product, not the first draft.
If you work in an enterprise, there are people who write for a living and will be happy to help you. We writers are awesome like that.
Pointer: get some SEO action on.
If you want people to read your blog post, they need to be able to find it with search engines. Some tech writers know the basics. Content marketers know more. People around the office might be willing to help or at least give you pointers. Also, I bet Google knows about SEO.
I'm Happy to Help
Last note. I like writing and I like pitching in. Feel free to run your thing by me. I have a full-time job that gives me plenty of work, and if you can bear that in mind, I'd game to help you show your work off.
Top comments (0)