Work-Life Balancing That Works

Image courtesy of Yuki Nakamura on Unsplash.

This week is the Cherry Blossom Festival in Washington, DC. It’s less than an hour by train from my house, and is arguably the prettiest harbinger of spring in the mid-Atlantic corridor. Saturdays and Sundays in the limited-run showing of the more than 3,000 cherry blossom trees are a chaotic influx of visitors from around the globe. Busy is a deep understatement. Crowded doesn’t begin to describe.

A fair-weather weekday, though? That provides nearly perfect viewing conditions for the gorgeous 1912 gift from Tokyo.

Alas. That would interrupt a work day. If I took the 2pm train to DC and wandered about the tidal basin for a couple of hours, the earliest I could be back home would be, say, seven p.m. assuming I stop for a bite to eat and don’t rush to ride the train home at 5pm with all of the commuters.

And yet – I’ll likely do it. I’ll feel no guilt about stepping away from my desk at 2, because it’s very likely I’ll sign back on at 7 or 7:30, and will have started my work day at 6:30 a.m. as usual anyway. I’ve been known to crank out some pretty great work at 10 p.m., or to manage some very focus-heavy work before 7 a.m. EST. I very frequently get some good writing done on Sunday morning, or a rainy Saturday afternoon.

Sometimes the 9-to-5 model of work doesn’t work.

Even before the pandemic, strict adherence to a 9-to-5 schedule was on its way out of favor. The onset of COVID-19 made it nearly obsolete not because workers were taking more time for themselves, but because working from home allowed them to take less. Throughout the pandemic, I’ve been working for companies whose workforces span international time zones, sitting on multiple continents. Working a traditional office schedule just no longer seemed pertinent.

There are days when I wake up at 5 a.m. and am energized enough to get started. There are other days when I prioritize going to the gym in the morning, meaning I won’t be at my desk until 8:30 or so. I am a fairly morning-centric person and I like the time to work without disruption from team members with questions or tasks. Working a bit on the weekend allows me the same kind of freedom from slack messages and time sensitive emails. Focus is good for this writer.

I’m not here to brag about my weekend work ethic, I assure you.

I’m here to point out that if you are super-efficient at 8 p.m. after you’ve put the kids to bed and are beginning to settle your mind into tasks you can handle, then by all means work at 8 p.m. But if you choose to do that, don’t feel tethered to your desk from 9 a.m. the whole way through, because that is where burnout happens. Burnout doesn’t come from logging time on a Saturday or before the rooster crows. It happens from feeling the need to be present at your desk even at your lowest capacity. If there are times of day that you are not productive, it’s likely those are the times you should go for a walk, make a grocery run, meditate, read a chapter from that book on your nightstand. You get what I’m saying.

Shed the idea that opening your laptop at 10 p.m. is a sign of overwork. If you provide room for “me time” when it is best for you, then you can also provide “work time” when you are at your peak.

I get it, sometimes you simply must be present for the typical work day to answer emails, attend meetings, and all of those necessary elements of our jobs. But there are other times when you can totally work “outside the box,” and not only should you, but you should also then take advantage of offsetting your time.

Take some time to smell the roses.

Or the cherry blossoms.

Advertisement

Minimum Viable Documentation: the Bare Minimum Doesn’t Have to be Bare.

Do less with more.

Practice minimalism.

Do “documentation triage.”

All of these are concepts we’ve heard about, and have been tasked with understanding and implementing across our documentation practices. But what are they and why do they matter? And how will creating “Minimum Viable Documentation” impact what we do and how we do it?

We learned ages ago in the software development world that “perfect is the enemy of done.” That applies to writing as well. We can move participles and conjunctions around all day and still never achieve perfection. As a professor, I told every single one of my students, usually on day one, that they would never receive a 100% on any paper they submitted to me. I wholeheartedly believe that there is always room to improve. I think the best writers throughout the history of time would agree with me. As a teaching tool, I often used e. b. white’s “Once More to the Lake” as an example of how revisiting a piece of writing many years later can fundamentally shift it to the better without trying to change it in tone or style whatsoever.

So how do we create documentation that is good enough without sacrificing our standards?

The first step, according to esteemed technical writer Neal Kaplan is to “prioritize ruthlessly.” It’s vital to look at what actually needs to be documented, and focus on that. The rest is, as they say, gravy.

When we are early in our writing careers, and sometimes just when we are early in our writing projects, we think it is important to document everything. No step or function should be relegated to the trash heap. We fail to plan, and therefore plan to fail. When we look at documentation as a broad-sweeping need for users, we miss the point. We lament that no one reads the documentation, but we keep writing it. Why? Are we hoping users will do an about-face? They won’t. Ao as my high school English teacher reminded us time and again: plan your work and work your plan.

That planning is what Kaplan calls triage. I just call it good practice.

  1. Start planning long before you start writing.

2. Give every task an estimated level of effort – even if it’s a guess, start guessing.

3. Use documentation architecture – design your plan, and plan to grow.

4. Stand by your plan,but be open to changing it.

See how not all of those numbered items are aligned? I chose that architecture because the first one is vital, the others then follow. Plan. Plan. Plan. They are each important, though. Following these 4 will result in documentation that gets the job done, doesn’t leave bare spots, but isn’t full of extra bells and whistles.

You’d never hire a contractor to work on your house without an estimated level of effort. You want to know how long that project will take, how difficult it will be. Your contractor lets you know it will be a couple of days, or a couple of weeks. It is an estimate and it is not a firm commitment, but it sort of time-boxes the work to be done. It’s rarely spot-on. You might have an architect that shows you how fantastic a skylight would be, but once your contractor starts the work, he tells you that will be a challenge to complete based on the roof, the seal, whatever. So you nix the skylight.

Your contractor takes a dive into the work and then recognizes that perhaps you would prefer the sink on the other side of the room, or maybe you want a different fixture than the one you saw in the store. You can put your foot down based on time, cost, and aesthetics. It may be that the extra time required to purchase a new fixture will change the look of the room enough that the pivot was worth it.

On the other hand, maybe the new fixture is out of budget or will take too long to install. It’s something you can see having installed in a year or two, but it isn’t necessary right now. Okay, so you know that down the road you have some more work to do, but getting the standard fixture installed keeps you on time, on budget, and your rom is usable.

Usable.

That is the key word in all of this. Usable.

Our “bare minimum” is hardly bare when our documentation is usable. Minimum viable documentation is choosing to follow the design plan your architect and contractor gave you, but adding all of the decorative touches later. You’ll have a fully functioning and attractive room with the key elements. You can add the flourish later, if you add it at all.

I’ve extended this metaphor about as far as I want to, and if I continue to write I will violate the basic principles of conciseness. Tell your teams that Minimum Viable Documentation is not the writing equivalent of a rough draft. It is the equivalent of writing a 2-page paper when you recognize that a dissertation is unnecessary. You can be sure that every comma, bullet, and number is correct if you write briefly. The viable minimum is so much better than the bare minimum, and worlds better than the alternative.

How We Write: Inclusive Content is Content for ALL

At a company I worked for a few years ago, I first heard about the concept of “the golden thread.” Essentially, the “golden thread” is a metaphor for the decisions, behaviors, and processes that provide the connection between strategy and actual results. It’s interesting to think that the objective could be something like “to improve the environment” and that there is a thread that could guide you along that path. Or an objective like “to own a home in my city” knowing that, sure enough, if you follow the thread one day you will hold the keys to your own front door.

For a technical writer, the notion of a golden thread should be much more than just a content thread. We employ those all the time. A document that outlines a process, from start to finish, should have a thread running through it. A Standard Operating Procedure manual should have an easily identifiable thread to follow from one process to another, weaving through an entire organization. The metaphor is not difficult to picture.

Although easy to spot in some instances, the notion of a thread tying together so much that it leaves no one out is more elusive. And yet, it is essential in today’s communication.

As a content strategist, I try to be mindful of all of the aspects of inclusivity as I write and design. My audience can vary from newcomers to the product I write for to highly experienced users. I write to the needs of engineers and data scientists, but also new adopters and first-time visitors. But experience level is not the only area where I must think of inclusion. That part is actually the easier lift.

Where inclusivity matters in technical content is in writing in a way that every reader can understand. In best-case scenarios, someone has come before and prepared a thorough style guide that captures clear writing, because writing clearly is more than minimalism. Cutting away formal words when less formal ones will do is one step in the process. I choose to write “let” rather than “enable” – as in “this product lets you plan your wedding” instead of “XYZ software enables you to plan a wedding.” Right?

Erwin Steinberg of Carnegie Mellon University was the first scholar to champion what he called “plain English.” Casting aside passive voice and professional jargon, Steinberg argued that writing simply and plainly was the best approach to complex concepts. His thought prevails today, especially when writing inclusively.

Today, many readers are approaching documentation with some accessibility issue. From low-vision to color blindness to dyslexia, the number of reader-centered accommodations is vast. One would think it would be impossible to consider all of them. And one would be wrong. By choosing to write pages that do not have complex markup that a screen reader wouldn’t understand, you have chosen inclusive writing. By using proper and bold headings, you allow those with low vision or attention deficits to more easily scan and identify chunks of information. Including images only with a corresponding text description assists a wide variety of readers and adds to easy clarity with little effort on the writer’s part.

It’s important, as a content designer, to consistently test and modify documents. There’s no such thing as the perfect, complete document. (Remember, perfect is the enemy of done.) Knowing this, though, it’s equally important to revisit your writing and your language choices as regularly as possible to see where you can improve. Scheduling regular reviews of your own work is the best way to see where you missed and where you didn’t.

When creating content of any kind, keep a few numbers in mind:

  • 26% of the US population has a disability
  • 20% has a mental illness
  • 5% is LGBTQ+

So what does this mean for writing? Glad you asked.

  • Monitor cultural references that not everyone will understand
  • Use preferred pronouns when writing personally, neutral pronouns whenever possible
  • Don’t assume that readers are heterosexual, male, female, young, etc.
  • Use gender-neutral professions and titles (e.g. firefighter, not fireman)
  • Never assign a gender to a quality (that is, strong is not manly and feminine is just off-limits)
  • Add detailed descriptions for links, not just “click here”
  • Never use ableist language (lame, blind, dumb)
  • Don’t swap out mental health assignations for daily emotions (someone who is meticulous is not OCD)

Along with these practices, keep in mind that shorter is better, jargon is awful, and if you have to use some fancy words you should build a glossary. Never rely on a stereotype and don’t assume a joke is funny to everyone. Absolutely choose welcoming topics, consider readers’ needs, and look for ways to improve every day.

When all is said and done, if you aren’t sure – ask. Rarely do people who are asked for their input respond poorly. People who are not considered or included – now they can get a bit (justifiably) upset.

Write on.

AI Isn’t Out for Your Job

Because We Can’t Even Agree On What It Is

Photo courtesy of Possessed Photogrpahy.

There is such a swirl of discussion around Artificial Intelligence and whether it will supplant human work. This largely stems from a real misunderstanding of what AI is and what it can do. According to IBM, Artificial Intelligence is: “the science and engineering of making intelligent machines, especially intelligent computer programs. It is related to the similar task of using computers to understand human intelligence, but AI does not have to confine itself to methods that are biologically observable.”

There’s a lot packed into that definition. No wonder people don’t know quite what to make of it!

It seems to me that the biggest challenge is that people mistake Intelligence for Sentience. While humans certainly possess both, it’s not even a realistic goal in some ways to presume that we can master Artificial Sentience.

What do I mean by this?

In a nutshell, “sentience is the ability to feel, sense or experience perceptions subjectively. Those working in the field believe that capability to be decades away, if achievable at all. Building self-awareness into a machine is an unlikely undertaking, anyway. To reach that state, researchers would have to build programs that achieve generalized intelligence, a single learning machine with the ability to problem solve, recognize environments and changing requirements, and the capacity to learn more. Once that capacity is established, the next step is just reaching the edges of the potential ability to learn consciousness.

Therein lies the rub. A machine is unlikely to “learn” how to “feel,” since the uniquely human capability of complex emotions is perhaps the ultimately most difficult thing to teach. Just as a machine has no conception of physical pain or healing, the ability to feel attachment or loss is not necessarily a programmable skill.

No one in the field claims that a Roomba has any particular attachment to the floors it vacuums, despite the fact that it does indeed learn what the obstacles to successful vacuuming are. No one believes that a robot vacuum enjoys the sensation of a 120-volt charge running through its wires, even if we imagine those wires to function much like veins.

Robots still can’t feel.

Robots can mimic, absolutely. They are fantastic at aping what humans do, if they are taught to do so. Within series after series of If/Then statements, a computer can perform all sorts of functions. My robot vacuum “understands” that If there is a chair leg in the way, it should rotate 30 degrees and try again. If the block is still there, it will rotate again an again until it is able to move past the obstacle. With the most recent robot vacuums (to stick with this example), the vacuum “knows” that the chair is there and “learns” to avoid it, unless it arrives at that obstacle and finds it has been moved. That said, the vacuum is not frustrated by the obstacle, nor is it relieved when the chair is moved to another room.

I think of it often as similar to what I learned in my first college linguistics course: animals can communicate, but they do not have language. That is, my dog can let me know when he is happy, but he cannot tell me that his father was poor but honest. Machines can learn, but the challenge is that they cannot emote. They can mirror emotion, sure, but to have original and unique feelings about their situations? No. At least not yet, and not for the conceivable immediate future.

But that does not mean that machines cannot learn. They very much can. Just as a third grader can sit quietly, ingesting information and retaining it for future reference, a machine can do the same. A student learning multiplication tables soon learns that 5 x anything can only result in a number ending in 5 or 0. A machine has the capacity to learn and retain that information and apply it to millions of situations, millions of times faster than the human mind can do. A machine can aggregate vocabularies, numerical sets, geographic data, and more – all at a rate far more effectively and efficiently than the human brain.

That’s why machine learning and artificial intelligence are thrilling and fantastic.

But until that computer program can harness things like anticipation (that the car in the next lane is looking like it will merge into yours), or fear (that the spider crawling up the side has the potential to cause damage), and responds accordingly, our jobs are all safe. Machines can certainly learn to edge over if a car is too close or to restart if an interloper is nearby, but it does not have the capacity for self-awareness.

We mustn’t confuse intelligence with sentience, and if we do that, we’ll soon welcome the advancements of AI and machine learning, harnessing them for what they are.

But remember, too, that until the machine can understand notions like initiative, relaxation, and joy, it remains a tool for us to use. And remember, too, that it may well be the mindless robots may be our biggest threat, not the ones that could one day feel and thus bring us things like helpfulness, empathy, and emotional support.

Susan is a technical content strategist and researcher of all things automated. She lives in Baltimore with her two dogs and snuggles with them when she’s not on her bike or swimming laps in the pool. She is an avid traveler and reader of nonfiction. Subscribe to this blog to learn more about technical writing, communicating, and machine learning within those domains.