business development, craft, Writing improvement

How to Organize Your Writing – Work Backwards

You’re not going to believe this, but this (this exact sentence, that started with “You’re not going to believe this, but this [this exact sentence…]”) was written last. Read on to find out how. More importantly, why.

kaleidico-xxHDLWmc1wE-unsplash
Photo by Kaleidico on Unsplash

What’s the hardest part of writing an article (or report, or memo), whether for your industry publication, an online community, your boss or the C-suite, or even just your own blog?

Some will say the hardest part is just getting started.

Like, that big blank canvas is intimidating.

Overwhelming.

Just staring at you, mocking your inability to get out anything reasonable.

For others, it’s the organization.

What do I say first? And then? Where do I end?

For non-writers, the structure can be just as difficult as the execution.

But it doesn’t have to be.

I can’t always help with the blank page syndrome. For organizing your thoughts, though, I can at least give you a structure for how to plan and then actually write the damn thing.

And this is not about how to prove your ideas with appropriate examples, or how to develop an appropriate voice or tone. [We can talk about those other times.] This is a process for you to organize your article creation, one that I apply myself when I sit down to write.

There are about as many methods as there are professional writers’ hands. (Yes, that means some have more than one method. Don’t shoot the messenger.) I have no idea whether this will work for you as well as it does for me. But give it a shot next time you’re wondering how to get started and how to fill up the space on the page. You just might find your next great productivity hack.

With that, let’s talk about how you can develop a quality piece with all of the essential parts: an Executive Summary (or Abstract), an Introduction, the all-important Body Text, and a Conclusion. It might be counter-intuitive, but I’m actually going to recommend you plan your writing completely opposite to how your reader will experience your article.

Start With the End In Mind

Yeah, this is a reference to The Seven Habits of Highly Effective People. And it’s a reference to Start With Why. It’s also the exact answer to the question I ask when people want my help creating content: “Why are you writing, exactly? What do you want your audience to know?”

Just start listing out the lessons you’d like them to take away once they’ve finished reading your article. They don’t have to be in order, they don’t have to be pretty, they just have to be on the page. Refinement comes later.

Prune Out The Less Effective Fluff

If you’re writing an article, you’re going to want one, or at most two, conclusions for your audience to take away afterwards. If you’ve got three or more, you’ll have to do some hard work and pick the one or two that you really want to emphasize.

The great thing about having written all of them out, though, is that you’re not banishing those ideas to the hinterland, never to return again. If they’re related, plan them for another article! If they are absolutely integral to the understanding of the most important one or two, then maybe it’s not an article but should be delivered in a longer format: a series of articles, a White Paper, or even an eBook.

Once you’ve identified your audience’s most important take-away, it’s time to get busy.

Create Strong Roots

You’re still not actually writing at this point. You’re doing more outlining than anything else: these are the two conclusions that lead to final answer #1, and these are the four theories which support those two conclusions, and these are the ten data points which underlie the four theories.

Create your outline as if you were working from the trunk of a tree down into the roots: trace back all of your supporting arguments to their fundamental causes, and map out how you’re going to lead the reader from one item to the next.

When you’ve got a comprehensive outline, then you can start to write the Body Text. But maybe not from the beginning to the end.

Don’t Assume You Have To Write Linearly

Your audience is going to read from the start to the finish, obviously. That’s what we’re trained to do from age six.

But you, as the author, as the sculptor of their journey through your article, don’t need to actually write section one before section two. Write what’s most comfortable first, and get into the rhythm that way. Work out the kinks of your tone and voice with the elements that are most automatic, because you will often spark other ideas you didn’t expect as you’re firing across all your neurons.

the-digital-marketing-collaboration-i0WO_RzeB2Y-unsplash.jpg
Photo by The Digital Marketing Collaboration on Unsplash

You’ll find that you spend your time working on the various parts of the Body Text in spurts. It’s a little chaotic and can be hard to get used to, especially for linearly-inclined brains.

Don’t be surprised, though, if you end up appreciating this more flexible approach.

For me, even in this article, I’ve been jumping around on the page, moving words and whole paragraphs at a time, sometimes leaping from section to section, to capture what’s coming out of my head at that moment. I don’t want to be rigidly tied to the “first-to-last” order when I’m being creative.

That’s just not how our brains work. They make connections we didn’t see at times we didn’t expect. Go with it. Learn to embrace the volatility and minimal direction. You have time for refinement later.

Write Your Conclusion Next-to-Next-to-Last

Your Conclusion should summarize the important lessons you identified at the beginning. You may have even written the conclusion right after you outlined. That’s okay, and it’s a good check

When you write the conclusion, then, read back over your text and ask yourself, Where did I say that? It’s a good opportunity to check your work and confirm that you’ve gotten everything you wanted into the text itself. If you can’t find where you proved what you wanted to, go back to the text and add a section, drop in an example, or make the logical development of the idea more obvious.

And Your Introduction Next-to-Last

You want to have all of the details of your article (or report or memo) already finished before you write the introduction and conclusion. If you start at the introduction, you might find yourself introducing more ideas than you actually have space for. Then, you’ll end up trying to write the article to conform to the specifications you set out in the introduction. This can lead to output that’s too long, or unfocused, or wandering.

You’ll keep on track by remembering your structure and only writing the Conclusion after you’ve clearly laid out the salient points in the text itself.

After the Body matches the Conclusion, you’ll be able to write the right Introduction, one that appropriately sets the stage for what’s to come. Don’t give away too much information too early, because that’s what the text is for.

Get Feedback and Revise

No matter how clear you think you are in your prose, with your examples, or based on your outline, you probably won’t get it right the first time. Mostly this is due to “inside-the-jar” syndrome. If you’re in a jar of your own problems, you can’t read the label that tells what those problems are, because you’re inside the jar!

You need an outside perspective. Have a friend or colleague read your draft and tell you the ABCD’s: what’s Awkward, what’s Boring, what’s Confusing, or what’s Drifting (off-topic).

Once you have an idea of where you’re going wrong, you can take a look at your article again with impartial eyes, and refine where necessary. This is where you’ll apply your [DELETE] key liberally. It’s there for a reason.

Write the Executive Summary (or Abstract) Last

I know, I know, not everything has an Executive Summary. But many will. They’ll be a 2-sentence description of the article as a teaser, or it might even be an actual abstract or summary if you’re writing a memorandum or report. So if this part isn’t critical to your operations, you shouldn’t be spending a lot of time on it. Putting it last means you aren’t going to be doing unnecessary work if you find in the middle that you topic has changed from what you originally intended.

If everything above hasn’t convinced you not to start writing with the Executive Summary, just remember this quote: “So the last shall be first, and the first shall be last.” Sure, the original context was about not being jealous of others, but it works well in this context too. What you work on last will be read first, and what you work on first will be read last.

Wrapping It Up

And you’re done! Here’s a quick review of this efficient method to create an article, report, or memo for whatever audience you’re impacting:

  1. Begin with the end in mind.
  2. Make sure you have chosen a clear message to be delivered.
  3. Work backwards through the outline.
  4. Write the Body in whatever non-linear fashion you choose.
  5. Write the Conclusion as a check that your body text includes everything you wanted.
  6. Write the Introduction.
  7. Get feedback and revise.
  8. If necessary, write the Executive Summary. You can only do this last because even though you might have an idea where it’s going to go, you can’t be sure. Putting this last ensures you set the appropriate stage.

And while you might not yet believe me, think about this: the words that you read first I wrote last, and these, that you’re reading last, I wrote (or planned) first. Game – set – match … Me.

***

Stephan Mathys is an author and communication strategist for actuaries, engineers, and data scientists. His forthcoming eBook is called It’s Not About the Data: 12 Communication Strategies for Left-Brain Professionals. Send an e-mail to stephan@sjmcopywriting.com to get a sneak peek and provide your feedback, which will obviously help improve the final version.

business development, craft, data and metrics

Critique My Code, Please

note, this article was originally published on LinkedIn

matrix-3109378_1280
Image by Jae Rue from Pixabay

 

ROUTINE ShouldYouHireAWriter(ContentCalendar, SubjectMatterExpertList)

DIM ContentCalendar AS array(ContentIndex, ProductionDate, ContentType, SkillRequired, LeadTime)

DIM SubjectMatterExpertList AS array(Name, AreaOfExpertise, WritingSkill, AvailableHours)

FOR EACH ContentIndex IN ContentCalendar

    FOR EACH Name IN SubjectMatterExpertList

        IF Professionals.WritingSkill < ContentCalendar.SkillRequired THEN

ShouldYouHireAWriter = TRUE

            CALL Hire(Writer(ContentType, SkillRequired))

            ENDIF

        ELSE IF Professionals.AvailableHours < ContentCalendar.LeadTime THEN

ShouldYouHireAWriter = TRUE

            CALL Hire(Writer(ContentType, AvailableHours))

            ENDIF

        ELSE ShouldYouHireAWriter = FALSE

        NEXT SubjectMatterExpertList.Name

    NEXT ContentCalendar.ContentIndex

END SUB

***

Let me Real-People-Speak that for you all.

For those who aren’t programmers, here’s what this says.

If you’ve got some kind of content your marketing team has decided is necessary to the essential function of your business (a Case Study, perhaps, or a blog post about a new product you’re developing for a growing market), you may want to get some outside help for that.

But – how do you decide whether or not to engage that outside professional? I have two criteria:

1) Do you have skill in that type of content?

Maybe you’ve never written a blog post before. Maybe you’ve never written anything before. Your skill is going to be defined not only by your writing skill, but your professional area. Are you a programmer? Maybe you shouldn’t be writing about end-user support, even though you’ve been asked to. If your skill is not up to what’s required of the piece of content, you should probably hire a writer.

2) Do you have enough time to do it?

Perhaps you’re neck-deep in requirements and coding for that very same model update that you’ve got to get out before quarter-end, and you know that taking ten hours of your time in the next month to write this stupid case study just isn’t in your budget. At that point, perhaps you need to spend less time writing and outsource that project. A good one could potentially cut your ten hours of drafting, revision, and review into a one-hour interview. What else could you produce in those nine hours? Might it be better to let you specialize there?

This mini-program essentially cycles through each piece of content and asks those two questions. Yes, it’s written a little facetiously. I know the syntax is probably way off, and there are clearly undefined subroutines that, should I try to get this to compile, would be throwing off errors like the Bad News Bears. Give me a break, I haven’t actually coded anything in like 6 months.

But the point is to show that there are pretty good reasons why you might look to outside help. And this routine would apply not only to writing content, it should apply to everything you do. [I use content creation because, frankly, that’s what I’m neck-deep in right now.]

First, evaluate whether your team has the necessary skill to complete the project upcoming. If not, you’re going to need some help.

Once you decide you do have the skill, determine if they have enough time to complete it. If not, you’re going to need some help.

And “need some help” doesn’t always mean hiring a professional to do that exact thing you want done, whether it’s building a retaining wall, shooting a promotional video, or even meeting with a client.

Sometimes, you might wish to hire another full-time person to do those specific tasks. Others, it might be that you should remove some of the lower-level tasks on your professional’s to-do list by reassigning them, thus freeing up more time in that high-level production arena.

The point is, you have options. Remember that, and don’t just assume that everyone you already employ can do everything. That’s why we’ve created this specialization economy, anyway. You should take advantage of it.

***

Stephan Mathys is a technical content writer for really smart professionals in the actuarial, data science, and engineering fields. You can reach him with questions about this article or his book, The Handbook of Content Marketing, at stephan@sjmcopywriting.com.

better language, craft, data and metrics

GIGO is a Sure Thing. The Converse – QIQO – is Nowhere Close

Garbage In, Garbage Out

–pretty much everyone who’s ever taken a course or read a book in the computer science, analytics, engineering, and data science worlds.

It’s a standard phrase: garbage in, garbage out, and we like it so much we use the GIGO acronym quite liberally. This, in contrast to some others, is actually a good use of an acronym.

The idea here is that if you have bad data, you won’t be able to get good results from your data warehouse, your model, your IOT devices, or whatever.

The phrase is supposed to be an inspiration to “clean up your data!” and make the “garbage” on the front end go away.

The purpose of this is to ensure that you have a “quality” product going in. The assumption is that simply putting quality in, we’ll get quality back out. If we rephrase, then, with the transformation from garbage to quality, we get “Quality In, Quality Out.”

But is this really true?

 

Nope. Not really.

Just because you have quality data going into your model, your system, or your process, that’s no guarantee that you’ll get a quality output. There are many reasons for this, but let me lay out just 3 for right now. I’m going to call them QIQO Fallacies, and hope that the phrase quickly becomes as ubiquitous as “Brangelina” or “WTF.”

 

QIQO Fallacy #1 – Solving the Wrong Problem

This happens when the stated problem is not the real problem. It shows up when someone, often far removed from an actual implementation team, says something like, “Hey, we’ve got all this data. I bet there’s a way to figure out how much [something] we’re [something else].” And then, the implementation team is tasked with figuring out the somethings and the something elses, but without a clear reason why.

Often this shows up because non-modelers have a very dim view of what data models can do, what they should do, and what they should not do. They assume that since there’s data, there must be something to be done with that data, and all you have to do is search long enough and you’ll find it.

Beware, though, of statistical anomalies that aren’t really there:

XKCD_jelly beans.jpg
from XKCD, a webcomic of math, sarcasm, and romance: https://xkcd.com/882/

How to fix it: Ensure that you have enough discussion before and during the model building that everyone understands the reason for building a model in the first place. It’s not enough to go just exploring. That’s likely to lead to spurious correlations that are not only wrong, they’re potentially dangerous to your business. Make sure you have a plan with a reason, and execute accordingly.

 

#2 – Solving the Problem Without Actionable Insights

This happens when you have a model that may answer the question that was asked, but the answers aren’t actually providing insight on how to change your future actions as a result.

Like, for instance, say you’re tasked to build a leading indicator model for some phenomenon that’s going to happen in a week or so. You give it your best and when you’re finished, you’ve got a great model! Your predictors give, with a high accuracy and small error bound, an expected range for the target value that’s going to show up in 6 or 7 days.

But – is that doing you any good? Do you have enough time to make any kind of shift or pivot to avoid that bad future?

7 days may not be long enough in some industries, like health care, geopolitics, or urban planning. And it might be an eternity in very short life-cycle industries like social media trends or stock trading.

The point is, whatever solution you’re searching for, needs to not only exist, it needs to be something about which you can take action. [Okay, that was a bit of a cumbersome sentence. Let’s try again.]

Just knowing about a future that you can’t affect doesn’t do much for you. You’d be better off not wasting your time on data preparation or model building if there’s nothing you can do to avoid those future predicted results.

How to fix it: Ensure that not only is your problem fairly well-defined when you start, you know that there’s a business reason for the solution you’ll deliver. Be clear that there are some actions that can be taken as a result of having the model outputs. Be confident that you’re not just building a model for the sake of a model, but that there’s going to be some insight about modifying the a priori future result which you’ll learn each time you run the model, and some kind of recommendation for different action you can make as a result of those insights.

 

#3 – Clogs Inside the Pipes – Bad Formulas and Poor Programming

This is the last one that I need to warn you about. If you’ve spent all your time figuring out how to appropriately “clean up” your data sets when they come in, and very little making sure that your model itself is up to code (ha! Get it? Up to “code”? I kill me.), you’re wasting your efforts. Because even if you have high quality data, running through an inefficient model isn’t going to be the best use of your time.

sewer-line-clogged-with-grease.jpg
Ew. Gross. Thanks “Len the Plumber” for this image I’ll never unsee. https://lentheplumber.com/blog/dig-dig-sewer-line-repair-replacement-options/

Essentially, if you start with a good data set but then send pieces through multiple transformations, ports, copy-paste steps, and generally bad practices, you’re introducing lots of different opportunities for inefficiency. If you’re setting it up so that output from one report is an input to another, you’re adding unnecessary steps.

Just like the clogged pipe above, if your model is forcing your data through unnecessary intermediate steps just to get a final value, you’re slowing down your process. You’re adding extra complexity, and you’re creating additional opportunities for something to break once you go live. You don’t want that. Bad models are just as bad as bad data.

How to fix it: Remember to always apply good modeling and programming practices (efficiency, parsimony, clarity, documentation, etc.). This is a way to ensure that once you do get your data sets appropriately identified and documented, you’re not slowing down the harvesting of insights (actionable insights, of course!) with poor modeling practices.

 

So, What Do You Think?

Am I way off? Or right on? Do you agree that QIQO is not guaranteed? Or do you think that we can get quality out just by putting quality in?

Send an e-mail to stephan@sjmcopywriting.com and let me know your thoughts. I’d love to have another professional debate this issue and point out where my thinking is off base.