Work the policy, not the exceptions.

At an early job, I worked with a coworker whose philosophy was “If you don’t ask for it, you’ll never get it”, which culminated in continuous escalations to management for exceptional treatment. This approach was pretty far from my intuition of how a well run organization should work, and it grated on my belief that consistency is a precondition of fairness.

Since then I’ve come to believe that environments that tolerate frequent exceptions are not only susceptible to bias, they are also inefficient. Keeping an organization aligned is challenging in the best of times, and exceptions undermine one of the most powerful mechanisms for alignment: consistency.

Conversely, organizations survive by adapting to the dynamic circumstances they live in. An organization stubbornly insisting on its established routines is a company pacing a path whose grooves lead to failure.

How do you reconcile consistency and change?

Like most seemingly opposing goals, the more time I spent considering them, the less they were mutually exclusive, and the more a unified approach emerged that I call “work the policy, not the exceptions.”

Good policy is opinionated

Every policy you write is a small strategy, built by identifying your goals and constraints that bring actions into alignment with those goals. It’s probably easiest to dig into an example.

One of the most interesting policies I’ve worked on recently was designing who is able to join which teams in a company with both many remote employees and many geographically distributed offices. Our most important goals were:

1. Make every office a first-tier office; there are no second-tier offices.
2. A first-tier office must own multiple critical projects, its work shouldn’t be constrained by support from other offices, and it must have many folks physically present who work together closely.
3. Ensure remote engineers remain an essential, well-supported cohort of the company.

Once we had agreed upon our goals, the next step was to codify some constraints to narrow the scope of allowed actions to those that supported our goals. In this case, a (slightly simplified) set of constraints might be:

1. Teams are staffed in at most one office. (“At most” to support the premise of teams composed entirely of remote engineers.)
2. Employees in an office must be members of a team in that office.
3. Remote employees may work on any team.
4. Employees within a sixty minute commute of an office must work from that office.

These are good examples of constraints because they clearly constrain allowed behaviors. You could imagine less opinionated constraints, such as “folks in an office should prefer working on teams within that office”, but that would do less to constrain behavior.

If you find yourself writing constraints that don’t actually constrain choice, it’s useful to check if you’re dancing around an unstated goal that’s limiting your options. For example, in the above, you might have an unstated goal that employee pursuing their preferred work is more important than offices being first-tier, which would lead you towards weak constraint.

The fixed cost of creating and maintaining a policy is high enough, that generally I don’t recommend writing policies that do little to constrain behavior. In fact, that’s a useful definition of bad policy. In such cases, I recommend writing norms instead, which provide non-binding recommendations, and because they’re non-binding they don’t require escalations to address ambiguities or edge cases.

Exception debt

Once you’ve supported your goals through constraints, all you have to do is consistently uphold your constraints. This is easy to say, but consistency requires no little bravery. Even with the best intentions, I’ve often gone astray when it was time for me to support my own policies.

The two reasons applying policy consistently is particularly challenging are:

1. Accepting reduced opportunity space. Good constraints make tradeoffs that deliberately narrow your opportunity space. Some of the opportunities that you’ll encounter within that space will be exceptionally good, and it’s hard to stay true when faced with concrete consequences.
2. Locally suboptimal. Satisfying global constraints inevitably leads to local inefficiency, sometimes forcing some teams to deal with deeply challenging circumstances to support a broader goal that they may experience little benefit from. It’s hard to ask folks to accept such circumstances, harder to be someone in one of those local inefficiencies, and hardest yet to stick to the decisions at real personal cost to the folks you’re impacting.

When we’ve picked thoughtful constraints to allow us to accomplish important goals, we need the courage to bypass these opportunities and accept these local inefficiencies. If we don’t summon and maintain that courage, we incur most of the costs and receive few of the benefits.

Policy success is directly dependent on how we handle requests for exception. Granting exceptions undermines folks sense of fairness, and sets a precedent that undermines future policy. In environments where exceptions become normalized, leaders often find that issuing writs of exception–for policies they themselves have designed–starts to swallow up much of their time. Organizations spending significant time on exceptions as experiencing exception debt, and the escape is to stop working the exceptions, and instead work the policy.

Work the policy

Once you’ve invested so much time into drafting policy, you have to avoid undermining your work, and yourself, with exceptions. That said, you can’t simply ignore escalations and exceptions requests, which often represent incompatibilities between the reality you designed your policy for and the reality you’re operating in. Instead collect every escalation as a test case for reconsidering your constraints.

Once you’ve collected enough escalations, revisit the constraints that you developed in the original policy, merge in the challenges discovered in applying the policy, and either reaffirm the existing constraints or generate a new series of constraints that handle the escalations more effectively.

This approach is powerful because it creates a release valve for folks who are frustrated with rough edges in your current policies–they’re still welcome to escalate–while also ensuring that everyone is operating in a consistent, fair environment–escalations will only be used as inputs for updated policy, not handled in a one-off fashion. It also maintains working on policy as a leveraged operation for leadership, avoiding the toilsome robes of an exceptions judge.

When you roll out a policy, it’s quite helpful to declare a future time when you’ll refresh it, which ensures you’ll have the time to fully evaluate your new policy before attempting revision. It’s fairly common for folks to modify good, effective policy due to concerns before the policy had time to show its effect. At a sufficiently high rate of change, policy is indistinguishable from exception.

The next time you’re about to dive into fixing a complicated one-off situation, consider taking a step back and documenting the problem but not trying to solve it. Commit to refreshing the policy in a month, and batch all exception requests until then. Merge the escalations and your current policy into a new revision. This will save your time, build folks’ trust in the system, and move you from working the exceptions to working the policy.