You probably have a bunch of blog posts that you have already written that could be published today, but you may not be aware that they even exist. This post shows some ways to unlock this potential content for your business or personal blog.
In the course of doing business, there are a number of artifacts that you typically create that would make excellent material for blog posts. These artifacts could include:
- internal shared documents
- general project documentation
- workflow / process guides
- lessons learned / retrospectives
- high signal emails
- new project steps
What took hours of work to write up and possibly days or months of hard-won experience or research can be shared with your customers or clients and help them. Obviously you should remove anything that is your company’s secret sauce, confidential, or detailed plans, but why not share your overarching conventions for others to benefit from and potentially improve?
Sometimes these can be used directly. Sometimes they might need a little cleanup. Sometimes explanation would help your audience understand the meaning or context of the document. But you may have ninety percent of a future post that you have already created.
Internal artifacts also reveal something about company values. If in your software development process you explain: “We don’t track bugs as positive velocity” or something like that, that may be a useful thing to explicate. It may be that this belief comprises a core part of your company’s culture. Similarly, reading your internal documents through the eyes of an outsider might give insight into what things your company values and how you arrived at the beliefs you currently hold. One example might be why and how you use feature branches to break up work (or why you consider them harmful.) Perhaps you already have this written up, or it would be good to document to make things clearer for new people on the project.
Sharing the internals of how your company makes decisions aligns you with like-minded customers and potential employees.
There are a few examples of this process that I can point to on this blog. These came out of typical things that I did at work and that seemed useful enough to share:
Starting on an Existing Rails Project came from a brainstorming document that I wrote up to capture thoughts on how to get up to speed on an existing project more quickly. When I saw how much value there was there, I tweeted to ask others if they would use something like this, and they responded positively (derisking taking another few hours to polish it up.)
How to Run a Successful Brown Bag System was content that I wrote for a blog, but it came from listing out our thought process and timeline of iterating on a system to try to get lunch and learn / brown bags going. From what I know, this process is still going strong in some incarnation at the original company.
Take a few minutes right now and go through Dropbox, Google Docs, and your project documentation and make a list which documents might have something that you can share with others. From this list, order the documents by how polished or informative they are. Finally, make a schedule to go through them one at a time and clean them up a little and publish them.
Seriously, go do this. I’ll bet you can find three posts that you can publish with relatively few changes that are valuable.