Attention: As of January 2024, We have moved to counting-stuff.com. Subscribe there, not here on Substack, if you want to receive weekly posts.
The past couple of weeks, I’ve been working on a big process project that’s in its final stages. I was putting together a deck that presented what the future process was going to be, what the roles and responsibilities are, the steps, why this process is even necessary, and how it fits into everyone’s existing work with as minimal disruption. It’s been a very slow process involving making drafts, showing it to future leads for comment, seeing them misunderstand or raise concerns and having to revamp large sections.
Much of the problem was that it was just impossible to anticipate all ways people could go down rabbit holes when they encountered a specific sentence, diagram, or whatever. All these are signs that my writing and communication of my ideas just wasn’t good enough to get through to my audience. And I was there speaking to the slides and answering questions. Imagine how bad it would be if people were just reading it alone.
While we data folk spend the majority of our time discussing how we work with data, very few of us (with the exception of maybe the data vis folks) actually talk about who we communicate our results out to other people. We most certainly don’t talk about being effective at it.
Lets make a doc
Along the way in my process project, one good bit of feedback was to take the deck and turn it into a document to help with offline readability. The person who said that linked me to an example that someone else in the company had used for some completely unrelated purpose. A glance at the headings and flow seemed useful, so I took a stab at it.
Then I made the mistake of actually reading the doc itself.
To put it nicely, it was using very dry, technical language to explain why an old process was bad and why a new one was needed. Notably it was written in the sort of register you would expect from a sterile, government technical report. To put it much more bluntly, it was a giant pile of unnecessary jargon and I’m half convinced the author who wrote the thing liked how smart they sounded in it.
I had trouble finishing every paragraph because my brain would actively scream in frustration partway through. New terms would be invented. I’d frequently wonder what point a sentence was trying to convey. It took genuine effort to figure out just what every paragraph was trying to do. About halfway through, I was just thankful that I could stop and simply delete all the text out leaving just the heading skeleton and formatting.
I don’t think the problem is that I’m a bad or lazy reader either. I regularly dive into academic papers from all sorts of fields I have zero business reading and can largely parse them enough to write posts about their results and methods on this very newsletter. I don’t get nearly as frustrated reading those papers as I did for a single 1000 word process proposal.
Most infuriating was how this wasn’t some highly technical scientific process for which jargon might be justified. It was about how teams should be involving other teams earlier so issues are resolved before they become the problems they were experiencing. How can such a simple and reasonable conclusion to a very common problem be so painful to articulate?
It’s obvious that this author isn’t stupid nor incompetent. The stuff they propose make sense, and I’m sure their team implemented a new process and their work situation improved. But it also wasn’t a topic that should have required significant effort to read about. Surely, the communication could have been much better without sacrificing any of the content.
The worry for us here is, no matter how much effort we put into doing our actual work to gather and analyze data, the most critical part of our work is to “convince other people to do something”. Failing here would nullify everything that comes before. And we rarely pay any attention to it because it’s not really “data work”.
Judging your communication skills is hard without help
It is REALLY HARD to know where you stand when it comes to communication. The vast majority of people outside of school do not find themselves in situations where they get any constructive feedback at all. No one will tell them if their speech was terrible, nor their emails confusing, their proposals and slide decks uninspiring. This is because the broad range of “understood with difficulty” and “understood with ease” all results in the same external outcome of “understood and did what was requested”.
Every one of us are probably not as good as communication as we would like to believe. I’ve written over 150 of these long posts the past few years and just this week my docs were still a mess when shown to an audience. So how can we keep improving?
Obviously, feedback is important
I won’t dwell on this obvious idea too much. Suffice it to say, find someone you trust and have them look at your stuff and tell you what could be done better. Send it to your manager, your teammates, your friends The closer they are to your intended audience, the better.
What’s important is to make sure to ask them specifically about whether it’s easy to understand, whether anything confused them, and whether you should add or delete anything.
Ways to self improve
But what can we do on our own to improve?
Study examples
When’s the last time you seriously took the time to study a piece of work that you thought was good and figured out why it works? Take an particularly good email, slide deck, or chart, and consciously dissect why it seems good to you. It’s surprisingly difficult but this will give you ideas that you can try to incorporate yourself.
Let your work rest, then return to it
All good writing is the result of rewriting, and so taking a break and re-reading your own work will often help you spot issues or simply places you aren’t satisfied with. The break is necessary to give your brain some time to forget what you’ve done and approach it with fresh eyes. You’ll find a surprising amount of stuff this way.
Every newsletter post I write usually gets one or two revision passes (spaced a few hours apart) before I hit the send button, but inevitably when the published copy arrives in my mailbox in the morning, I find things I want to tweak or fix within the first couple of paragraphs.
Once, on a translation, I did six full revision passes over the course of two years before publishing and even then found even more issues that I wanted to fix later on. There’s no end, but the work does improve each pass.
Remember what the audience wants
At work, people aren’t reading emails and documents for the pure joy it gives them. Ideally they want to be in and out of a message as quickly as possible so they can accomplish what they need to do. Think of all the frustrated times you’ve heard a talk or seen a presentation where you just want them to get to the point already.
A lot of communicating well at work is stripping out the important stuff so that it’s quickly and clearly understood. If a 30-minute meeting should have been an email, a 3 paragraph email might ideally just be 3 sentences instead.
Selectively reference “style guides”
There are many books out there that claim to teach you how to write or make good visualizations. I’ve learned that you have be very careful in referencing these materials.
First, there are style guides published by various organizations. On my shelf I have a copy of the “Chicago Manual of Style”, which is used widely in the book publishing industry. It’s a giant tome with lots of guidelines covering everything from basic grammar to how citations, names, quotations, and other minute details are handled. I’ve also got the APA style book that’s often required for publication in many social science journals that does similar things. Other industries and organizations have similar style guides.
These guides are useful to know at a high level since they’ll cover things you probably haven’t thought about. For example, when should you use an em-dash? They’re not really useful for learning anything about how to organize your arguments persuasively, or even what sorts of words to use. It’s not necessary to refer to these guides unless you’re required to conform to them. So skip them unless you’re curious.
Besides those, there are books that discuss the actual writing process. As an example, in my younger days, I read and liked “On Writing Well” by Zinsser. What’s important to remember about these books is that they offer one person’s opinion about how to write well. They’re just collections of advice. If you read a bunch of these books, you’ll find that opinions and advice will differ and conflict. It’s important to pick and choose what makes sense in your own head.
The same applies not just to writing but data visualization. Back in the 2000s when I was learning about the topic, people kept referring Tufte’s series of books to me. I even have some of them on my shelf. I’ve never used them for anything because I found them to be intensely unhelpful in my work. There are plenty of people who both agree and disagree with me about the utility of his books and any advice found therein.
But regardless of how useful these references are in terms of advice, they’re a source for inspiration and a ways of looking at things you haven’t considered. It pretty uncomfortable to have to read through advice about a topic that you think you know and see how someone else has come to a completely different conclusion.
It’s up to you whether you want to incorporate their advice into your own thinking or not. But either way, I’m sure that you, me, and everyone else out there has lots of room to improve our communication skills. I highly recommend everyone devoted a bit more attention to fact.
Standing offer: If you created something and would like me to review or share it w/ the data community — just email me by replying to the newsletter emails.
Guest posts: If you’re interested in writing something a data-related post to either show off work, share an experience, or need help coming up with a topic, please contact me. You don’t need any special credentials or credibility to do so.
About this newsletter
I’m Randy Au, Quantitative UX researcher, former data analyst, and general-purpose data and tech nerd. Counting Stuff is a weekly newsletter about the less-than-sexy aspects of data science, UX research and tech. With some excursions into other fun topics.
All photos/drawings used are taken/created by Randy unless otherwise credited.
randyau.com — Curated archive of evergreen posts.
Approaching Significance Discord —where data folk hang out and can talk a bit about data, and a bit about everything else. Randy moderates the discord.
Support the newsletter:
This newsletter is free and will continue to stay that way every Tuesday, share it with your friends without guilt! But if you like the content and want to send some love, here’s some options:
Share posts with other people
Consider a paid Substack subscription or a small one-time Ko-fi donation
Get merch! If shirts and stickers are more your style — There’s a survivorship bias shirt!
One rec I've heard is creating a fictional persona that you need to write to, e.g. http://teachtogether.tech/en/index.html#s:process-personas.
Maybe it's helpful to say "this is for Patricia Project Manager" as you're composing.