Choose Your Next Article Topic With This Exercise

When I fall out of my writing habit, most often it’s because I can’t decide what to write about. Choosing an article topic can be paralyzing. Here’s an exercise I use to come up with new topics. Afterward, the issue is not that I have too little to write about, but too much.

When coding, you don’t let “not knowing what to code about” stop you, do you?

No, you have a process to turn bug reports and feature requests into code. Having a process for problem-solving, like design thinking, get’s you unstuck and gets you moving forward.(For more on solving coding problem deliberately, check out this post from Justin Fuller: How to understand any programming task.)

Writing can be the same. And it’s important to keep up, It’s been one of the best skills I’ve leveraged to improve my career.

Photo by rawpixel on Unsplash

First, identify your topics.

There’s plenty of places to look for initial topic ideas:

• What have you learned about recently? You could think of treating your blog as a public “personal wiki” of knowledge. Some of my most popular articles have come from me writing about problems so I’d remember how to solve them if they came up again.
• What problems from recent projects have you tackled? Related to the first, but looking at a slightly different lens can lead to more ideas.
• Has anyone asked you a good question recently? Think in and out of the office.
• Have you had any interesting conversations, either online or offline?
• Have your written something else that resonated? Maybe another blog post, tweet, or comment on a forum?

Then, apply some “design patterns.”

1. Question & Answer
2. How-tos
3. Next Actions
4. Mistakes
5. Lists
6. Resources
7. Sample
8. Philosophical
9. Motivational
10. X vs Y
11. Quick tips
12. Case study

Now: Apply the Design Patterns to a topic

Once you have a topic, run it through the format gauntlet, and voila! Several new starting points for posts. Let’s take “refactoring a react components” because that’s one I pulled out of “recent challenges from work.”  Your topics might look something like this:

1. (Q & A): When is refactoring a component a good idea?
2. (How-to): How to refactor your complicated components into smaller, more manageable ones
3. (Next Actions): Explaining the value of refactoring
4. (Mistakes): Common mistakes that lead to less maintainable components
5. (Lists): 7 signs your component should be refactored
6. (Resources): Install this Atom Plugin to make Refactoring a breeze
7. (Sample): Example of a component refactoring
8. (Philosophical): Where Refactoring fits in the development process
9. (Motivational): How to refactor legacy code without feeling overwhelmed
10. (X vs. Y): Refactoring vs. Rewriting (oh wait, I already wrote that one: Should you repeal and replace your legacy code base?)
11. (Quick Tips) 5 quick refactoring wins
12. (Case Study) How refactoring shaves two weeks off of our next four feature releases

Overcoming Common Stumbling Blocks (AKA Debugging)

“My topic doesn’t mesh well with one or more of the formats.”

No worries. Skip it and continue moving forward. You’re going to come up with more potential topics then you could write so don’t sweat it.

Write “X” instead. You don’t have to know the exact count until the end.

“I started writing, and it went off the rails.” 

You don’t have to commit to these ideas. Sometimes I end up starting one article and finishing another.

“This topic is too long; I’ll never finish this!”

If something seems daunting, hammer the scope to a more specific topic. Sometimes the result is better. Would you rather read: “How to fix ‘ _reactNavigation.getNavigationActionCreators is not a function‘ error, or “How to debug JavaScript?”

“Writing about technical stuff is boring.” 

Articles don’t have to be technical. Plenty of developers also like reading about topics like soft skills and career tips.

“I’m not trying to be a guru here. Why am I acting like I’m the expert?” 

Your goal should be above all else, to be helpful. You aren’t writing for yourself; you are creating a small thing that can help someone else in the world. And isn’t that something we all enjoy doing?

“I Don’t know which topic to pick.” 

Short answer, whichever one you can write, finish and publish. You can’t help anyone if you don’t ship. The whole goal here is to get over the paralysis of not knowing what to write about. Just take some inventory, sketch out some ideas, and get started! The more you write, the more you’ll find you have to say. Writing is a marathon, and you can switch lanes at any point.

Still don’t want to blog, but want to improve your professional writing? Check out the valuable writing package for templates & resources, available for free.

Process Documentation: The First Step to Eliminating Tedious Work

Looking for ways to spend less time doing parts of your job that you hate? You have three options:

• Eliminate.
• Delegate.
• Automate.

I’m a minimalist. I like to take a Marie Kondo approach in business and life. Tasks get on out plate more quickly than they get off, and we don’t always stop to reflect and ask: “Does this work provide value? should we do it at all?”

Let’s assume for this article that the task has passed the sniff test. You can’t eliminate it. Then move on to the next two options: If a computer can do it automate, else we delegate the task to someone else.

There’s an important step before you can productively do either: document your process. Documenting your processes is something that you should be doing at any stage of your business, for a company of any size. I was documenting new processes on day 1 of my one-man shop.

Everyone has systems in their heads, whether they realize it or not. Do you have a morning routine? A strategy for handling your inbox? These are almost a process. However, I’m a firm believer that:

If Your Process Isn’t Written Down, It Doesn’t Exist

Ideas in your head are fuzzy and abstract. Getting a system out of your head and out into the real world has several benefits:

• It forces your mind to bring clarity to ambiguity. Sometimes the simple act of writing a process can help you improve it.
• It frees up mental RAM. You don’t have to remember every step of the process.
• It improves reliability. A process means you do the job the same way every time.
• You can iterate on the process. Once something is created it can be improved.
• You can attack the work with greater confidence.
• You can share your process with other people (the first step toward delegation)
• You can find ways to streamline, eliminate, or automate parts of the process (the first step toward automation.)

So How Do You Write a Process?

Many people get hung up here.  Don’t. It can be anything that lays out how the job gets done. Some common examples:

1. A numbered list of steps that you follow.
2. A flowchart of if-then logic.
3. A checklist that you go through.
4. A rubric or heuristic you use to evaluate something.
5. A template or swipe file you can use to kickstart a creative process.

You don’t have to pick one, choose the one that makes the most sense for the process at hand. Don’t try to force too much uniformity or rigidity. It also doesn’t have to be just one of these; it can be a mix.

Tools For Documenting Processes

1. Google Docs— It’s used by most organizations so getting others on board is simple. You can share documents as read-only. You can easily link between docs or link to a doc from another tool.
2. Screenflow — Screenflow makes it easy to record your screen and your voice simultaneously. I use this to record processes instead of writing them out. You can use the video as documentation, as a supplemental aid, or you can hand it off and have someone else for transcription. The free version of this is using screen recordings with Quicktime
3. Trello — Trello is great for keeping track of processes that have multiple steps that take place over time. You also get checklists and links to Google Docs within a Trello card. The order of columns acts as a high-level documentation of the steps of the process. I’m also a fan of keeping a resources column on the far left, with cards linking to other processes and resources.
4. Things —  Things is my de-facto to-do list. My ur-checklist. Every project, both personal and professional, is in there. I also find the scheduled and recurring tasks useful for turning processes into habits.
5. Context-Specific Tools Every process doesn’t have to live in one place. You’ll see in the next example.

Case Study: Outreach

Recently I had to consider the following facts:

1. Outreach, when done correctly, is an effective strategy for generating new business.
2. I’m not a big fan of doing outreach.
3. I am a big fan of building systems.

So the conclusion was obvious. I shouldn’t be doing outreach; I should be building the outreach system. So I decided to tackle the problem in that way. The process is broken down into three parts.

1. Email Templates I created a Google Drive file with templates for reaching out. There are a couple of different ones depending on the context. Also worth noting that I’m not advocating for sending the same, impersonal, boring email to everyone; each template is still manually customized depending on the situation. In a way, it’s a mini-automation of the process.
2. Recurring Task in Things Outreach is something I’ve made part of my daily routine. I keep two recurring tasks on my to-do list every day: One to do new outreach and one to do follow up.
3. Track Progress in Pipedrive Pipedrive is my CRM of choice. It’s Trello + A Rolodex. I have a pipeline for keeping track of who I need to follow-up with and when.

By creating a process, I  turned outreach into something fun instead of being a chore. Now I’m not just sending emails; I’m testing and iterating on parts of the process. I was able to shrink down the amount of time I spend doing the outreach so that I can spend more time doing work I enjoy.

Getting Started

Try documenting one of your systems today. It shouldn’t take you more than 20 minutes. Pop open a Google Doc, and write down the steps or create a template for just one task. See how much easier that task feels the next time you go to tackle it. How much more confidence you have. See how many minutes you save. Once you get over the hump and get started working on processes and see the benefits, it’s almost addicting.