Let's Talk About Rules
How rules make bureaucracies more hostile, and what to do about it.
If there's one thing that defines bureaucracy, it's rules. (Also, stuffy gray suits and humorless expressions.) Rules, also known as regulations, policies, and requirements, are the lifeblood of a bureaucracy. Without rules, and enforcement thereof, bureaucracy loses its power, and the more rules in a bureaucracy, the more power it has. (We'll come to the topic of enforcement later.) We have already established what makes a bureaucracy hostile, now, let's talk about the role of rules in accelerating a bureaucracy's hostility.
The Origin of Rules
In our first post we discussed the role of good intentions in creating bureaucracies. The same is true of rules. In most cases, the people building a bureaucracy implement new rules because they believe those rules will help drive the organization towards its goals. Most rules seem reasonable on first reading, but in their reasonableness lies real danger. It's hard to reject a rule when the costs seem low and the purpose is clear. But that is because we tend to evaluate new rules in isolation, rather than as part of the larger system. At scale, a large number of "reasonable" rules combine to form major obstacles.
Let's look at an example of how reasonable rules can form larger obstacles. Most software teams use a code reviews to evaluate new code before accepting it into a product. This is an extremely reasonable system, because new code can contain errors that could break other features or introduce new bugs. So, a senior software engineer will review new code before pushing it into production. This adds some time to the process, and slows down delivery of new features, but the benefits generally outweigh the costs.
In order to speed things up, some teams also used automated tests to ensure the software functions as expected, even after new features are added. If the tests are successful, then it's easier to quickly accept new code. The senior reviewer can simply verify the tests passed, scan the new code for efficiency, style, etc., and then push it to production. In an ideal world, with disciplined teams that are careful about rule creep, this works just fine.
Now, how might this exceedingly reasonable system morph into something more oppressive? First, consider the code reviews. What if the senior engineer misses something, and the new code introduces a particularly costly bug? Out of fear of repeating the mistake, management might be tempted to introduce a second code review, just to double check the first reviewer's work. Seems reasonable, no? But who is authorized to do the second review? Can it be just any senior engineer, or does it have to be an engineering manager? In a small team, what happens if only one reviewer is available? Does the code wait, or do you push it to production without the additional review? For the system to remain nimble, you have to think through these questions, or be flexible enough to break the rules in the interest of speed.
And what about the automated tests? Tests are themselves just a different piece of code, which also must be written, reviewed, and implemented. What if the tests themselves are wrong? Or implemented in such a way as to give false failures in certain cases? Now the engineers need to spend time debugging the tests just to comply with the rules. In high-cost situations, this may be worth it, but combined, a few reasonable rules now have the potential to add considerable friction to the process, even in what should be easy, low-complexity situations.
Creeping Rules
Every new rule has upsides and downsides. The upside is usually baked into the rule definition itself: mitigation of risk; communications consistency; error checking; hierarchy compliance; etc. The downside, however, is often hidden from view until much later, which biases organizations towards accepting new rules even though the costs are unclear.
In the above example, we hinted at the first problem with rules, which is rule creep. A bureaucracy experiences rule creep due to edge cases and mishaps. An edge case is a situation that is outside the norm, but frequent enough that it can have a real impact on an organization. Weather is an easy example. In the mid-Atlantic of the United States, winters are generally rainy and cold, but snow is rare. Snow is not, however, impossible, and one or two heavy snowstorms a year is fairly normal. In other words, snow is an edge case for mid-Atlantic weather.
If you owned a shipping company in the mid-Atlantic, you might start with a rule that says trucks stay on the road, no matter the weather. The road infrastructure is quite good, so driving in the winter rain isn't much of an issue. One day, a large snowstorm comes through, but your rule doesn't say anything about snow, so your drivers stay on the road. You can imagine what happens next. Accidents, delayed deliveries, trucks skidding off the road, and so on. After going through that, you update your rule to say trucks stay on the road, no matter the weather, except for days when it snows. (Again, seems very reasonable, right?)
Snow in the mid-Atlantic isn't always catastrophic though. Sometimes it's just a dusting of snow that is little different from a light rain. But, in compliance with the rules, your drivers now stay off the road and you lose money due to lost business. You update the rule again. All trucks stay on the road, no matter the weather, except for days when it snows, but only if the snow is heavy. You can see where this is going. As you see more and more edge cases, and edge cases to the edge cases, the rules get more and more complex, and business slows down as a result.
Rule Inheritance and Context Loss
Another problem with rules is context loss, which occurs when the original purpose of a rule is lost over time, but the rule itself stays. Any large, or long-lived organization will experience context loss, because the people in the organization move on or the situation the organization is facing changes. Context loss is a particularly devious aspect of rules because it increases the fear of repercussions when someone wants to jettison an old rule. If you don't know what a rule does, or why it exists, how can you decide whether it is worthwhile?
Context loss can happen in a multitude of ways, but let's look at a common one, which is management preferences. Every senior manager has their own way of doing things, and may implement new rules based on personal preference. For example, a vice president in a company might prefer to receive written summaries of projects before meetings, and implement a rule to that effect. What happens when the vice president retires or leaves the company? Do teams still have to prepare written project summaries before meetings? The easy answer is yes, because most teams are likely to associate the rule with the organization rather than the individual. In order to stop doing so, someone with appropriate authority would have to rescind the departed vice president's rule.
Over time, managers may come and go, but the rules they implement stay, and by inertia alone, the people in an organization will keep following those rules. Context loss can happen in all sorts of situations, including changing market, political, or environmental conditions, personnel changes, new technology, new regulations, etc. As successive generations inherit old rules, they may or may not inherit the context. And if the context changes, rendering the old rule unnecessary, someone has to know enough to eliminate the old rule, otherwise it builds as organizational debt.
Rule Bottlenecks
Earlier, we discussed one example of a rule bottleneck, which was the senior engineer who has to review code before it goes into production. This is an example of key personnel, whose approval is necessary to comply with a rule. Any time someone like this is unavailable (on vacation, sick, traveling, etc.), the system slows down unless there are alternate key personnel. Establishing alternate key personnel requires planning, and an inflexible or poorly managed organization may not have the foresight to plan ahead, resulting in a rule bottleneck.
Another, perhaps more difficult, example is when the rules become so complex that you require specialist knowledge to comply with the rules. As the number of rules increases, and the context related to those rules becomes opaque, specialist personnel may be necessary to interpret and apply the rules. (We usually call these people lawyers.) This is particularly true if an outside actor is creating the rules. (We usually call these actors governments.)
Any time specialist knowledge is required for rules, an organization will face a rule bottleneck. By definition, specialists have unique or hard-to-acquire education, knowledge, and experience. This makes them rare commodities. And depending on their workload, vacation schedule, and number of commitments, specialists will be faster or slower in issuing guidance on rules for the rest of the organization.
Alternatives to Rules
So far, we have discussed why rules are an inherent part of bureaucracy, and how they can make a bureaucracy more hostile. What then, is a nimble organization to do about it? Our recommendation is both simple, and immensely difficult to implement: use guidelines rather than rules.
Rules are hostile because they are inflexible. A guideline, by comparison, is flexible and outcome-oriented. Let's revisit our shipping company dealing with bad weather. We saw how rule creep can make it difficult for drivers to know when they are allowed to be on the roads, particularly in the face of edge case weather. Instead of rules though, the shipping company might simply issue a guideline that says "only drive when the weather appears safe". Like the rules, this guideline is intended to prevent accidents but also avoid unnecessary downtime. Unlike the rules, the guideline is flexible and leaves compliance up to the discretion of the driver.
This brings us to the biggest challenge of guidelines over rules. Guidelines require empowerment and trust. If you aren't willing to empower your team to make good decisions, or if you put so much pressure on them that they're unlikely to make the right decision (for example, by punishing drivers for deciding not to drive), then guidelines won't work. You have to be willing to trust your team to make the right decision, in a way that is aligned with your organizational goals (in this case, safety and efficiency), and without your oversight.
Trusting other people, particularly under high-stakes conditions, can be extraordinarily difficult. Moreover, when mistakes inevitably happen (at some point, a driver will have an accident due to snowy weather), you have to resist the urge to implement rules. Instead, you need to be disciplined enough to keep trusting others, even after mistakes.
Guidelines are much harder than rules, but they can keep organizations nimble. To work though, you need to ensure everyone understands the guidelines, and is equipped with the right knowledge and experience to operate under them. This requires constant education, culture-building, and willingness to take risks. A shipping company with a culture of safety, where drivers know the risks of maneuvering through winter weather, and are empowered to make on-the-ground decisions, is going to be much more effective than a company with a strict set of cascading rules.
As a final note, we should point out that not all rules are bad. In some cases, the stakes are legitimately so high that rules are the only way to avoid mistakes. In a hospital, it's probably worth having a rule that doctors must wash their hands before surgery. A culture of hand-washing might get you there, but the risk is simply too high to rely on culture alone. However, these cases are outliers. Every organization probably has a few of them, but not every desired behavior needs to be encoded in a rule. Hospitals may need a rule about hand washing, but guidelines for treating particular illnesses will give staff greater flexibility than rules, and likely improve patient outcomes.
In today's proceedings, we learned how rules can create unexpected challenges for an organization. As small hindrances and inefficiencies from rules add up, they can create large roadblocks to progress. This is a defining aspect of a hostile bureaucracy, as it makes the system more important than the people and goals it ostensibly supports. That's the bad news. The good news is that there is a better way. Using guidelines instead of rules can help you tame the bureaucracy, so long as you're willing to trust your team, and stay flexible.