Always Give a (Good) Reason
tl;dr Whenever you ask for something, giving a reason will:
- get you better responses;
- reduce people's feelings of being told what to do;
- teach your clients to help themselves next time; and
- allow you to check your work.
Whenever I ask for something–information, edits to a document, a change in behavior to comply with laws, or a different approach from my team–I give a reason. Not everyone does this.
Here are four reasons for always giving a reason.
Get Better Responses
You ask your Head of Litigation, “How much did we spend on outside counsel last year?”
There are many potential correct responses, each depending on the context. For example, are you asking because you need to help the Controller close the books on the year, does your GC friend want a point of comparison, or are you forecasting spending for next year?
Your Head of Litigation needs that context to prioritize the response and answer with the right amount of precision.
Similarly, imagine asking your Product team to change the user sign-up flow to present the Terms of Service " prominently." “Hey,” you Slack, “could you change the font color of the Terms of Service link on our login page to green, blue, or red?”
Among other things, Product won’t know how urgent this is, what the consequences are for not doing it, and whether there are different ways to solve the problem (perhaps by changing the font size of the Terms of Service or making it bold).
In contrast, providing a reason gives Product the information to respond wisely. “Hey, to create a binding Terms of Service that limits our liability, we should change how we present the Terms of Service link on our login page. There’s a new precedent about what constitutes sufficiently clear notice of a Terms of Service link. One thought I had was that we could change the font color, but the standard is that we need to make it ‘prominent.’ Let me know if you have other ideas.”
Reduce Bossiness (Reactance) and Show Respect
People don’t like to be told what to do. Psychology researchers have studied this (of course they have) and given it a name: “Reactance.”
Whenever you ask for information, an edit to their document, or a behavior change, you are telling them to do something for you and, as a result, trigger reactance.
However, when you provide a reason for your ask, reactance decreases. With an explanation, you are no longer telling someone what to do, you are instead partnering with them to complete a shared goal. For example, “Can you get me the amount of outside counsel spent last year? I’m asking because I need to create a forecast for next year, and I would like to use previous year’s spend as a benchmark.”
Teach Your Clients
Your clients are intelligent and capable people. When you give them the rationale behind their advice, they might (I mean, it's possible) solve their own problem the next time.
For example, “Hey, thanks for asking whether we can use that third-party trademark in our advertising. Unfortunately, we can’t. That’s because we can’t use third-party trademarks in our advertising that will create the impression that there’s an affiliation, partnership, or endorsement by that brand. Here, there might be the appearance of a partnership or endorsement because of how we’ve laid out the copy.”
With that explanation, your client could spot this issue the next time it comes up.
Check Your Work
Writing out a reason can cause you to change your mind. To take a trivial example, “Hey, do we have an arbitration clause in our Terms of Service? I’m asking because [ . . . wait a sec; I can check this myself . . . nevermind].”
Or, to take a more substantive example, “Hey, could you generate a data subject access report for user X for me? I’m asking because she claims Irish law requires us to include certain information [. . . wait a sec; this is a US user . . . I don’t think we need to engage with them regarding Irish law.]”
I am pleasantly surprised (and humbled) by how often writing out my reasoning, like writing these blog posts, changes my mind or reminds me of something I forgot.
Fin.