Something Is Broken
So when I originally set up this blog I was full of enthusiasm, hope, and a fair bit of hubris as well. I think we have all had moments in which we take on a project in excitement to find that it’s not working out the way we had planned. There are certainly plenty of examples and experiences within the DevOps and security space. I also don’t think this is inherently a bad thing.
When we discover that a problem/outage/incident/gap has happened, this is the time for engaging in the exercise of a retrospective. This can be a big or a small thing, but the important piece is taking a moment for pause and reflection. These can be immensely effective when used properly in creating change and also for redirecting strategy towards one’s intended goal or objectives.
To quote a former mentor of mine:
“If you’re not making mistakes you’re not trying hard enough”
Where things went wrong?
Within incident response and the security field there is this term called “root cause analysis.” In layperson terms it’s a way of being able to determine what was the source of the problem, ie. “why did this happen?” The DevOps space often calls them “Post Mortems.” An old colleague of mine liked the term “Retrospectives” as it was less morbid, and it’s stuck with me since.
Regardless of the term you use there are some core principles on how they tend to be conducted. One of the most important of those is referred to as “blameless culture” or “faultless culture.” Fairly self-explanatory but hard to overstate. It’s to figure out what happened, but to do so in a way that allows for genuine evaluation without jumping to blame or punish.
Taking those concepts and applying them here, there are a few different things that stand out to me on where/how things went wrong for the blog. I’m going to list a few of them off, then a few of what went well, and then I’m going to talk about what I plan to do next:
-
No Backlog: The start is that I hadn’t built up a repository of content to talk about in advance. I had assumed that as time went on I would think of things to share and that would naturally expand/fill in as I needed. This was not inherently a bad strategy, but I failed to provide enough structure for those ideas to latch onto. Similarly when there were concepts that came up (such as log4j or the anti-LGBTQ+ bills) I often had my hands so full that I wasn’t in a place to be able to write a proper blog post on the topic.
-
Too Restricted: One of the related issues that I ran into with the above was that I was treating this blog in a very restrictive fashion. Specifically I was treating it as if I could only post things about security or DE&I, and within those spaces only within highly restrictive contexts. Granted there are some strategies out there for creativity that use purposeful restriction as a method for inspiration, but obviously that didn’t pan out this time. This meant that even when I had topics or ideas to talk about, I was so engaged in the metacognition of “is this idea close enough to the blog’s objective” that I rarely was left with enough resources to actually write the blog. Something of an essential part of the blog.
-
Underestimated Energy Cost: Another area that I genuinely did not treat with the amount of respect it was due was how draining and exhausting creating something can be. Once again the assumption was that I would eventually find the energy, instead of reserving the space and resources for it. Like any hobby, skill, or profession, we need to be proactive in making space for the tasks we have decided are important to us.
-
Schedule: This one is kind of a minor point building off the others but still important. I didn’t have a consistent touchstone/routine for checking back with my blog. This allowed for time blindness to sink in/take effect. At which point the problems compounded each other. At some points going so long between checking in that it became an obstacle to even post because my dev environment for it had become stale and it would have been a chore to set up.
Where things went right?
There are a few areas that were successful as well that are worth calling out.
-
Networking: The blog and site did work to drive contact and networking despite the low number of posts. The amount of success from this would have likely been even more notable with increased postings.
-
Quality Control: Although it was overly restrictive the processes that I had in place did mean that I was not posting content that was not in line with my goals.
-
Stable Hosting: Going with a “serverless” hosting method was a definite win. Specifically because it allowed me to go long stretches of time without worrying about patching the blog or its overall maintenance. Similarly this drastically reduced my hosting costs. On a related note, going with Jekyll as a content management system overall has worked very well.
What next?
So we have some key areas that were issues, and some good things that we don’t want to negate with our solution. What do we do next? In a team setting I would usually have a conversation with the people involved, but given that this is basically a team of one, I have some introspection and self discussion. Here are some of the action items that stand out:
-
More Flexibility: I presently manage multiple different platforms for different styles of content. I’m also doing this primarily as a hobby and professional support. As such I should look for ways in the future that I can consolidate my activity so that I’m not spreading it out as much. There is still probably room/allowance for segregation of content types, so folks know what they’re in for, but at the same time being more consolidated could help with more consistent content generation.
-
Digest Summaries: As an extension of that consolidation effort I can probably create digests(or optimally even find a way to automate collection to lower the lift on editing). This practice would also serve as a way to keep me engaged with the medium and possibly even spot overarching themes that could be good longer form content.
What’s left unanswered?
There are still some questions left unanswered or partially answered, and that sometimes happens at the end of a retrospective, and that is ok. It’s still important to note them as that can help inform the cognitive process and review later on.
- What media do I consolidate, and which do I leave separate?
- Similarly what parts of my identity & expression should be separate?
- Summing that up, What should I put in and leave out of this blog?
- How can I build up a backlog of content?
- What is the optimal cadence for posting?(this might be able to be data driven)
