Editing a background check policy

We’re implementing a background check policy for some roles at Tidelift, because we see security-critical information from our customers. Our background check provider (who I won’t name, because this isn’t about them) has a template policy that is pretty good! But the rest of their product has a very high standard for UX—their designers generally do not settle for pretty good.

https://www.flickr.com/photos/28681973@N00/25648519032

Since I know they care, and since employment documents (especially ones that relate to bias) are an important way Tidelift communicate about our company values, I took the time to send them my changes. Having done that work I figured I’d make it a blog post too :) Some notes:

Consistency between software and legal documents

A legal document is, in many cases, a part of a company’s user experience. As such, it needs to be vetted for consistency with the rest of the software, just as you’d vet any other part of the UX.

This is hard, and easy to screw up, because let’s face it—who likes reading and re-reading legal documents? Not even lawyers, if we’re being honest. This particular document screws this up in two ways.

First, the tool (very correctly!) encourages companies not to do a background check for every position, since that introduces a significant bias against people who may have been rehabilitated and should have a fair chance at employment. But the legal document says very plainly that “all offers of employment are contingent on … a background check” (emphasis mine). The legal terms must be brought into alignment with the software’s reality.

Similarly, one of the benefits of this tool is that it takes care of the paperwork for you—without pens and paper. And yet the legal document says that a “signed, written consent will be obtained … in compliance with … law”. Now, good American lawyers know that under the E-SIGN Act of 2000, lots of digital things are “signatures” for the purposes of American law, but most people don’t know that. Good drafting will avoid confusing these non-lawyers by simply saying the consent will be “explicit” and recorded by the service.

Multi-clause sentences and checklists

This is not always the case, but many sentences in legal documents would benefit from being broken up into bullet points, so that each criteria is easier to follow or even treat as a checklist. Consider the difference between:

A decision to withdraw an offer of employment will be made only after conducting an individualized inquiry into whether the information obtained is job-related and a decision to withdraw an offer is consistent with business necessity.  

Original policy

And:

A decision to withdraw an offer of employment will be made only after conducting an individualized inquiry into whether:
– the information obtained through the reference check is relevant to the nature and performance of the role; and
– withdrawal is consistent with the business’s needs.

My revisions

This sounds sort of trivial, but clear writing really can help you spot errors. In this case, breaking up a sentence into bullet points made me notice that the document was inconsistent—an important anti-bias process step was listed in another section, but silently dropped in this list. So someone skimming just the one section of the policy might get it very, very wrong. (Programmers reading this will be nodding along right now—this is debugging by using better formatting to ease code inspection.)

Similarly, where a process is spread across multiple paragraphs, consider using numbered bullet points to emphasize the checklist-like nature of the process and improve the ability to discuss. Much easier to ask “did you do step 4” than “did you do the second clause of the third sentence”.

Q&A style

I continue to believe that many legal documents should at least be edited (not necessarily finalized) in a Q&A style—in other words, changing each section header to a question, and making sure the section actually answers the question. I talked a bit more about that in this post about doing it for a draft of the Mozilla Public License.

In all cases, doing this forces you to make sure that each section has a focused, clear purpose. For example, in the original draft of this policy, there was a section titled “Evaluating Background Check Results”. Revising that into a question (“How will we evaluate the results of the background check?”) helped me realize that one sentence was about a related, but different topic—privacy. Breaking that out into its own privacy section both clarifying the original section and allowed the new section to respond more forcefully to employee concerns about confidentiality.

In the best cases the Q&A framing can really help understanding for non-legal (and even legal) readers. In this case, I found that a well-placed question helped differentiate “why the company does it” from “how the company does it”—which was muddled in the original draft, and important to aid understanding of a tricky anti-bias concept.

Be careful about definitions

Last but not least—you can often tell when a document has suffered from copy/paste when it uses a defined term exactly once, rather than multiple times. Not only does this give you the opportunity to remove the defined term (in this case “Company”) but it also reminds you to give extra focus on the ways that term is used, since it is likely to have copy/paste problems. (In this particular case the stray “Company” thankfully didn’t point to anything worse than jarring word choice—but at least it was easy to eliminate!)

Interested in learning more? Come work with me!

I can’t promise we approach everything with this level of detail; we’re still a small startup and one of the ways we balance the tension between pragmatism and idealism is to Just Get Things Done. But I’m also proud of the way so many of us think through the things some other companies get wrong. If that sounds like fun, we’re hiring!