So you say you wanna be a writer.

Maybe if you have a blog and want to make it more readable I could give you a few tips. But there’s too much luck involved in getting anything published on a paying basis. It’s sorta like wanting to be an actor: You can get parts in a local community theater, but that isn’t where the money is.

I misunderstood? You work in a job where you send a lot of emails, write the occasional report, and aren’t quite ready to ask an AI to do your writing for you? But when you’re done writing something you doze off mid-paragraph while proofreading it?

For this I can help.

Starting here: Don’t choose a writer you admire and attempt to mimic their style. A good writer’s style is a projection of their personality. Mimic your favorite writer and you’ll be trying to change your character.

Worse, your favorite writers are probably your favorites because they inject some entertainment into their writing. When you’re writing for a general audience that’s a good thing, so long as you don’t overdo it.

But when you’re writing for colleagues in a business setting, add entertainment and you risk making yourself the class clown. You might attract an appreciative audience in your place of work, but while your co-workers might enjoy your humor, those in a position to award you raises, promotions and bonuses won’t put you high on their lists because of it.

And so, when it comes to writing for your place of work, you’re best off keeping your humor to yourself, or, if you’re feeling the need, to a small circle of friends.

Then it’s time to get serious about what you have to say. And as is so often the case, getting serious starts with a plan. Like the one that follows. In it, you need to think about your audience, purpose, “meta-purpose,” actions needed by your audience, the document’s tone, and its grade. Just in case these aren’t too obvious to require additional explication:

Audience: Who are you writing this for? Who else are you writing it for? Who else might read it whether you want them to or not?

It’s unlikely that you have just one audience, and even if you do you can’t count on what you write not being propagated to others.

You need to know who you’re writing your document for so you can present your thoughts in ways that are as compatible as possible with how your audiences think.

One more bit about your audience: Avoid the “person from Mars” trap – the trap of assuming your audience has been living on Mars for the past 10 years and knows nothing about your subject, but also failing to provide context to someone who has been metaphorically living on Mars and needs it.

Purpose / Goal: What you hope to accomplish by writing the document. Start with the most global alternatives and then drill down a bit; the most likely global alternatives are either to inform or persuade.

If it’s to inform, ask yourself what you want your audience to be smarter about than they were when they started reading. “Who, what, when, where, why, and how” is a useful template.

If it’s to persuade, what do you figure they think about the subject now, and what would you like them to think about it when they’ve finished reading? And especially, what you would like them to do about it. Want a template? “Problem, solution, plan” is a useful framework.

“Meta” purpose: In addition to the “official” purpose, what else do you want to accomplish? For example, you might want to make your audience smarter about the challenges of processing OCR. You also might have a meta-purpose of wanting the recipients to think of you as a sophisticated and knowledgeable resource to call on when this level of expertise is needed. Or, it might be to get someone on your side of things if the subject is, say, politically contentious.

Action needed? What do you want your audience to do as a result of receiving this from you. If the answer is nothing, think hard about whether it’s a document you should send at all.

Tone: Given the audience, purpose, and action needed, will the document be more effective by being formal, or by being relaxed and casual?

Grade: Go through the document and score each paragraph as to its suitability given its audience, purpose, meta-purpose, and needed action; also whether it fits the tone you want to set.

Which leads to Bob’s last word: Don’t be an easy grader.

While many are recovering from the CrowdStrike patch situation, it is probably good to reflect on the fact that the outcome could have been worse.

It was fascinating to see that certain industries suffered more, including travel and healthcare.  It seems that tribal affiliations or very targeted marketing (or both) gave CrowdStrike several industry specific installation bases that were impacted significantly.    Most of us have at least one story of a friend or colleague that couldn’t catch a flight home on Friday or a medical procedure that couldn’t be performed.

Monoculture IT has the same problems as monocultures in agriculture, politics and communities—Vulnerabilities are amplified, and have more consequences.  We can’t buy “Big Mike” bananas these days, and some of my ancestors moved here because of a potato fungus.  In both cases, farmers were growing the same exact genetic sibling or clone, only to be taken out by a highly specialized threat, at a huge cost to everybody.  We live in a time where deliberately or accidentally bad software has replaced fungi as a daily threat.  The analogy is shockingly close. Maybe we should stop talking about viruses and call them fungi instead?

Luckily, our diverse systems saved us from worse, and I think there are some lessons here for IT leaders.

Lesson #1- OS Diversity is a good thing.

The multitudinous flavors of Linux have more or less replaced all the commercial Unix operating systems and are varied enough to keep pests and predators as bay.   Non CrowdStrike Windows systems were not affected at all.  Neither were the remaining Big Iron systems affected either.   This isn’t a “Windows is bad / Linux is good” situation.  We can predict that next time it will be a Linux, or legacy Unix, or Apple OS that’s the culprit.

When you evaluate the alternatives – OS diversity vs OS monoculture – monoculture makes technical architecture management easier. Diversity makes risk management easier. See Lesson #3.

My opinion: The management challenges of multiple OS platforms seem to be worth it.  And to be sure we’re clear: I’m advocating OS diversity, not obsolescence. Lifecycle management still matters, as one big airline that’s still using some sort of patched up version of Windows 3.1 we found out (!)

 

Lesson #2- DevOps needs multi-environment testing and promotion.

Like many of you, we adopted a containerized, Kubernetes based DevOps approach over the years. Bad releases make people unhappy, lose confidence and vendor patches still need to be tested before promotion to Production as if they were your own development.   It was surprising to see so many companies that seem to have dropped multiple levels of environments and testing, and allowed the CrowdStrike patch to be installed directly on Production environments.   I am scratching my head about why this would happen- Was it because it was felt that this was an especially trusted vendor?  Was it because of the perceived risks of a Zero Day vulnerability? What was communicated to them from CrowdStrike about the release? Are there companies running enterprise systems without a “Dev/Test/QA/Prod” environment architecture, based on some perceived cost savings?  We often see environment architecture compromised due to cost.

Maybe it was confusing “Continuous Integration / Continuous Delivery” (good) with “Continuous Integration / Continuous Deployment” (bad). Or maybe it was just plain old complacency.

Regardless, IT leaders need to take this lesson to heart now.

 

Lesson #3-  Making things easier often makes them more risky.

This week’s column was originally going to be about AT&T and Snowflake.   Data warehouse security really should be at the top list of considerations (Note to self—fix this column).    In both cases, we see how the promise of “Easy” management of key systems introduced risks that were pronounced and, unfortunately, realized.   This seems to be the case with CrowdStrike customers that assumed that the automatic patching system could be entrusted with a Production system.   We are likely running similar risks with all the Cloud hosted offerings in our lives right now that some cloud-hosted vendors hide from view.

There may not be a great alternative to this risk, but awareness is a good place to start.  Or, if you’re big enough to have the requisite clout, ask your cloud-hosting vendors how often they undergo an ITSM audit, and to share the results of the most recent one.

Just because the root cause of the CloudStrike mess was bad patch management, that doesn’t mean patch management is the only poorly implemented ITSM practice that can create vulnerabilities.