For years, the fact that we cannot provide transparency from what we learn as we’re moving along and growing was a constant thorn in my back. Even when we decided to do a marketing (a.k.a. content) push with our blog, it did not bring that much value since I, as the founder of Monitive, didn’t find the time to write. And was the one knowing a whole lot of what was going on, our challenges, and how we went past them.
So, articles did come out, very nicely written by our skilled marketing specialist. But they were more like general knowledge and not that tightly coupled with what was going on within the company.
Until the Document. Don’t create. strategy. Gary explains this strategy as:
In very simple terms, “documenting” versus “creating” is what /The Real World/ and the Kardashians is to /Star Wars/ and /Friends/. And don’t get confused—just because you’re “documenting” doesn’t mean you’re not creating content. It’s just a version of creating that is predicated more on practicality instead of having to think of stories or fantasy—something that’s very hard for most people (including myself).
Today I published the About us page, and one of the values is transparency.
And since I’m not amazingly skilled at fantasy, I decided to start documenting.
I believe it’s a mindset.
When I sit down wanting to write a blog post, I feel the immediate pressure to create, which creates the exact opposite of that.
But when I sit down thinking to document something that recently happened or I recently learned, plenty of ideas come to mind.
So here I am, documenting this neat and helpful trick to blow away writer’s block, and start writing.
A quick walk through my process looks like the following.
I use the Bear app for the actual writing, as it’s amazingly beautiful, and a real pleasure to write. It also uses Markdown syntax that I’m using later down the line.
For editing, I use the Grammarly desktop app. It’s amazingly useful to proofread and correct any spelling errors, quickly find synonyms, and more. The free version is enough for me. I just copy-paste the entire article from Bear to Grammarly. And whatever I correct in Grammarly, I update in the Bear article. This is something I’m trying to find a workaround for.
Side note: I used to have Grammarly’s Google Chrome extension installed, but I removed it after coming across a very solid thread on how Grammarly receives “a nonexclusive, worldwide, royalty-free and fully-paid, transferable and sublicensable, perpetual, and irrevocable license to copy, store and use your User Content”, and by User Content they mean everything you type in your browser (while you’re using the Chrome extension). I’m not a privacy freak but that’s where I draw the line.
Next, I copy-paste it into VSCode, as your website and blog is a static site with simple, Markdown files.
This is also where I add the images and preview the article as it will be written. I use Firefox Nightly to preview that article, but that’s just because it becomes very useful when debugging CSS issues.
And finally, I git commit the new post and its images, and two minutes later, it’s live.
If you’re looking for a simple solution to detect downtime before your customers do, check out Monitive.com.