Note: This is another of those 60-minute posts.
Suppose I said to you, "Go read War and Peace and write me a 10-page book report on it." What would you say? Probably something like Why? or Who do you think you are? or maybe just No. That's a homework assignment, and there's no reason I should be entitled to just give you a homework assignment.
Why isn't it reasonable for me to give you a homework assignment? Because I'm not your boss1. And in civilized society, we don't abide individuals just assigning arbitrarily large tasks to one another. It isn't proper.
Notice I said "arbitrarily large tasks"; we actually are okay with assigning small tasks to each other. For example, almost no one thinks it would be audacious of me to say, "Hey, could you hand me that stapler?" Even if I were to blurt, "Give me that stapler!"—a significantly ruder way to say it—my suspicion is that most people would still give me the stapler, albeit with a bit of annoyance.
There is some sort of unspoken dividing line for most of us, on the axis of task size, where tasks to the left of the line will be performed on command and tasks to the right will be rejected.
One of the devs on my team told me a story at lunch the other day. He used to work at Barnes and Noble, and as an employee there he was incentivized to sell memberships to the store. While most of his coworkers simply asked customers if they wanted a membership, he found much greater success by sharing a few concrete details up front, particularly if he could offer significant savings on the purchase the customer was about to make.
Asking someone to make a decision like Would you like to start a membership? is a bit like giving them a homework assignment. It's a decision that requires gathering more information (i.e. asking, What are the benefits?), doing some analysis, and finally committing to at least a small amount of overhead (e.g. filling out a form) that the person hadn't originally planned for. For many, the cost of making this decision pushes it past that unspoken diving line.
For the dev on my team, sharing details about the membership with customers had a dramatic effect because it effectively reduced the size of the task being assigned—skipping the information gathering and some of the analysis (e.g. This will pay for itself from savings on your purchase today alone)—so that it moved to the left of that line.
I'll share another anecdote. Recently one of the engineers on Bitbucket switched over to the security team. One day, in this new role, he started conducting some testing against our staging environment, causing some disruption to the team. When asked to stop, he reached out to the leader of the DevOps team to inquire when would be a good time to conduct his tests against the staging environment. The answer he got: Never.
See the similarity? When can I run these tests that might cause some disruption? is a bit like asking, Would you like a membership? The answer requires data gathering and analysis, which the person being asked may not have time to perform. The way to get people to say yes in these situations is to do that data gathering and analysis for them, so that the cost of the decision you're asking them to make is much smaller2.
Here's another way of framing the lesson here. Sometimes No or Never doesn't mean No, you can't do that; sometimes it means No, I won't take the time to make that decision right now (in other words: No, I won't do that homework assignment). Be aware of that, and account for it by doing the legwork: make a concrete proposal, explain the benefits, show that you've done the homework. In doing so you can make it easier and easier for someone to say yes, just like handing over a stapler.
Unless I am your boss, in which case... I'm going to need you to read War and Peace. ↩
And for the record, I believe that's exactly what happened in this case: the former Bitbucket engineer went back and made a more concrete proposal, including what the procedure should be for scheduling some planned testing and informing the appropriate on-call member(s) of the DevOps team. ↩