How to deal with people who will not read?

Question

I work in a field where you can get sudden requirements to communicate a lot of highly technical stuff from time to time. Sometimes this stuff is really involved. Like, you can chat with people about it, but you know that the next day you won't have covered all the angles, and half will have been forgotten.

The problem I am experiencing is that some key people will not read. These are highly capable, technical people, but they just will not or can not study technical analyses. They claim they have, but you can just see they have gleaned nothing from it.

What can I do to help them digest the information I need them to digest?

Answer 1

I struggle with this problem all the time. I've even asked about it here, only to get the question closed, downvoted, etc. I suggest that you give up and let them fall on their face. Or if they are not a total loss, then meet with them in person.

People who won't or can't read, do so for a reason. That could be apathy, illiteracy, the epitomous "busy", or that they sign your paycheck and think that you should do your job without bothering them.

If other people aren't willing to or can't make the effort, all the tricks from the other answers won't help you. They're good tricks, and will apply to people who are able and willing to read and/or be collaborative. However, the people that you're having problems with will only find such tricks condescending, or be irritated simply because you presented them with written words.

Source: Experience.

Answer 2

It sounds as though the level of intricacy and detail of the documents you are writing are above my current pay grade, but as a former middle school teacher I have a few tips that may help. (I had to get kids to try and read too!)

1. Try creating an outline or bullet point list that will highlight specific aspects of the document you are wanting them to read. By highlighting aspects, and even having open-ended questions in the bullet points, you are allowing people to reference main points of your document. If you use a question in the bullet point it helps to influence the reader to try and answer it for themselves.

2. As silly as it sounds, bold and italics are a great way to attract the reader's attention and emphasize what you are trying to convey.

3. Sharing documents and adding comments by shared users allows you to see who is paying attention and who is contributing. If the comments are turned on in Google Docs or other shared applications you are able to gather input from other people who are contributing.

4. And last, there's always good ol' conversation. Ask the people who seem to be slacking if there is a reason they're not fully engaged. Express the importance of documentation, follow-ups, and the attention to detail. Hopefully they are mature enough to understand the importance as well.

Answer 3

Perhaps part of it was your writing style.

I have read and answered many questions on this site, but yours was, in fact, difficult to read. I'm wondering if this has something to do with it.

Even Einstein said "Make things as simple as possible, but no simpler".

• Get down to the level of detail that is necessary, but no more detail than that.
• Break things down further into the smallest pieces to read. Make sure your fonts are large enough, the colors in any charts are clear and that the data is meaningful.
• Break things down into bullet points if possible.
• MAKE IMPORTANT DETAILS STAND OUT
• Solicit feedback from your audience.

The problem may be in your presentation. Rule that out first before you ascribe any laziness to your coworkers.

If it is in fact your presentation, at least that is something you can address. Laziness, not so much.

Answer 4

Amazon has a fascinating technique to address a related problem... Don't expect people to pre-read your complex ideas, they simply can't give it the attention it deserves, they're too busy. Instead, write up an executive summary of what's being proposed/decided, call a meeting, have everyone sit there and read it together, then they can ask questions afterward.

"No PowerPoints are used inside of Amazon," Bezos proudly declares. "Somebody for the meeting has prepared a six-page...narratively structured memo. It has real sentences, and topic sentences, and verbs, and nouns--it's not just bullet points."

In his recent letter to shareholders, Bezos details the work that goes into these memos, which he says may take up to a week or more to write and refine:

"The great memos are written and rewritten, shared with colleagues who are asked to improve the work, set aside for a couple of days, and then edited again with a fresh mind. They simply can't be done in a day or two."

[...]

"We read those memos, silently, during the meeting," says Bezos. "It's like a study hall. Everybody sits around the table, and we read silently, for usually about half an hour, however long it takes us to read the document. And then we discuss it."

Answer 5

Don’t make them read. I’m not sure if this can be applied directly to your current situation. The thing that stands out to me is that you want people to be able to become experts on the problem on the first go at the issue or to keep re-reading until they understand. That’s novel, but as you’re experiencing, unlikely. There probably isn’t enough time to do that.

I think a good thing that you might be able to do is diagram or draw whatever these things are instead of trying to textually describe them and all the intricacies.

I work with a lot of website front end pieces and sometimes those pieces can have a lot of underlying business rules and corner cases. The times that the most defects are generated are when we have to build from a great big word vomit user story that lists a mountain of requirements meaning that even if you read, re-read, and even read again, you’re likely to miss something key.

One project, we had user stories that actually conflicted with the graphical design document. More often than not, what was actually implemented was implemented according to the design doc because that could be understood much more easily and at a glance. It had flow graphs, UI mockups, and expected functionality, but the source of truth was supposed to be the actual user story even though those were way more difficult to read.

So the first thing that I think would help is if you tried to get everyone to whiteboard these processes and graphically documented them instead of writing long, boring, volumes of text.

---

I started working with library called Rx that deals with plumbing data about in a functional, reactive way. I read documents until I was blue in the face about how the plumbing was supposed to work. However, what really made the whole thing click were the marble diagrams that explained what data was going where, when, and why. These diagrams are part of the core documentation and every operator/function in the library has a diagram that matches the textual explanation of the feature so that you can quickly understand the thing you are trying to get a grasp of even if you’re just skimming.

Take a cue from that and try to find a way to allow for birds eye views to give a good enough vantage point of what you’re working on but also entices reading the detailed description as well. You say that some of the things you’re trying to detail are things like mathematical proofs, I would think that there must be some way to describe these things “in action” or applied such that someone can get a ballpark understanding of the concept and use the long form text description as a way to fully understand what’s going on.

Maybe I just like books with pictures.

Answer 6

In addition to @MacItaly's great answer, I want to add an additional point:

Make your main point right up front. The first thing someone reads in a long document should be a summary of what the document is about. The first sentence of every section should drive home the point that section is trying to make. All the details that hold that idea together can follow after that.

It's tempting to write a narrative that builds and builds to fulfilling climax before coming to a final conclusion. That's how good stories are written, and really, even the most technical documents are just telling some kind of story (even if that story is as dry as the operational temperature limits of widget Beta-5A). But it's not a good way to convey information you want your readers to absorb because it buries the main point in a wall of text. Don't make your readers dig for the point you are trying to make or their eyes are going to glaze over before they get there (this is especially true in a dry technical document). State it right up front, then fill in the details that support that point.

Answer 7

As a technical writer and document manager, I write and go through a lot of highly technical documentation and expect users to read them. You can't make people read. But, there's two things I've learned to help people get through them with the important information.

1. write for someone just off the street.
2. pictures, lots and lots of pictures.

For item 1. as mentioned by others, bullet points, tables, bold, highlights, that kind of thing really helps to draw the eye to the important parts. Sometimes it makes the document longer but if someone that doesn't know details already can be drawn in and grasp the most important bits, it helps.

Item 2. I don't mean just pictures, but diagrams, flow charts, icons (like in the "for dummies" series) code snippets, whatever. Again it helps draw the eyes, but it also helps those who learn visually, not through reading.

Also alternate between these and the placement on the pages. These things also help people go back later to maybe look in-between them to find the important bits.

TLDR: don't just give a wall of text and expect people to find the details in it. Break it up so their eyes can catch what they need.

Answer 8

I struggle with this in my current job as well. It's difficult to get an answer out of seemingly nearly everyone in the company via email. This is compounded by having a satellite office hundreds of miles distant. We hold Skype meetings with them, but it doesn't seem to help much. I've resorted to sneaker diplomacy, get up from my desk & go talk to the person that I need information from in person. Of course trying to do that over Skype is iffy at best.

One of the better things I learned in the US Navy with regard to communication was:

Tell them what you're going to tell them. IE: Executive summary or TLDR

Tell them what you wanted to tell them.

Tell them what you told them.

Even with this approach, we still run into issues with people who never read the email detailing changes we've made to their software and why and we get questions. However the flip side of that is also true, my company has a stellar record of finding workarounds when something doesn't do what it's supposed to and don't bother to file bugs about the original problem because they've found the workaround. So we won't even know when something is broken.

EG: One time one of our automated calibration machines stopped running calibrations. Our techs switched over to running the calibrations by hand (much-much-much more time intensive, and human error prone) and never told anyone about the machine not working properly. A year goes by, lots of overtime is happening because they can't keep up with the work load. My colleague (who used to be a calibration tech) happens to be in the calibration lab one day and notices that nobody is using the automated calibration software and asks why. The techs explained that it'd been broken for "a long time" and they just did it manually instead. Five minutes of investigation showed that the hard drive was full, packed solid, so every time the software was started, it tried to write a file, couldn't, errored out (saying that it couldn't write the file) and quit. This is by design, if you can't write to the files you can't process a calibration. He deleted about ten years of log files from the machine freeing up several gigabytes of data, and voila, the automated cal machine started working again.

Answer 9

I work in a field where similar situations arise. Unlike many answers and probably on the lines of OP's question, it's important to notice that it' not always about your writing. There are technical documents and commercial proposals from third parties that people need to read.

The problem is, if you are the only one reading a document, then nobody values the effort you put in.

The mitigation are case-by-case and depend a lot on your level of authority within the company. If you are a new employee, I'd suggest calling meetings to discuss documents where your highlights are shown in a presentation. You get your point across, but people may still not read the thing. If something you wrote requires attention, don't expect everyone to read in detail (specially if it's something you haven't yourself proofread once), ask a trust worthy colleague now and then, maybe reach to your manager saying something on the lines of "this report needs a reviewer, but I know it's pain to do so, therefore I don't feel comfortable asking a colleague as if it was his favor to me...". If the reading work is actually necessary the manager should assign someone with the reading task and take note if the person does a proper job.

Note however, that maybe all this reading may not be as important as you think, and possibly not everyone has to do it for all reference materials.

If you are a manager, there are other ways to cultivate discipline in the team, but from the question text, this seems not to be the case.

Answer 10

Application and Iteration

Already a lot of good answers have been given. I'd like to focus on the information handling process instead of the information presentation.

People need time to digest complex information. Even with a very good presentation not all information will stick. A good way to learn is by application. To get it all to stick a process of multiple iterations of reading and application can be used.

An example of a process

1. Read to get the main ideas.
2. Try to apply the ideas
3. Get stuck.
4. Re-read to get the details. New experience will help to understand
5. Try again to apply

Repeat steps 3-5 till the information is processed.

Answer 11

First of all, if the amount of technical material is large, it's not going to be possible for most people to take it in quickly. I remember back in grad school it typically took me 2-3 hours per page to read and really understand highly technical material.

That said, there are two general classes of documentation --

1. Documentation that someone just wrote. Such documentation will contain unclear writing and even outright errors. The best way to understand what is intended is typically to write unit tests and to ask questions when something is unclear. I'd encourage them to do that. Then if you give an answer, they can be expected to show their understanding of that answer with a unit test.

2. Documentation that has been around a long time. In that case, a community will exist. You may be able to encourage them to take their questions to that community.

Lastly, if you are able to read and grasp such things quickly, remember that you have an unusual talent, and not everyone can do that.

Answer 12

Mathematical proofs are hard to discuss verbally, though I'm sure I'm not fully imagining your situation.

My suggestions:

• Request written responses in the form of annotations to the original document

Giving people time to read the documents, and then write down their thoughts, can help you get more formal, attentive reading sessions from these people. The annotation style makes sure that they are connecting their responses to actual portions of the original document (less scope for misunderstandings, and those that are present will be easier to find).

You mentioned in comments that the people you are describing might prefer not to respond in this way, but it also seems like their preferences are not tenable for you. If you have to make them engage more, this might be a way to make it happen.

• Write collaboratively

People can blow off reading something. That's harder to do if you're writing that thing. If these people are responsible for certain sections, or if you have meetings where everyone goes over sections together, you can probably get them to engage more with the documents. It's sort of like supervision, but very light.

• Ultimately, you can't force intellectual effort

This is more of an aside, but you can't make people think, and there is generally a limit to how much you can condense precise information. If they are not driven enough to do this on their own, then adding some sort of incentive for them to do it might be the only way to get them to volunteer the effort. Some mechanism for rewarding the effort (or punishing failure to make the effort) might be necessary.

Answer 13

Slap an Executive Summary on it

I worked in a region of the world where reading was not tradition, and nobody would read before endorsing/adopting my documents/programs.

So I put a powerpoint (simple bulletpoints with pictures) of the summary, bound it, made it look pretty and attached it to the top of the full document. Staff reviewed it for accuracy and completeness, decision-makers read the 10-slide pictograph.

Answer 14

Mefitico's answer contains some excellent points, but I also wanted to posit that the incentives for reading the documents may not be appropriately weighed. You mentioned that there isn't a manager in this situation, but presumably there's some evaluation of performance -- if a "deep reading" of the materials doesn't provide enough benefit relative to charging ahead anyways, people will optimize by avoiding it. This suggests that the deep reading isn't actually required to do the job effectively, or at least it's not measured as such.

As an engineer, one thing that helps me at work is if there's a way to tie-in the tangible goals with the required understanding of the materials; that's one way to ensure that relevant parts of the document are read. For example if the goal is "run Algorithm XYZ on data sets A, B, and C" and you have a write-up about Algorithm XYZ, that's probably the fastest path to finishing that goal. But if you asked me to read the same document on Algorithm XYZ without actually allocating time to read it or a goal to tie it with, it will be very low on the priority list.

Answer 15

Simple, just remind them where to read the information every time they have a problem with it or every time they don't know it. Eventually, through the power of repetition, people will start to just associate reading with learning.

Other than that you need to make sure your documentation is well written, otherwise no amount of RTFM(Read The Full Manual) is going to make someone read it; people will not read things that make their eyes bleed.

Answer 16

The fault lies in the reader or in the writing, or both. Since your question doesn't really suggest what the problem is, it is hard to suggest a solution. You say the readers are competent, but leave open whether they are refusing to read or are unable to read the material. If the former, the question is why? (Time constraints? Lazy? Other things are more pleasurable?) If the latter, that suggests they are not competent.

What you can try to do depends on how much you can influence the author(s) and/or the reader(s). If the issue is strictly a communication issue, an excellent book is "How to Read a Book", by Mortimer J. Adler. Use the information in there to encourage the authors to make life easier for their readers by writing well, and to encourage the readers with tips on how to do a better job of getting the most value out of whatever it is they are reading. There are general principles that apply even to works that are not books. I can't recommend this book highly enough.

Another guide to writing well is Strunk and White's "The Elements of Style".

Answer 17

Some perspective from the other side of the fence:

In a previous job I had a lot of documents I "needed" to read. Typically requirements captures design documents etc. I often didn't read them past skimming.

Why? Well often "needed" in this context was: "helped the author".

For example, they wanted their design to be used as it got them credit and reinforced the "I solve the hard problems, they just implemented it" view of the process. If this is the case: great. But then you don't have a problem. I read the document because I have too. In practice, often the document was either:

• Fluff that really just restated something that the author was given (that I had access too).

• Not complete enough to use.

• Was sensible and reasonable, but:

  • Didn't apply to the way I was going to interact with the project.

  • The situation had already been deviated from and difficult to "get back on track".

• Sometimes: Wrong, contradictory or silly.

After I while started ignoring vast swathes of stuff I probably should have been reading and making my own way as, on average, this seemed to work better for me.

It's worth noting a few things:

• That doesn't necessarily need to be the way it is, just the way its seen.

• It doesn't necessarily need to be anything you did. Once the mindset of: "this is just one more thing I need to pay lip-service to before I can get on with fixing things", you will be fighting an uphill struggle. Not only because they won't read it to find out, but it will colour how they read it when they do. For example, you stress they need to read the documents. With an open mind, this could easily be read: "There will be significant downsides in not doing so for the business/project, that I haven't included because they aren't relevant/necessary." However, my first thought was the sceptical one I am warning you about. I can't know, but once you start seeing the patterns...

• While the time spent reading was a factor, it was only a very small one. It's frustrating to be told: "do it this way, with that result" when the two are mutually exclusive, no matter how succinctly you put it.

So, what can you do:

Ask nicely and it explain why it benefits everyone/them. This never hurts, and if its a question of motivation, especially if the problem is they perceive themselves as outside the loop this, can go a long way.

Get, feedback if you can, as to what it is that's causing resistance. It may well be something that's impossible to fix like they just don't care about any of it, but I would think that's unlikely (if they really didn't care, they wouldn't come off as technical and competent, that requires at least a bit of commitment). I think it's far more likely that it's something you can fix. I clearly can't speak for everyone but: I can't see myself being reluctant to share my objections, and figure out how to progress, in a forum that I thought was about fixing the issues, not assigning blame.