Pity the child who asked my fourth grade teacher, Mrs. Hunt, "Can I go to the bathroom?"
"Yes, you can," she would say, "but no, you may not." The first time I complained to my Mom that we’d have to repeat the request in its proper form before Mrs. Hunt would say, "Yes, you may!" I expected Mom to get as angry as I was. Instead, she laughed and said that was a good way to teach grammar and also to highlight the difference between constraints, controls, policy, and capriciousness.
Of course, I wanted to know what she meant. My older brother Reese, who already knew this speech, grinned at me knowingly as Mom explained that Mrs. Hunt was assuming we were all capable of going to the bathroom; that there were no physical constraints keeping us from going.
The school had a policy, however; kids couldn’t leave the classroom without a teacher’s permission. Mrs. Hunt was old, but she was probably fast enough to grab us if we tried to circumvent policy and make a break for it. And if she couldn’t prevent a child from leaving, she’d certainly react to it. It was an adequate control system, Mom said.
Then Mom got serious. My teacher wasn’t being capricious, she explained. She wasn’t making up a rule on the spot, based on how she felt at the time. Being capricious about important things, such as not allowing someone to empty their bladder with dignity, is an abuse of power or trust, she said. No one likes or admires that. And she wouldn’t put up with it. If this were the case, then she’d march down to the school and have a chat with the principal. But Mrs. Hunt was teaching policy, discipline, and grammar. Mom was all for it.
Of course, Reese knew how to flip this into a game. "Hey, Gwen, may I hold my breath for 20 minutes, please?" he’d ask. "Yes, you may, but no, you can not!" I’d reply. "Hey, Gwen, may I fly to the moon?" "Yes, you may, but no, you can not!" "Hey, Gwen, may I reach right through the oven door and grab the hot baking dish?" "Come on! You know you can’t!"
Fast forward several decades. I started working with software teams charged with integrating large sets of information and moving data between mainframes and client/server applications. I kept hearing that certain functionality wasn’t possible, when I knew for a fact it was. "It can’t happen the way you want!" developers would tell me, and I’d have to play 20 questions with them to determine whether it wasn’t:
- Physically possible under any circumstances
- Possible because of the way the system was architected or configured
- Possible due to preventive controls
- Feasible because of related conditions or constraints, such as resources or timelines
- Permitted because of a law regulation, policy, standard, agreement, contractual requirement, or compliance requirement.
Do you work with people who take similar verbal shortcuts? Do they insist things can’t happen—things you’re being told to make happen as part of your compliance strategy? If so, the next time you’re told, "No, you can’t!", consider going after a bit more detail. Determine whether the thing you need truly can’t happen, or whether the truth is that it may not.
If you can’t do something, it’s because of a constraint or a control. Some constraints aren’t changing anytime soon; people still can’t thrust hands through metal oven doors, and mainframes still can’t fit in a shoebox. Other constraints and controls are situational, so you need to evaluate them in context and decide if they can be negotiated.
If the truth is that, "Yes, you can, but no, you may not!", then you probably need to know the reason so you can pass it on to your stakeholders when they ask why you can’t deliver what they want. It’s important for you to get good answers to your questions. After all, if you’re simply trying to comply with a compliance requirement, the last thing you need is to be accused of being capricious.