How to Require Consideration

One Way to Balance Alignment with Autonomy

“The code is more what you’d call ‘guidelines’ than actual rules.” -Captain Barbossa, Pirates of the Caribbean: The Curse of the Black Pearl (2003)

Today’s short article is about how to use “requirements to consider” (or what I call “Guidelines”) as a way to ensure alignment without eliminating localized discretion.

The point of a guideline is that it is two things at once. It is both a requirement, but it is also optional (you can read more about them here), because the individual retains the ability to make a final judgment call about whether or not they’ll actually do something, but—and this is the critical bit—they cannot just ignore or skip the act of considering.

Here are some examples:

• A support team has a refund guideline: “Before denying, consider offering a goodwill credit if there was a service failure.” The agent reviews outage and account history, then denies (or credits) and logs the rationale.

• An engineering team has a release guideline: “Before shipping to the review team, consider security impact.” An engineer does a quick threat-check, then ships with a note documenting what was checked and why any remaining risks are accepted or deferred.

Requirements-to-consider are a great way to handle peer-to-peer expectations, but they end up being useful in all sorts of situations because they provide an elegant balance of stability and flexibility.

What Does Consideration Mean?

“Consideration” means whatever you think it means, but let’s break it down into two categories: 1) thinking acts and 2) doing acts.

The Thinking Considerations

• Reflect on

• Deliberate about

• Evaluate mentally

• Weigh (internally)

• Sanity-check (in one’s head)

Any of these would qualify as “consideration” even if they are vague and impossible to measure. But sometimes a lightweight standard is all that the situation requires. With that said, if you really want to see the power of guidelines for collaboration, we need to look at the “doing” versions.

The Doing Considerations

The doing types of consideration are really where a lot of juice is because this is how you can turn something that seems impossible to manage, and turn it into something grounded and navigable. Here are some examples:

• Check off (confirm it has been considered)

• Log (a one-line note)

• Post to Slack channel

• Mark as reviewed

• Record “applies/doesn’t apply”

• Note “tradeoff accepted”

• Capture a single sentence rationale

• List one risk and one mitigation

• Add a link/reference (to evidence or precedent)

How to Enforce a Guideline

There is a lot to say about guidelines, but I want to keep this focused on the minimal distinctions necessary to put them into practice (I’ll provide a fuller treatment later), which means we need to focus on enforcement.

The point of a requirement-to-consider is that, as a requirement, it can (and should) be rigidly enforced.

But by leaving the final determination and judgment up to the individual, it is rigid enforcement of something that is very reasonable to expect.

To be clear, violating a guideline means:

• They didn’t even consider it

• They mentally considered it, but didn’t do the required action (if there was one)

And I think that’s pretty much it. Because even though it may still create tension, if they considered it and didn’t actually do it, they still followed the guideline.

Of course, this may create new tensions which need to be integrated. Maybe the guideline needs to be changed, nuanced, or upgraded, but the point is that a guideline gives the person needs the right to use their judgment (within whatever constraints).

Conclusion

Too often we try to “soften” requirements through vague phrasing or by selectively enforcing them. But those approaches tend to create ambiguity and therefore create dependence upon the people in power. For those reasons, guidelines are often a much better option.