And then we say, “Lord God, how can I break free of anxiety?” Can it be that you have no hands, fool? Perhaps God didn’t make any for you? Then sit down and pray that your nose doesn’t run! Or rather, wipe your nose and stop making accusations.

—Epictetus, Discourses

Look ye, pudding-heads should never grant premises.

—Herman Melville, Moby Dick

Technology Changes Bureaucracy

A lot has changed since Weber’s day. Manufacturing, which accounted for only about 12% of jobs in 1840 but trended steadily upward through Weber’s time to about 38% in the 1950s, fell to less than 20% by 2010. On the other hand, the services industries now make up over 75% of jobs.1 The type of bureaucracy we see today is primarily meant to control service workers, not factory workers. Digital technology has taken hold and become central to the way businesses compete and public sector organizations accomplish their mission objectives. Efficiency and productivity look very different in a digital and knowledge-work world: the goal is not to produce more lines of software code per hour or to manufacture better formatted PowerPoint presentations.

What today’s organizations need, primarily, has more to do with speed and short lead times. Businesses are caught up in an environment of rapid and continuous change, complexity, and uncertainty, driven in part by the actions of their competitors—some of which are startups bent on undermining traditional industries. It’s driven as well by the fickle preferences of consumers, who might suddenly race to a competitor in as little time as it takes to read an inappropriate tweet from a CEO or hear of a new style of yoga. The business environment is subject to sudden political change, regulatory change, and geopolitical instability; coronaviruses and trade wars; terrorist actions and new installments of Fast & Furious. Consumer expectations have risen as technology has put empowering tools in their hands (and on other body parts)—smart phones, tablets, wearables, virtual reality headsets, gaming consoles.

And bureaucracy is still with us. That seems strange. Bureaucracy works best, Weber acknowledged, in situations of routine, repetitive work. It locks in routines and formalizes processes so that they are well-known and repeatable … forever and ever. When the world calls for speed and agility, fastness & furiousness, bureaucracy just doesn’t seem rational. Formal rules and roles lend stability—but stability in the face of disruptive change is what makes Blockbusters and Kodaks of previously admired companies.

I’ll suggest in this chapter that we can use bureaucracy to gain speed and support innovation. It’s a tool available to us for situations where it fits. It can accelerate and routinize repetitive work and provide guardrails that relieve worry. It can help us satisfy external demands—like compliance frameworks and pressures from bad-guy hackers—that would otherwise interfere with our delivery of value and our pleasure in our work. I know, claiming speed as an advantage of bureaucracy sounds a bit unhinged. But much of what we’ve learned in delivering digital IT capabilities can help us change the way we practice bureaucracy, for the better.

We’ll have to shear off many of the bad practices that have attached themselves to bureaucracy. We’ll have to eliminate bureaucracy that’s not adding value, limiting its scope to where we really need it. And then, we’ll be able to use techniques we’ve learned from DevOps and Agile IT to make our bureaucracy lean, learning, and enabling.

The problem is that we’ve been doing bureaucracy all wrong.

Bureaucracy: Annoying, Necessary

Admit it—Weberian bureaucracy is not the stuff of nightmares. The other stuff we’ve added, stuff outside of Weber’s bureaucratic “ideal” of rigid roles and rigid rules, is what made Kafka’s reputation. Bureaucracy is just a tool, a way to add formality where formality is helpful, a way to rigorously specify processes when rigor matters. It’s a solution to problems organizations face as they grow and personal contact is lost among employees or between employees and the public. It’s neither good nor bad, just as the law of gravity is neither good nor bad. We shouldn’t have nightmares over gravity, but, then again, we should use it only when we want to descend toward the Earth or attract massive bodies, not when we’re leaving Earth to return to our home planet after abducting bureaucrats for study.

Unfortunately, the way we usually practice bureaucracy is a nightmare—the trolls-in-caves, carbon-copying, weigh-’em-down-with-sludge school of bureaucracy that menaces our productivity and elevates our stress levels. But what if we could tease apart these strands, separate bureaucracy as benefactor from bureaucracy as tormentor—and somehow make the Sadean part go away? Look—we don’t really hate bureaucracy, we just hate big cockroaches like Gregor Samsa.*

In fact, we need bureaucracy, at least in the Weberian sense. And we’re stuck with it because the traditional division of labor between Marketing, Sales, Finance, and Operations is still with us, even if other functional delineations are being erased. To achieve the fastest lead times, we need it to streamline those repetitive, mechanical activities that Agile frameworks refer to as “toil.” Large enterprises need some formal patterns of interaction. Even innovators like Amazon and Google, as we’ll see in later chapters, impose structure to rationalize their operations. And there will always be some sort of formal “governance” to convince investors, regulators, and customers that particular controls are in place. At some level of abstraction, every large enterprise is a bureaucracy.

During my time in the government, I realized that no amount of digital transformation would eliminate government bureaucracy. And we wouldn’t want to have it any other way. The US government has, as a fundamental principle, an institutionalized lack of trust. We have a system of checks and balances because we do not trust any one branch of government. We have formal mechanisms that prevent government officials from bringing their biases to roles that are meant to be in service of the public. We give hiring preference to those who have served our country in the military. We implement rules that constrain how we award contracts to make sure vendors are treated equally. In other words, bureaucratic structures are used to satisfy the public that the government is acting in their interest.

I found that government bureaucrats are on the whole well-meaning and devoted to mission success. Their activities are tightly constrained in ways that are hard to imagine until you face them every day. But bureaucracy per se is not what constrains them: it is our wishes, as expressed through Congress, the president, and the free press that, when translated into the syntax of bureaucratic rules, control the behavior of federal employees. Bureaucracy is an answer—the answer to the question, How can we set guardrails and controls that make sure that government employees do what we want them to do?

Businesses are no different. The capital markets do not just naively trust the management team of a company. Management does not just trust employees. The government does not just trust businesses. Unions do not just trust management.

Bureaucracy does not just tell people what to do—it provides proof that they are doing the right things. The red tape we hate so much yields a paper trail to show that the rules were followed. That’s how bureaucracy addresses an institutional lack of trust.

Adler puts it nicely:

We need bureaucracy for the discipline it affords, but we don’t want it because it brings a host of negative consequences…. My research suggests that the negative consequences of bureaucracy—rigidity, alienation, and low commitment—may be widespread, but they are not inherent in bureaucracy. They are the result of poor choices in the specific form given to bureaucracy in too many organizations.2

Digital Bureaucracy

While everyone can see that technology has changed, what’s less obvious is that the way technologists work has also changed—dramatically. And since technology is increasingly central to businesses, it’s also changing the way businesses operate and are led. The innovative management styles developed by technology-centered companies are beginning to influence more traditional enterprises. As DevOps, user-centric design, and machine learning have entered businesses, silo boundaries have been crossed. Businesses are learning to focus on product rather than their own processes, to enter markets incrementally and refine their products and services iteratively, and to make decisions based on real data rather than projections and assumptions.

To the extent we use technology to refine our bureaucratic approach, we can harvest bureaucracy’s advantages—fairness, simplification, optimization, transparency, and compliance—but with a tad less metaphysical pathos. Digital transformation does not need to sidestep or eliminate bureaucracy. Instead, it needs to realign bureaucracy, turn it from an impediment to an ally, make it not just allow speed and joy, but foster it. In a transformed digital organization, bureaucracy is given its proper place, while creativity, innovation, values, and shared humanity leap to the foreground.

There’s my new formula for digital transformation—that vague goal for which bureaucratic bobbleheads are bobbing support.† Our story starts in the IT world at about the turn of the millennium when Agile methods began to catch on …

Enter Agile and DevOps

At first glance, Agile and DevOps seem like the opposite of bureaucracy.

Agile IT delivery is based on inspecting and adapting. It’s best contrasted with what was called a plan-driven approach, where requirements were amassed and approved, a project plan was assembled, and a project team tried to deliver exactly those requirements exactly according to that plan. Success meant that the plan’s milestones and budget were met. An Agile project team, in contrast, looks back frequently to assess what they’ve learned and what’s changed, and incorporates those learnings and observations into its plans. Success is measured by results; the plan is expected to change with circumstances. Feedback and adjustment are guiding principles.

Since Agile delivery accepts and values change, it’s perfect for environments where complexity and uncertainty dominate. That is, everywhere, at the moment. To maximize feedback and learning, it’s practiced by small teams who deliver IT capabilities quickly and in small increments, learning with each one.

DevOps entered the scene in about 2009 and is today’s preferred approach to delivering IT. It combines Agile and Lean ideas and organizes technologists into collaborative, cross-functional teams. Each team has all the skills it needs to create, test, secure, deploy, and operate code, and takes ownership for doing all those things. (In A Seat at the Table and War and Peace and IT, I suggested we add non-IT business expertise to DevOps teams as well, and make teams responsible not just for delivering technology, but also for getting business results.)3 DevOps relies heavily on automation to deliver results extremely frequently in tiny increments—sometimes as often as hundreds or thousands of times every day—thus maximizing learning as the enterprise gets to see the results of each small piece of work.

Where bureaucracy emphasizes following the rules, DevOps emphasizes getting results; the displacement of goals common in bureaucracy is not seen in DevOps. Where bureaucracy would have a division of labor based on functional expertise, DevOps has cross-functional teams; where bureaucracy pushes accountability down a hierarchy of organizational chart roles, DevOps holds teams, as a whole, accountable. And while bureaucracy defers to experts higher in the hierarchy, DevOps relies on an experimental approach to support data-driven decisions.

DevOps, you’d think, couldn’t be more different from bureaucracy.

DevOps Is Bureaucracy

Those surface differences obscure the many deeper connections. DevOps is in fact a brilliant implementation of bureaucratic ideals. Like any Weberian bureaucracy, DevOps is full of rules—and they are rigorously and impartially enforced, without anger or bias or whim or caprice. Some are cultural norms (the team wears the pager), some are rules of thumb (automate all the things; if something is painful, do it more often; always make your changes to the master branch), and some are automated (code cannot be deployed unless it has passed all its tests; code only becomes part of the build after it receives a peer code review).‡

DevOps regiments those aspects of IT delivery that are repetitive “toil” through a bureaucracy that is enabling and lean. For example, code is tested and deployed through automated scripts that enforce security and quality controls. Those automated rules keep us secure and compliant and let us optimize our practices to where we can deploy code thousands of times per day.

Functions that were once handled by human bureaucracy—reviews by change control boards, say—are now taken care of by automation and standardized practices, but that doesn’t make them any less bureaucratic. More so, perhaps. There are no exceptions and the rules are applied impersonally—very impersonally, because they’re applied by machine.

DevOps is a culture and a process. And the culture reinforces the belief that the process is one which … thou shalt follow. Thou had damn well better—DevOps is bureaucracy functioning as institutional memory. It incorporates the practices that our collective experience has found to be most effective. Check in code often. “Prove” that your code does the right things by writing tests and showing they pass. Deploy often, but only if your tests have passed. If you break the build, you must fix it right away. Automate your infrastructure. Make sure absolutely everything, including infrastructure, is checked into source control. Use a testing pyramid; focus mostly on unit tests. Its processes are rigid, well defined, and impersonal. DevOps, you might say, is a reference implementation of Weber’s bureaucratic ideals for the digital age.

DevOps is automated bureaucracy—and so what? It’s still a humane approach to IT delivery, joining together the former silos of IT development and operations behind a single goal. In the next chapter I’ll distinguish between bureaucracies that are enabling and those that are coercive. DevOps works so well because it’s enabling. Does it also have coercive aspects? Perhaps. Do you find it suspicious that so many teams are adopting DevOps when we tell them it’s the right thing to do? Would a technology team not feel plenty of peer pressure if they decided to adopt “blameful retrospectives”?§¶

I consider DevOps to be a revolution in how we deliver IT capabilities. My books have presented it as the solution to many decades of dysfunction in how companies use technology, in particular how they’ve traditionally thought of IT as separate from something called “the business,” and as a result have treated their technology departments as if they were an arms-length contractor outside their corporate walls. DevOps gives us a way to bring technology into the heart of an enterprise by dissolving the wall that shuts it out.

And that’s why I want to force everyone to use these best practices. I mean, enable.

Reconciling Weber to DevOps

There are a few tweaks we’ll have to make to Weber’s ideas to make him happy with DevOps.

Although Weber speaks of a division of labor based on technical specialization (which contrasts with the cross-functional teaming of DevOps), what is truly central to his framework, I think, is the division of accountability along precisely drawn lines. Well-defined accountabilities in Weber’s model ensure that there are neither gaps nor overlaps when the work is orchestrated into a whole.

Division of accountability is also a core principle of DevOps, in that teams are fully committed and responsible for the IT capabilities they deliver. DevOps principles say “run what you build.” The point—an important cultural difference from previous ways of doing IT—is that a team doesn’t toss its work over to someone else to manage when it claims to be “finished.” Instead, the team takes full responsibility for the code’s entire lifecycle and the business results obtained with it.

DevOps lends itself to a product-based organizational model. Such a model is just as rational as Weber’s hierarchy of technical functions, and more rational today: just as Weber was overwhelmed by advances in technology and thus made technical specialization the basis for his division of labor, enterprises today are overwhelmed by the potential for customer-centricity and deeper engagement in the digital world, and make customer-facing products the basis of their rationalized hierarchies.

Another tweak we must make to Weber’s model is that accountability in DevOps is at a team level rather than an individual one. Essentially, some nodes on the organizational chart are filled by teams rather than individuals. This, frankly, goes against Weber’s thinking: he dismissed “collegiate” organizations—those with group accountability—as inefficient.4 Instead, he took as his model the “monocratic” variety of bureaucracy, where every role is occupied by an individual, which, he says, allows for the highest degree of efficiency.5 But in our digital world of fast-spreading memes, hacker toolkits for script kiddies, stealth startups, and high-spending venture capitalists, it’s more rational to value short lead times over process efficiency.

Oddly, Weber doesn’t see this. Speed—interpreted as fast response and short lead times—must have meant something very different in his time, because he’s adamant that his monocratic variety of bureaucracy provides it:

The extraordinary increase in the speed with which public announcements are transmitted, whether about economic or even purely political matters, has in itself created nowadays a continuous and intense pressure in the direction of the maximum possible acceleration in the time taken by the administration to react to situations as and when they arise: the best results in this respect are normally only achieved by strict bureaucratic organisation.6

Weird, huh? He seems to be talking about today’s digital economy, and he’s suggesting that bureaucracy fits. He’s so close to getting the digital world right …

The lean principles of the Toyota Way didn’t start to be formulated until 1930, after Weber’s Economy and Society, and the details of the Toyota Production System didn’t come together until sometime between 1948 and the 1990s, when they began to influence American Lean Manufacturing. With them came the idea of minimizing lead times by eliminating the eight kinds of muda, or waste. I can only conclude that Weber did not know real speed. He believed that it followed from scientific process efficiency improvements, including higher capacity utilization, which is viewed as a potential source of waste in Lean. We’ll disagree with Weber and stick with the Lean view on this one.

A Schimpfwort in Hierarchy-Space

DevOps and Agile practices like Scrum may be instances of Weberian bureaucracy, but in execution they’re very different from the gnarled forms of bureaucracy we encounter every day and think of when we hear our favorite Schimpfwort.

DevOps is a model bureaucracy because it’s empowering while structured and controlled; lean as a matter of principle; and set up to learn through feedback loops and monitoring. It’s also designed as a bureaucracy that doesn’t inspire metaphysical pathos: it lets employees innovate and test their ideas at low cost, low risk, and high speed; it automates red tape so that employees can focus on work that motivates them; it enforces controls required by compliance frameworks and security objectives, but does so behind the scenes through automation rather than through gatekeeping trolls; and it increases organizational agility rather than reinforcing the organizational sluggishness that we know to be dangerous in a disruptive environment, and which traditional bureaucracies have generally exacerbated.

As an example of how DevOps changes the game for bureaucracy, in the next chapter I’ll explain how security teams can enforce their security rules in DevOps through automated tests and guardrails and through early participation in design and engineering. When they do so, they’re still experts occupying roles in Weberian hierarchy-space, and they still impose bureaucratic controls on the DevOps teams—it’s still their automated tests an IT system has to pass—but they no longer need to act as gatekeeping trolls who leap out of the shadows at the last minute to croak “no!” Or, using the language of the next chapters, they provide lean and enabling bureaucratic controls to empower the developers, and a process by which their bureaucratic controls could be continuously improved.

Bright Empty Terms

Some management theorists suggest we’ve entered a postbureaucratic world where new forms of organization are better suited. They speak of “fluid organic systems” and “innovative integrative cultures.”7 They emphasize competition or collaboration between parts of the business rather than rigidly delineated roles and predefined rules.8

Other management theorists argue that these postbureaucratic models are actually just bureaucracy in another guise.

Organizations in which, for example, there is reliance upon a set of core norms, rather than a detailed set of rules and procedures, may be more intensively “bureaucratic”—in the Weberian sense of being dominated by a logic of formal rationality that deploys these norms instrumentally, with a view to streamlining the means of established ends. From this perspective, “post-bureaucratic” features and forms of organization are, perhaps, better characterized as “hyper-bureaucratic.”9

These theorists are disturbed by the shiny, propaganda-like, bureaucratic-feeling language in which neobureaucracy is often couched. Graeber, for example, notes “a peculiar idiom that first emerged in such circles, full of bright, empty terms like vision, quality, stakeholder, leadership, excellence, innovation, strategic goals, or best practices.”10 Wilmot goes further:

Phrases such as “moving away from a silo culture”, “putting customers as the heart of all decision-making”, “decentralizing into neighbourhood teams” are redolent of “post-bureaucracy”-speak. As argued earlier, they are potentially consistent with the drive of formal rationality to calculate improved means of attaining existing means. But, when the underpinnings of bureaucratic ethos and principles are neglected, a likely outcome is an escalation of the pathologies of bureaucracy—in the form of paralysis and disorganization—without remedial virtues.11

Some write of businesses as complex networks that constantly reconfigure themselves.12 In my previous books I’ve drawn on sources like Joseph Clippinger III’s The Biology of Business to present the idea of businesses as complex adaptive systems (CASs). The idea of a CAS is based on biological systems that continuously adapt to survive natural selection. Managers in a CAS set up “fitness” parameters and then leave the business free to evolve, expecting that the processes most fit to deliver successful results will naturally survive. Agile IT approaches are consistent with such postbureaucratic views of the business enterprise: they’re based on team accountability, informal networks, customer-centric design, and rapid adjustment through feedback, controlled not top-down but through evolution and adaptation. At the same time, they often follow very structured frameworks; bureaucracy, you might say, still lurks in the background.

Perhaps this debate is missing the point. These “postbureaucratic” approaches may be equally bureaucratic—but they may all the same be better bureaucracy. Today’s digital techniques, while they erect bureaucratic structures, change the nature of bureaucracy by eliminating or attenuating its disadvantages. For example, many bureaucratic controls that were previously enforced by mechanizing human behavior can now simply be mechanized.

Doing so eliminates the soul-deadening work of administration and the petty exercises of power that enter, unbidden, into bureaucratic administration. We can separate the mechanical, bureaucratized part of what employees do from the creative, satisfying part, and let the employees focus on what motivates them. Bureaucracy, through automation, becomes background to the real work of delighting customers or citizens; it can stop being coercive, bloated, and petrified, and start being enabling, lean, and learning.

Risk and Outcomes

Bureaucracy is often not the right tool to use. There are many areas (most areas?) where control should be loose and informal or where there’s a risk that rules, rather than results, will become the focus. Areas where principles and values and good management skills can substitute for heavy-handed governance. Places where we want employees to bring themselves—their personalities and perceptions—to their role.

The tools of the digital age can help us narrow the scope of bureaucratic controls in an organization in at least three ways. First, they reduce risk; with lower risk, we can substitute less onerous controls. Second, they allow us to put controls on outputs rather than process; this is a key area where today’s knowledge-work economy differs from Weber’s manufacturing-centric milieu. And finally, management through values, a practice highly refined by companies like Amazon, makes it possible to widen the spaces between bureaucratic controls.

A combination of DevOps and the cloud is powerful for reducing risk. The cloud reduces business risk because with it infrastructure can be replaced at any moment, whereas outside the cloud the hardware purchased upfront might turn out later not to meet the company’s needs. Infrastructure can also be scaled up or scaled down without penalty as a company’s needs change. Organizations using the cloud can try out new business ideas inexpensively and with no commitment; for example, we can use machine learning, augmented reality, or virtual reality to design new customer experiences. DevOps reduces business risk further by frequently delivering small, incremental features so that the company can continually check to make sure it’s getting the right results and, if necessary, adjust course or discontinue investing before much damage is done. As risk is lowered, bureaucratic red tape can be peeled off.

At the same time, speed and lowered risk mean that controls can be placed on outputs and outcomes rather than on the processes that produce them. In MI-CIS-OIT-003, for example, our requirements were at the level of “deliver frequently” and “work backward from the customer” rather than at the detailed execution level of MD-102’s demands like “write an analysis of alternatives with the following sections.” We could measure whether a project team was “delivering frequently” or “working backward from the customer” because results were quickly and frequently being delivered.

In manufacturing, it makes sense to streamline the activities that produce the product through rules and well-defined processes. In knowledge work, however, doing so is rarely effective. You can’t tell people how to think; even telling them how to prepare an outline or a mind map is probably not going to improve a company’s competitive position. Instead, you’ll do better to put controls on their output—making sure their code is secure or that their external communication follows branding guidelines. Of course, this has led to troll-keeping behavior in the past, but through automation, fast feedback, and the shift-left technique I’ll describe in the next chapter, we can repurpose our trolls.

Values and Principles

As DevOps has arisen, a new management style has also emerged that reduces the need for formal bureaucratic structure: the use of agreed-upon values and principles to align employees’ activities. Employees are expected to use their judgment in applying the principles to each of their decisions; managers oversee their work by giving them feedback on how they do so. The principles are a common language across the enterprise, so employees can coordinate their activities and arrive at joint decisions consistent with the principles yet formed through their diversity and interaction.

In his study of bureaucracy at the gypsum factory, Gouldner noted that bureaucracy took hold in one part of the factory—the part that produced gypsum boards—but not in the mining operations. His explanation was that the miners shared a strong set of values and cultural norms that determined their actions. In Gouldner’s words, “The informal group and its norms, then, constituted a functional equivalent for bureaucratic rules to the degree, at least, that it served to allocate concrete work responsibilities and to specify individual duties.”13

Amazon similarly uses shared values and shared mechanisms to avoid heavy-handed bureaucracy. The company is grounded in a set of fourteen leadership principles that guide hiring, employee development, work activities, and decision-making throughout the enterprise.** They include values like “Customer Obsession,” “Bias for Action,” and “Have Backbone; Disagree and Commit.”

Because employees are expected to act based on these principles, they can largely be left free to make decisions on their own. They can have productive discussions asking each other, “What’s the most customer-obsessed way we can do such-and-such?” Managers can coach their employees on better applying the principles, thereby fostering continuous improvement.

In places where standardized processes are important, Amazon has introduced mechanisms, tools that they’ve found effective in executing on the leadership principles. Chief among them is the mechanism of the PRFAQ—a combination of a press release and Frequently Asked Questions (FAQ) that’s used to frame discussion about new products and services. The author of a PRFAQ begins by writing a press release, pretending that the proposed product is already complete and is being launched, making clear its benefits to customers. The FAQ section includes answers to questions the author would expect from within Amazon and outside. The PRFAQ is read and discussed as a sort of business case, with others contributing ideas and asking questions, until it is perfected or discarded.

The fourteen leadership principles together with mechanisms like the PRFAQ guide employees’ activities in a way that accomplishes much of what bureaucratic rules would do. But they fail some of the tests for Weberian bureaucracy: role distinctions are mostly erased because decisions are made by arguing about the application of the principles, and anyone who can present a case that their solution is more customer-obsessed or more biased for action will likely win, regardless of their organizational position. They also fail as rules to be applied rigidly and universally, since rather than determining actions they’re used to support proposed actions. One could also argue that they are not “impersonal” as in a Weberian bureaucracy; instead, they are meant to be inclusive. Employees bring their unique points of view, the things that make the company diverse, to the process of generating and assessing creative ideas that implement the principles.

The principles don’t eliminate the need for traditional bureaucracy: Amazon still has expense reimbursement policies, codes of conduct, nondisclosure agreements, security reviews, brand guidelines, and plenty of other formal and “impersonal” processes. There’s a weekly operations review to ensure that our services perform to our high standards, and a standardized process for making and reviewing budget requests.

The rules and standardized process are just background support for what really matters to Amazon: innovating on behalf of customers and remaining the world’s most customer-centric company. Customer Obsession, Bias for Action, and the other leadership principles keep employees focused on the objectives and provide a basis for judging ideas while giving them room to innovate and continuously improve customer services—opening a space between the bureaucratic rules, so to speak.

Bureaucracy provides guardrails and repeatable, simple processes for the administrative tasks that employees don’t want to spend time on. Principles provide a flexible context that establishes the goals toward which the employees should direct themselves. The actual day-to-day work is innovation, expert technical execution, continuous improvement, and changing the world for the better.

How to Fix Bureaucracy

There are three things we must do to eliminate bureaucracy’s Kafkaesque aspects. We must make it lean by removing waste and shrinking lead times. We must make it capable of learning; that is, changing as the environment changes and as better ways are found to accomplish goals. And we must make it enabling—that is, helpful as a way to get things done rather than a no-saying, gatekeeping, troll-controlled impediment.

Lean Rather Than Bloated

Think of MD-102, with its eighty-seven documents and eleven gate reviews. It asks employees to fill out templated forms, wait for approvals, produce status reports, and sit in meetings. There’s a goal to all this busy work: risk reduction. But isn’t it possible to accomplish that goal equally, or even better, with a less costly and less time-consuming process? One that is leaner and speedier? We can find out by applying the Lean toolkit, the discipline that is used in Lean Manufacturing, Lean Six Sigma, and the other Lean practices that descend from the Toyota Production System.

Learning Rather Than Petrified

Bureaucracy requires that we apply rules universally and fairly. Its roles and rules are necessarily rigid in the sense that they are applied without exceptions and by following a formalized process. But this says nothing about how the rules are made. It’s not an essential characteristic of bureaucracy that its rules don’t change, only that once they’re set they’re applied rigorously.

And that’s precisely what we must do: make our bureaucracies capable of learning. That, in turn, requires that we set up feedback loops that tell us how well the rules are working, sensing mechanisms that let us know when new “best” practices exist, and mechanisms for continuously improving the rules.

Enabling Rather Than Coercive

Is the primary purpose of the rules to control employees’ activities by restricting them, or to empower employees by giving them a structure within which they can innovate and be productive? The distinction may be subtle, but it makes all the difference between Kafkaesque nightmare and Blakean pleasant dreams.

Weber’s idealized bureaucrats use reason to efficiently accomplish objectives. That, in itself, is enabling: it supports employees in working together to get things done. Unfortunately, bureaucratic structure can also be used by officials to control others for their personal satisfaction. Or it can establish well-tested protocols for getting work done and set guardrails that allow employees to work safely, quickly, nimbly, and with confidence. We’ll prefer the latter option—to make bureaucracy enabling rather than coercive.

A Very Geeky Analogy (Part Two)

If we can make bureaucracy lean, learning, and enabling, we can use it to organize a company effectively, at grand scale. In the analogy I introduced earlier, bureaucracy can be like an IT architecture that makes extremely complex systems possible by orchestrating the activities of microservices—bureaucrats and workers—through formal and logical activity patterns.

To push the analogy even further, in a well-formed bureaucracy we use loose coupling as a design principle so that each component—microservice, team—can innovate independently, knowing that the result of their combined activities will be the ultimate goal of the organization as a whole. Each component can be individually optimized, as can the overall algorithm that orchestrates their activities—that’s the principle of leanness. Each is checked into version control where it can be refined and improved and refactored—that’s the principle of learning. And each provides capabilities that can be used by the others and can rely on the overall design and the tooling to take away stress and toil—that’s the enabling part.††

You might object that formal design is a good practice for code but not for human interactions. That’s often true—which is why we should restrict the use of bureaucracy to those cases where it helps us. But there are many cases where formal interactions between people are helpful, especially when you try to coordinate the activities of many diverse people toward a defined goal, or where routines can reduce anxiety. When you walk into a restaurant, you know more or less what to do—tell the host at the front desk you have a reservation, get shown to your table, look at the menu, order your steaming bowl of strozzapreti.‡‡ For most of us, a stressless experience.

Verdict: No Sniveling

Willmot says that it’s not “simply a matter of reducing the number of forms or files but, rather, creating and processing those forms and files in such a way that is consistent with the bureaucratic principles of fairness, justice, equality, and so on.”14 Our next task is to examine what bureaucracy looks like when it is lean, learning, and enabling. Then we’ll bring back the Monkey, the Razor, and the Sumo Wrestler to teach the bureaucracy how to get there.

When bureaucracy is in your way, you’ll have to do something about it. You have a few choices: (1) you can accept its impediments with an attitude of learned helplessness, whining like Epictetus’s pupil in the epigraph to this chapter; (2) you can try to make the bureaucracy go away, which is rather like telling Moby Dick to stop thrashing against your tiny whale boat; or (3) you can try to fix the bureaucracy by making it into a better bureaucracy. For the rest of this book, we’ll focus mainly on option three, with only a small bit of whining and whaling.

*	Gregor Samsa is the protagonist of Kafka’s “The Metamorphosis.” Mr. Schwartz’s tongue is firmly in cheek, as he earlier said that Samsa turned into a dung beetle, not a cockroach. -ed.
†	See Schwartz, War and Peace and IT, for an explanation of the bobbleheads. -ed.
‡	“Wears the pager”: software developers respond to emergencies (operations specialists used to); “automate all the things”: DevOps jokey language for “automate everything”; “master branch”: don’t delay before merging different programmers’ changes together; “peer code review”: all code gets reviewed by another programmer before it can move forward. -ed.
§	DevOps teams use “blameless” retrospectives, which encourage all team members to find the root causes of problems without blaming themselves or others. -ed.
¶	With all due respect, -ed, I think that’s what “blameless” means. -au.
**	Here’s the complete list of principles: (1) Customer Obsession, (2) Ownership, (3) Invent and Simplify, (4) Are Right, A Lot, (5) Learn and Be Curious, (6) Hire and Develop the Best, (7) Insist on the Highest Standards, (8) Think Big, (9) Bias for Action, (10) Frugality, (11) Earn Trust, (12) Dive Deep, (13) Have Backbone; Disagree and Commit, and (14) Deliver Results. -au.
††	“Loose coupling”: the “inside” of a microservice doesn’t matter to other microservices; “checked into version control”: code is stored in a database that keeps track of changes; “refactored”: improved without changing its functionality; “toil”: repetitive, unrewarding work. -ed.
‡‡	Strozzapreti, which literally means “strangled priests,” is a kind of Italian pasta. Beginning in A Seat at the Table, Schwartz has been referring to it often, probably because he enjoys the name. By coincidence, it is also the name of my university in Milano. -ed.