There are certain queer times and occasions in this strange mixed affair we call life when a man takes this whole universe for a vast practical joke, though the wit thereof he but dimly discerns, and more than suspects that the joke is at nobody’s expense but his own.

—Herman Melville, Moby Dick

What I had intended to ask of you as a favour you have generously made a duty, leaving me the appearance of merit when I am merely following my own inclination.

—Friedrich Schiller, On the Aesthetic Education of Man

Black Belt Bureaucracy

There are times when bureaucracy is the best available solution. You reach into your tool bag as a leader and what comes out is a sticky, gooey gob of rules that you have to enforce, maybe to ensure your company stays compliant with GDPR or your expense and HR policies are applied fairly. Or, if you’re an IT leader, perhaps you need to brew up some rules around security, enterprise architecture standards, or shared services with chargebacks to business units.

What’s the recipe for a bureaucracy that doesn’t stir up metaphysical pathos among those subject to it? How can you use a bureaucracy the way Weber intended—to promote efficiency, fairness, and merit-based organization? To make it “domination through knowledge” rather than through petty authority and arbitrariness? How do you make sure it doesn’t pettifog?

Of course: you need to make it lean, learning, and enabling.

B1: Move Incrementally

Why exactly are you manufacturing bureaucracy? I don’t mean at a superficial level, like “we need to have control.” I mean, really, why? Is it to make sure you comply with GDPR? Is it to reduce travel expenses? To make sure workers show up to work on time? If you’re introducing IT standards, you might not have asked yourself why exactly—IT standards are as much a habit as a meaningful tactic.

You can’t skip this step, because the next step is to figure out the minimum bureaucratic constraints that will accomplish your objective. It’s an application of the Agile principle of “Maximize the amount of work not done”; in this case, it’s “Maximize the amount of bureaucracy not imposed.” Or you can think of it as an MVB—minimum viable bureaucracy—to which you will add more bureaucracy only if it becomes necessary. Start small, add incrementally, like everything else in the Agile world.

To build your bureaucracy empirically, you need to ascertain the results of each incremental piece of bureaucracy. That’s your feedback loop. If you add a bureaucratic mechanism and it doesn’t help accomplish your objective, roll it back!

Clarity on your objective is also important because you’ll need to compare the benefits to the costs you’re adding through your bureaucratic controls. Why not subtract your bureaucratic costs from your bureaucratic benefits and call it your profit from bureaucracy? If the profit isn’t looking too impressive, roll back, roll back!

You can give people transparency into the purpose of the rules, at least for those who are interested in questioning them. You want the rules to be questioned (see Hunt Monkeys, below). The critical point is to be clear on the purpose—because that leaves open the possibility of satisfying the purpose in better ways.

You must do an honest job of calculating the costs of your bureaucracy, not necessarily in dollars but in additional lead time for getting things done. Doing so is hard because your costs are scattered all over the enterprise. How many hours do people spend in meetings? Who has to review, edit, and sign off on documents? If you have an enterprise architecture standard, what does it cost you when employees forego using a tool or technique that more exactly fits the situation? Do you have an Enterprise Architecture Review Board, or a governance board? Do people have to prepare packages for that board, endure uncomfortable reviews, gather information to complete the packages?

B2: Do Marginal Doing

When you add bureaucracy, you will be adding watching to your doing. Your ultimate goal, though, is to maximize the amount of successful doing per dollar invested. So, a marginal dollar of watching had better increase the productivity or success of each of your doing dollars. You spend each watching dollar with the hypothesis that it will do so. Perhaps making this hypothesis explicit will bring clarity to your bureaucracy-making effort.

For example, you might be introducing a control that will help you comply with GDPR. In that case, it will probably make a lot of your doing more successful, because you’ll be allowed to do your doing in Europe or with Europeans as customers. Let’s say instead that you’ll require all software development projects to write an Integrated Logistical Support Plan. Your implicit hypothesis is that doing so will make the dollars you spend on each project more effective. This is a hypothesis that you really should test, because its truth isn’t all that obvious.

When it’s time to cut costs and take a marginal dollar out of your budget, seriously consider taking it from watching, not doing. You might be tempted to do the opposite, since with a lower budget, you feel you need better control over spending. But over what spending? If you’re not spending on doing, you’re done.

But the best way to frame this decision is to consider the goal: maximizing the amount of successful doing per dollar invested. You should take the dollar from whichever bucket will lead to that outcome.

B3: Substitute Values and Principles

As I noted in Chapter 7, it’s sometimes possible to replace bureaucratic controls with strong cultural norms and agreed-upon values and principles. Amazon is a good example, with its fourteen leadership principles that guide day-to-day decisions and reduce the number and extent of rules necessary. They don’t exactly replace bureaucracy, but they do fill in gaps between the rules, even if you make those gaps satisfyingly wide.

We’re trying to avoid this kind of thinking (in Muller’s words):

“Voiding human choice in public decisions is not just a theory … but a kind of theology…. Human choice is considered too dangerous.” As a consequence, “Officials no longer are allowed to act on their best judgment” or to exercise discretion, which is judgment about what the particular situation requires.1

Instead, we want to use our bureaucracy to provide minimal guardrails and then ask employees to use their judgment—guided by the organization’s values and principles. That doesn’t mean that management loses its control (in the broadest sense of the word), because employees are expected to use good judgment and will have to answer for their actions. At Amazon, each of us is free—encouraged, I should say—to make our own decisions on how to use the principles “Customer Obsession” and “Bias for Action,” but we have to use them and our decisions may be scrutinized.

When setting up your bureaucracy, there are many areas where you’ll do better to establish principles rather than rules, particularly in situations where cases are so varied that rules are necessarily incomplete, in areas of high ambiguity where you want employees to exercise judgment, and in areas where creative interpretation is necessary. On the other hand, values and principles will probably not help you prove your compliance with formal compliance regimes.

B4: Work inside the Frame

Continuing that train of thought—bureaucratic rules are just one way of many to steer employee behavior. It’s not necessary to use governance rules to control every aspect of their behavior because principles, management, and norms among their peers also contribute to guiding them. In particular, each employee has a manager who—get ready for this—manages them. Not necessarily in a command-and-control way, but in a way that influences their behavior. The bureaucratic rules are a “frame,” you might say, within which employee behavior is both free and managed.

An example that often comes up in our IT discussions is the use of standardized development and deployment platforms. In many DevOps organizations, a central group makes a set of tools available—a build pipeline—for all the developers to use. Leaders sometimes ask whether they should require all the teams to use it.

Not necessarily. Some enterprises have decided to leave the choice up to each team, with the provision that if the team uses the standard toolset, it will be managed and maintained by the central platform team, thereby freeing them of the burden. Since that’s a compelling proposition, most teams will choose to use the standard platform. A few teams might decide that the standard toolset isn’t right for what they’re doing and will choose a nonstandard one.

The next question we hear from leaders is “But what if they don’t use the standard when they should? What if they just prefer a different tool and decide to use it even though it adds cost and effort? Don’t we need a governance control to make sure they don’t?”

No. The people on these teams have managers who should question their decision to use a nonstandard toolset. The manager should ask “Why did you decide to do something that cost the company extra money? Was that a wise decision? Why are you going to waste your time managing the alternate tool instead of doing other, more productive work?”

This is how most knowledge-work employees are managed. Their actions aren’t fully governed by bureaucratic rules, but they are expected to make responsible decisions, and their managers are responsible for making sure that they do.

Even self-organizing teams in the Agile world are not free from control by managers.2 One Agile thought leader, Mike Cohn, says that “a Scrum team’s job is to self-organize around the challenges, and within the boundaries and constraints put in place by management.”3 That’s the key: freedom is the freedom to accomplish objectives that matter to the business.

As you build your black belt bureaucracy, you want to use it as a tool to constrain only what must be constrained. It’s tempting to make the frame of governance small out of a fear that employees will make bad decisions and managers will fail to correct them. But you’re hiring those employees to make good decisions. What you don’t want to do is make it harder for them to do what they were hired to do, which is to use their brains, skills, and professional knowledge to further the goals of the enterprise.

B5: Make It Easy to Do the Right Thing

When we at USCIS realized that employees were almost always going to fall for social engineering scams, no matter what our rules said and how much we trained them, we backed off from bureaucracy and tried a different approach. We introduced multifactor authentication, where employees had to use their badges to log in along with a simple PIN they’d memorized and did not need to change often. They no longer had a password for an attacker to steal.

Instead of frustrating employees with complicated password rules, we’d made it easy—once they got used to the new process, at least—for them to do the right thing to maintain the agency’s security. The principle works for many bureaucratic rules. How easily can employees file their expense reports? Has marketing made it easier to follow brand guidelines, maybe by providing corporate logos in different image formats?

If you do require management’s signatures on documents, make it easy to get them. Is there at least a cultural norm that managers will quickly make room on their schedules or even drop whatever else they’re doing to review and sign the document?

B6: Build for Self-Service

In the chapter on enabling bureaucracies, I presented the idea of self-service bureaucracy. For example, software development teams often need to use third-party software such as open-source components. A coercive model would force them to get permission from the security department each time they wanted to use such a product. With a self-service model, the security team makes available to the developers a vending machine full of software that’s been pre-vetted and secured. The developers can serve themselves without asking permission.

The self-service model works in many situations that previously required bureaucratic red tape and sometimes long lead times. One of the biggest drains on IT’s time used to be password resets. It was frustrating for everyone else around the company as well. But today most organizations have automated this process. Any user can click the “forget password” link and obtain a reset code. Security controls are automated and built in.

At Amazon, we have a strong culture of self-service. In fact, a new employee’s first few days of work resemble a scavenger hunt: they must figure out what they need, search for instructions on how to get it, and make their way through portals and installation scripts. I remember ordering my own business cards, joining email groups, requesting a company credit card, getting administrator access to my own laptop, and probably thirty or forty other self-serve tasks during my first day or two. Yet all of the bureaucratic and security controls are still applied—they’re just built into the self-provisioning process.

Ask yourself: If employees were given the choice, would they use your bureaucratic mechanisms? If they simplify or speed up a repetitious task, probably yes. If they needlessly constrain the employee, the initial answer is probably no. Of course, if you can show them why the mechanism is needed, it might change their minds. For an employee who is truly motivated to help the company succeed, a mildly annoying control that is clearly necessary to keep the company in compliance with GDPR might be easy to accept. You want to make sure that the employee willingly goes to your vending machine and gets the healthy noodles rather than ordering in from the ice cream shop, as I do.

B7: Automate Compliance

Automating bureaucratic controls makes them lean and removes the annoying toil associated with them. It’s a standard DevOps technique. Wherever you need to enforce a control, either set up an automated process that enforces compliance or automate a test that checks to see if compliance is occurring. It’s fast, easy, and doesn’t involve personal impositions of authority or troll-keeping.

For example, say that you want to deploy the financial controls I talked about in Chapter 7, requiring employees to tag (or label) infrastructure that they spin up in the cloud with a cost center code so that you can allocate costs. Old school bureaucracy: tell everyone they have to label their infrastructure, and have Finance periodically check to see that they did. New bureaucracy technique #1: set up an automated control in the cloud that continuously checks to make sure all infrastructure is tagged and if not, either shuts it off or reports that it is noncompliant. New bureaucracy technique #2: create a template script that employees will use to stand up their infrastructure and have it automatically look up and insert the right cost center code based on which employee or project is using it. That way the employee doesn’t even have to do anything to remain compliant.

Old-school bureaucracy required that employees use the right red tape to prove that they had followed the required processes. This created a paper trail so that auditors could later verify compliance. But all that paper adds costs and slows work down. Instead, with well-implemented automation, you should be able to give the auditors as much red tape as they can consume, with no added effort and no slaughtering of trees. Electronic audit trails are even better than paper ones, because they can record more detail and, in many cases, can’t be altered. Leaner bureaucracy and even better compliance.

I mentioned earlier that much of the documentation required by MD-102 is really a disguised checklist: an inefficient way to have someone sign off on the assertion that they did what was required. After each gate review meeting, we were required to write a memo saying that we’d reviewed the project and approved it to proceed into the next phase. The words in the memo weren’t important—it was just a wordy checkbox.

Fortunately, we can now automate many of the tasks whose only purpose was to show that rules had been followed. For example, one of our gatekeeping reviews checked to make sure that a new system had been fully tested before releasing it to production. But today we can write our automated deployment scripts to make sure that all of the code’s tests have been passed. We not only know the code works but also have an electronic audit trail showing exactly when the tests were run and what their results were. Since we can also electronically track any changes to the tests and the deployment script, we know exactly what tests were used and can confirm that nothing was deployed without adequate testing. The trolls rest contentedly in their caves.

B8: Get Skin in the Game

Our initiatives were overseen by disinterested parties who had little incentive to see the project completed successfully, only an incentive to stop it from proceeding if they discovered any risk. And, of course, there’s always risk. MD-102 was burdensome because those who imposed it had no incentive to make it less burdensome. Quite the opposite: the thicker MD-102 became, the easier it was to show Congress that they had DHS’s investments under control.

What if the burden were reversed: If the overseers had to justify every document and gate review they demanded? If they had to prove that the expense of an Integrated Logistical Support Plan was justified by the value it created for every software development project required to produce it? (It isn’t.) This exercise isn’t likely to happen because oversight is usually imposed by managers high in the hierarchy on employees who are low in the hierarchy, who have no right to demand justification. But you’re building your bureaucracy from scratch, so make those overseers work for their piles of red tape!

We had a similar problem with IV&V (independent verification and validation). It was performed by a contractor or a team that was not directly involved in the project—that’s what made it “independent.” That independence was valued by the devisers of MD-102, since their process was based on distrusting the project executors. That same independence, though, was also a problem—their incentive was only to find problems, not to support well-reasoned trade-offs.

Since they were never part of the decision-making and learning that went on every day during a project, they could only compare the result to the original plan. If a manager had decided that one of the requirements no longer made sense because of changing circumstances, and therefore was not worth its cost to implement, IV&V would flag it as a deficiency, in effect insisting that the money should have been wasted. When you’re setting up your bureaucracy, make sure that it supports the behaviors you want to encourage.

B9: Redraw Organizational Charts

Sometimes, changing the organizational chart can reduce the need for bureaucratic ceremony. You’ll often find wasteful formality at those seams where one silo meets another. In my previous books I tried to show how the traditional separation between IT and something called “the business” led to waste as requirements were tossed over the wall to IT and results tossed back over the wall to the business. Much of IT bureaucracy follows this separation: for example, the overhead of requirements documents, the sign-offs required to approve them, and the Gantt charting and status reporting that uphold the arms-length, contractor-like relationship that such a structure requires. There are a number of ways to solve this; one is to simply move the technologists onto product teams within the “business” part of the organization.

The problem is more general, though. In earlier chapters I showed that bureaucracy arises as interactions between silos are formalized, in a sort of Conway’s Law of Bureaucracy. This can often be remedied by some simple pencil strokes on the organizational chart.

Weber’s division of labor was along functional lines. His assumption—typical of the twentieth century—was that the increasing sophistication of different technical areas would require increasing specialization on the part of employees. DevOps and other cross-functional team-based approaches have called this into question. Generalist skills are more highly valued today, and we like to work backwards from the customer, organizing around product areas that directly deliver customer value rather than around technical skills.

Generalist skills, in fact, may help soften the rigid formalism that one functional group must impose on others. A security geek who understands the operations of the business might be able to develop better, or at least more informed, security policy that is easier to stomach. On the other hand, a business operator who has some understanding of security might have a bigger stomach for policy. Rigid siloing into functional groups exacerbates the pain of bureaucratic paraphernalia: policies that are forced on someone by security technocrats they don’t understand and whose measures of success are different and harder to accept.

When crafting bureaucracy today, you’ll want to make sure there are clear—but not necessarily technical or functional—accountabilities. Cross-functional teams can sit comfortably in a Weberian hierarchy, happily occupying a bubble on the org chart, sometimes within the product part of the organization. Generalists, exiled from Weberian bureaucracy, can have specific accountabilities, but they also play a helpful role in making coercive-sounding bureaucracy more enabling.

B10: Formalize Agility in Policy

Despite the constraints you’re imposing, you still want speed and agility. Since what is set in policy will tend to win out against what is not, consider writing speed and agility into formal policy. For example, it would have been helpful if the Analysis of Alternatives template had mandated that each of its sections be filled out as briefly as possible. Perhaps MD-102 could have required a QA analyst to sign off on each document as being the briefest possible document that answered the questions in the template. That would be fine agile bureaucracy.

I’ve given you a head start with MI-CIS-OIT-003 and 4 in Appendix A to this book. You can also require that continuous improvement be applied to your own policy, as we did with the addendum to MI-003, which you’ll also find in this book’s Appendix. As I mentioned earlier, we erred in not formalizing a process for regularly updating the addendum—you might want to try doing so in your own policy and let me know how it goes.

B11: Practice Occam’s Centrifugal Whirl

In Chapter 9, I introduced Occam’s Centrifugal Whirl, a tactic of spinning authorities out to the periphery, or decentralizing controls when possible. In the tension between centralization and decentralization, centralization has a bureaucratic cost. It’s sometimes the right answer; the benefits outweigh the costs. But the default should be decentralization; it’s centralization that must be justified.

In DHS, where our investments were overseen centrally, the overseers were not familiar with our day-to-day needs and constraints, so there was additional cost to us in documenting and explaining things that were obvious to everyone in our component agency. The central overseers didn’t have to make the difficult trade-offs that we made every day; they didn’t feel the pain of delays to our initiatives that jumping through their bureaucratic hoops caused. Centrally based decision-makers are forced to see everything through the lens of simplified metrics and simplified categories. MD-102, as a central oversight framework, had to be general enough to apply to missions as distinct as vetting immigration applications, operating Coast Guard carriers, protecting the president, and responding to natural disasters. It could do none of these well. And centralized service provision (“shared services”) can add overhead and checkpoints to operations that could otherwise be self-service.

There are alternatives to centralized activity that can be effective and still allow for a degree of centralized management. Information security policies, to the extent that they need to be shared across the enterprise, can be delivered to the periphery in the form of automated test suites, which can then be applied by the decentralized teams. At AWS, the teams that create our products and services are highly decentralized and autonomous, but still implement guidance they are given by centrally based leaders; for example, continually working to reduce their costs and pass the savings on to customers.

Centralizing is sometimes necessary and sometimes productive, but it should not be a given.

B12: Dashboard Your Successes

In the first play, B1, you made sure you understood your objectives. Why not measure against those objectives and expose your results on a dashboard? The enforcers of MD-102 could have created a dashboard to show whether projects overseen by MD-102 were delivered on time and within budget. The results would not have been impressive. Even better, it could have reported on the cost of complying with MD-102 versus the benefits in on-time performance.

If you’re going to continuously improve your bureaucratic controls, then the improvements you make can be represented on the dashboard as well. Doing so will help motivate those on your continuous improvement team and those on whom the bureaucracy is enforced. As I’ve said, the PRA had many good aspects, one of which was that it tracked a specific metric—the number of burden-hours reduced. Let’s do the same with all of our bureaucracy shrinking.

You can treat the oversight process—the bureaucratic symphony you’re composing—as an investment and, just like any other investment, see what value you’re getting from it. The result should be a fine-tuning of your bureaucracy to get the best results.

B13: Hunt Monkeys

The best way to make sure your bureaucracy evolves is to find monkeys within your organization who’ll keep pushing to make it better. Hunt for monkeys and support them. At Amazon, we have the concept of a “bar raiser,” particularly in our hiring process. The bar raiser’s job is to make sure that we keep getting better and better—they’re a force or an energy that keeps the process of continuous improvement running. Old-school bureaucracies hate monkeys; new bureaucracies promote them, in both senses of the word.

In our hiring process, a bar raiser oversees the debrief after interviews, when the interviewers discuss their results and make their hiring decision. The bar raiser’s job is to make sure that the candidate is only hired if they’ll be better at doing their job than 50% of the people who are currently doing it. We also have bar raisers for our AWS blog who make sure that the quality of our content keeps going up. As a master bureaucrat, you can’t just subscribe to the principle of continuous improvement; you must also set up a process where it will necessarily happen.

A monkey should constantly question bureaucratic controls to make sure they’re still justified and suggest alternatives that might accomplish the same objectives better. Where bureaucracy tends to accumulate more and more controls, the monkey is a force for divesting controls that are no longer necessary and eliminating duplicative controls. A master bureaucrat makes sure there’s always a monkey handy.

B14: Bureaucrats Must Work Too

The overseers work for the executors, not the other way around. Making this clear is one way to give them skin in the game. It’s also a way to increase doing and reduce watching. Just as automating security controls turns them into tools that developers can use to make sure their code is secure, your oversight process should be a tool that project teams can use to make sure their efforts deliver business value and are aligned with strategy. Which is something they actually want.

In my IT organization, we pushed this principle even further by mandating that overseers such as QA, Enterprise Architecture, and Security do hands-on technology work: they became doers rather than watchers. Instead of issuing and documenting standards, Enterprise Architecture began creating reusable software components that implemented their standards. Security created or assembled automated security tests and placed automated guardrails in production. QA set up automated quality monitoring tools (“static code analysis”) and trained other technologists on how to improve quality. In all of these cases, the overseers were doing work that helped the people they oversaw.

The ARB, which consisted of officials rather high in the bureaucratic hierarchy, could also have worked for the projects they oversaw. They could, for example, have asked us an additional question in each meeting: What impediments are you facing and what can we do to help remove them? In other words, the overseers could have acted as servant leaders. From their positions in the hierarchy they would have had a lot of organizational power to apply. They could have seen across the many investments DHS was making and found ways to coordinate them for mutual advantage. They could have financed subsidiary activities that would help the project.

If the overseers were truly invested in the success of a project, they would be contributing however they can. The fact that we rarely saw that behavior from DHS overseers is a clue that their focus was on application of the rules rather than outcomes—that is, that there was a displacement of goals. But there’s no reason why they can’t bring a supportive attitude to oversight, even in a compliance-oriented bureaucracy. Ideally, they would have been dedicated to helping us comply with their rules rather than acting as judges of whether we were complying or not.

B15: ASAP Is Good

Perhaps you’re familiar with some pointy-haired boss* who wants everything ASAP. Well, he’s right. Everything should be done ASAP. This sounds strange because the pointy-haired boss is a jerk and when he says ASAP he means that his employees should work nights and weekends to finish the work. He means that he doesn’t want to make decisions about priorities, he just wants everything right away.

The sense in which he’s right is that a lean organization always tries to reduce lead times as much as possible (without demanding unsustainable effort from employees). When managers want something as soon as possible, they’re then committed to removing any waste or impediments that will slow their employees down. A typical impediment is that the manager does not prioritize the work—Lean theory teaches us that limiting work in process will reduce lead times. A good manager shouldn’t settle for having work delivered “on time,” but should insist on having it delivered with the shortest possible lead time—and be committed to making it possible.

This is important because bureaucracy is comfortable dealing with predictability (calculability)—focused on outcomes like delivering “on time.” But that’s not really what we want in a modern organization—we want short lead times (work completed ASAP). A culture of ASAP provides the urgency and the impetus for improving bureaucracy. You can help the Monkey in his task of showing that the status quo is not okay by making it clear that speed is valued. Bad bureaucracies bloat, which means they have waste, which means they are not lean, which means they lead to long lead times. ASAP is what’s missing.

Let’s say that you’re setting up a governance process for IT projects—a process for deciding whether to fund proposed IT investments. You should have two lean goals: make sure your process makes its decisions as soon as possible (no sooner than possible, though), and make sure that the investments you fund will deliver their results as soon as possible.

An example where ASAP urgency was lacking was our delightful Balanced Workforce Assessment approval process.† Each official was given one week to review and sign the assessment document. But since it only took fifteen minutes to do so, and since desk aging does not improve the quality of a spreadsheet, the rest of the week was waste. Each official should sign the document as soon as they can, and that’s that. If they sign it in barely less than the week they are given, that’s not bureaucratic success.

B16: Everyone Owns the Rules

Rules should almost never be enforced, in the coercive sense. If every rule is there for a good reason, and if employees are motivated toward the success of the enterprise, then they should want to follow the rules.

For example, the only way that a company can be successful at securing its information assets is if it builds a culture where security is valued. Everyone, regardless of their role in the hierarchy, should care about their company’s security posture and consider security to be part of their job.

An employee in Marketing or Sales, for example, should care about the privacy of their customers’ information—they’re implicitly promising it when they promote the company’s products. A COO should care that the company’s operations can continue running rather than being halted by a hacker who compromises an important IT system. The CEO and CFO have a fiduciary duty to the shareholders to prevent security breaches. Complying with the security rules is not a matter of obedience—it is a matter of doing what’s necessary to accomplish your own goals, which should include keeping your company secure. No one can really be doing their job right if they don’t participate in securing the organization.

Bureaucratic hierarchies with their strict divisions of labor can have this danger: that because security is specifically the goal of a security team, everyone else believes that it’s not their own job. As a result, they comply minimally and grudgingly with security policies, and make no attempt to fill in the gaps between the official rules. It’s like a work-to-rule strike, a way of taking policy literally and thereby subverting it.

Instead, all employees need to take ownership of securing the company, and use the security folks as enabling experts, the geeks who can help because they understand security deeply. To move from a coercive security bureaucracy to an enabling one everyone else has to want help from the security experts. The fact that they often don’t is largely a leadership and management challenge. Employees who are truly motivated to see the company succeed should also be motivated to see the company secured.

Yes, there’s some bureaucracy that must be enforced because it does not serve employees’ objectives. I’d like to fly first class, but my company’s rules say I must fly coach. But to a large extent, bureaucracy can serve the goals of employees as well as management—as long as management and leadership do what it takes to motivate the employees. Making bureaucracy pleasant turns out to be no more and no less than good organizational leadership.

To join an organization is to agree that you’ll be committed to serving its goals. A well-designed bureaucracy harnesses that commitment, joins it to the commitment of others, and directs it toward the organization’s mission. Homo bureaucraticus is born with an understanding of how to do that.

And that’s my final word on metaphysical pathos.

*	A reference to the cartoon strip Dilbert. -au, standing in for -ed.
†	This was the process that prevented us from achieving thirty-day procurements that I mentioned in Chapters 2 and 10. -au, standing in for -ed.