IT: The Biggest, Baddest Bureaucrats

This post is an excerpt of Mark Schwartz’s The (Delicate) Art of Bureaucracy: Digital Transformation with the Monkey, the Razor, and the Sumo Wrestler. 

IT Bureaucracy: Not Fooling Anyone

Among the biggest, baddest, bullyingest bureaucrats in a large enterprise are the IT folks. Yes, us, the very IT folks who so hate bureaucracy when we find it imposed on us. Your password, we say, must be in a format that guarantees you’ll never remember it, and you must change it every few nanoseconds, and you need to remember your old password in order to change it to something else you won’t remember. If you notice a problem in our IT systems, you must fill out a trouble ticket; if you want a new feature or some help, fill out another ticket. Or write something called a user story card in the format “As a bureaucrat I want to force people to use the ticketing system so that they will grind their teeth with frustration.” Everything we touch turns to standards. Then, once we’ve set them, we put trolls in everyone’s way to enforce them. We make employees sign Acceptable Use Policies before we let them use the company network acceptably. Never, we say, connect your personal device to the company network, and be sure to lie to us when we ask if you’re using your personal device for company business.

If you’re an IT person, you’re probably sputtering, “But! But! We have no choice! These are best practices! Hackers are trying to steal our cat videos!” Quite so, quite so. See my point? For the rest of the enterprise, these policies are handed down by purported experts, IT people, the cave dwellers who don’t care about getting the real work of the company done, and they are endlessly frustratingly bureaucracy.

When we discover better ways to use technology, it’s natural for us to want to force people to use them. If we notice there’s inefficient duplication of IT systems across different lines of business or office locations, we want to centralize purchasing and architectural decision-making. We need governance mechanisms to control our technologies because  .  .  .  well, there are lots of good reasons.

Digital transformation forces us IT folks to confront our standardize-and-govern mentality. Will technology free us from bureaucracy, or will it entwine us further in it? It’s worth some thought as we manufacture our bureaucratic goo.

Mechanization

The connection between technology and bureaucracy goes deep. Max Weber, understood that there was a mechanical, nonhuman aspect of bureaucracy. In Economy & Society he states:

The professional bureaucrat is chained to his activity in his entire economic and ideological existence. In the great majority of cases he is only a small cog in a ceaselessly moving mechanism which prescribes to him an essentially fixed route of march. The official is entrusted with specialized tasks, and normally, the mechanism cannot be put into motion or arrested by him, but only from the very top.

With that quote, we see the core tension of bureaucracy before us. Bureaucracy is what we get when we think through the best way to perform each operation, then set up rules to make sure employees always do it exactly that way. But once we do, it seems like we’ll have mechanized employees’ activities, and we might just as well replace them by machines. What role can individuals play in a system that moves under its own logic and power?

As I’ve suggested, bureaucracy echoes many of the intellectual developments of the modern era. Just as Napoleon was organizing his army into logical ranks and files and creating the Napoleonic Code, the German philosopher G. W. F. Hegel was publishing his major work, The Phenomenology of Spirit, arguing that history represents the development and unveiling of an “absolute idea,” or Geist, and that we as individuals are caught up in that larger development which proceeds inexorably around us. Karl Marx, one of the “Young Hegelians,” picked up on this idea and wrote about history as an inevitable progress toward communism, with individuals essentially relevant only to the extent that they play a part in that drama. After Hegel and Marx the role of an individual in this “machine” of society and history became a focus of philosophy in the works of, among others, Kierkegaard, Nietzsche, and the existentialists, and in Melville’s vision of an uncaring, hostile natural world in which we are tossed about. Bureaucracy, in other words, was hardly original, just a recapitulation of what was already going on in academia.

[perfectpullquote align=”left” bordertop=”false” cite=”” link=”” color=”” class=”” size=””] A good deal of our discomfort with bureaucracy comes from our anxiety at being treated like expendable parts in a machine.   [/perfectpullquote]

In Theory of Social and Economic Organization, Weber says: “The fully developed bureaucratic mechanism compares with other organizations exactly as does the machine with the non-mechanical modes of production.” There’s a deep ambiguity in Weber’s conception of bureaucracy. On one hand, he talks about it as “domination by knowledge” and a meritocracy—that is, a human effort. On the other hand, he talks about an impersonal application of rules, a mechanical effort.

A good deal of our discomfort with bureaucracy comes from our anxiety at being treated like expendable parts in a machine. It’s a legitimate fear, since bureaucracy is motivated by the assumption that, left to themselves, people will screw everything up. Bureaucracy is used to make sure recalcitrant workers actually work; to restrict employees who would otherwise pad their expense reports; to stop government officials from taking bribes. Because it’s based on a fundamental distrust, bureaucracy feels like it exists only because there’s no way to fully eliminate people. Alfred Krupp, the munitions manufacturer, said it bluntly:

What I shall attempt to bring about is that nothing shall be dependent upon the life or existence of any particular person; that nothing of any importance shall happen or be caused to happen without the foreknowledge and approval of management; that the past and the determinate future of the establishment can be learned in the files of the management without asking a question of any mortal.

We should be particularly sensitive to this in our era of digital transformations, for bureaucracy, in this view, is about using an algorithm to guide human behavior. In Weber’s day, computers didn’t exist; the closest he could conceive was an organizational system where people execute algorithms themselves.

A Very Geeky Analogy: Part One

Allow me to elaborate this analogy, because I’m going to suggest that (1) the thought pattern behind bureaucracy is very close to the way technologists think, and (2) perhaps counterintuitively, this suggests a way that we can minimize the torments of bureaucracy by literally automating them away.

[perfectpullquote align=”right” bordertop=”false” cite=”” link=”” color=”” class=”” size=””] Bureaucracy, then, is the algorithms (rules) and their authorized users (roles) that control the behavior of an enterprise. Bureaucracy is an organization’s software.   [/perfectpullquote]

In my geeky analogy, the roles in a hierarchical, bureaucratic organization are like the microservices of an IT architecture. Just as each microservice has a well-defined and bounded role in the architecture, so each role in a bureaucracy is bounded through a division of labor and technical specialization. As roles in a bureaucracy interact through formalized patterns, so do microservices through their formal interfaces (APIs), which represent a contract that the microservice “agrees to,” thereby lending calculability to its activities. Officials in a bureaucracy enact only their roles; their human biases do not affect their performance. Similarly, as long as a microservice fulfills its contract, its internals don’t matter; this is the principle of loose coupling, or the separation between interface and implementation. As microservices are orchestrated to perform a business function, each having a place in an algorithm that delivers an IT capability, so bureaucracy orchestrates the roles in its organizational chart to deliver on the goals of the enterprise.

Bureaucracy, then, is the algorithms (rules) and their authorized users (roles) that control the behavior of an enterprise. Bureaucracy is an organization’s software.

Bureaucrats by Nature

It turns out that the “alphas” of Homo bureaucraticus are the software engineers, those who’ve learned to control others by standardizing processes and roles and providing automation that essentially forces everyone to do things their way. In Adler’s words:

Technology is know-how that has been objectified and thus rendered relatively independent of the skills of specific actors. Know-how can be objectified in equipment and associated software programs; it can also be objectified in organizational procedures and structure.

Consider again my keynote story in the introduction (the case of the corkboard’s disappearing diagram). Software developers, in trying to improve a process, effortlessly found a bureaucratic solution. The mechanism they chose was a formal, defined set of steps that would apply to all team members, whether they’re forgetful or not. It’s an algorithm; a technologist’s solution to social interaction.

From another angle, software code itself is a kind of bureaucracy. A rule-maker—called a programmer—writes code to represent rules that will be followed by the computer and the user, constraining the behavior of both. “Code” is a “codification” of expected behaviors. It uses “validations” to restrict user behavior and allows employees access only to functions that fall within the boundaries of their job descriptions. It is embedded in a business process that may be specified in a user manual, an SOP document, a tradition of how the software is used, or instructions from a pointy-haired manager.

[perfectpullquote align=”left” bordertop=”false” cite=”” link=”” color=”” class=”” size=””] From another angle, software code itself is a kind of bureaucracy. A rule-maker—called a programmer—writes code to represent rules that will be followed by the computer and the user, constraining the behavior of both.   [/perfectpullquote]

Code happens to be a special kind of rule that is “executable”; that is, a policy which is detailed and formal enough that we can build a machine to execute it. If we didn’t have the machine, it could be executed, mechanically, by a person  .  .  .  which would make the connection to bureaucracy more evident.

If this seems like a stretch, spend some time with software users. You’ll find that for them, code enforces arbitrary or strange “features” and restrictions on them, which seem to come from some hidden corner of a bureaucracy. They do things this way and not that, because that’s how the software is set up. They’re forced into strange workarounds, perhaps entering values into fields that were clearly not designed for their purpose, because it’s the only space available. If they need a change to the code, they enact formal rituals and sacrifice budget dollars to gain a position in a product backlog.

The backlog, by the way, is a truly ingenious piece of bureaucracy—a last in, nothing out queue that imprisons requests until some inscrutable process grants them a hearing. Like Joseph K. in The Trial, the user never finds out what their feature request is accused of or when and how justice will be rendered.

Standards, Centralization, Greek Names

It’s been a commonplace that IT must standardize. We just must, because—you know—otherwise bad stuff would happen. Without standards, independent parts of the organization might make duplicative or inconsistent choices. We might spend money on several pieces of technology where a single one would do; we might have to train our people to support multiple platforms; we might introduce security risks as employees use tools we haven’t vetted. Software engineers might go off and write code in a programming language like Ruby or Malbolge or Khepri or something other than a standard CIO-soothing-language like Java.

If it’s not clear that standards are a kind of bureaucracy, consider an employee who’s not allowed to use a piece of software or hardware they’ve used in a previous job that’s better than the one IT has standardized in their current job. Maybe they’re told they must use an iPhone instead of an Android phone, or vice versa. If technologists want to make up names for their server computers, they must choose names from Ancient Greece rather than Ancient Rome. Or they’re stuck with an old version of an operating system because it’s still the company standard.

[perfectpullquote align=”right” bordertop=”false” cite=”” link=”” color=”” class=”” size=””] The backlog, by the way, is a truly ingenious piece of bureaucracy—a last in, nothing out queue that imprisons requests until some inscrutable process grants them a hearing.   [/perfectpullquote]

In many cases, the benefits of standardization outweigh the costs; it’s a great idea. The standards that enabled the internet—well, they enabled the internet. But knee-jerk standardization often neglects the costs it imposes, for bureaucracy has a cost. We might not be able to take advantage of new technology (say, functional programming languages, which are becoming increasingly valuable), we might not be able to hire programmers who want to program in MobYdIck, or we might frustrate our excellent technologists who know that a better way lies outside the standards.

Closely related is the question of centralization versus decentralization. To Weber, the need for centralization was what drove the introduction of bureaucracy in the first place. But as James C. Scott, a political scientist teaching at Yale, shows in Seeing Like a State, centralization results in a loss of important local details as higher-level abstractions are imposed. He talks about a centralized government’s need to “make a society legible, to arrange the population in ways that simplified the classic state functions of taxation, conscription, and prevention of rebellion.” But such simplifications lose fidelity; the representation they create “always ignores essential features of any real, functioning social order.”

IT suffers from this same oversimplification and loss of detail when it centralizes. Apparently minor differences between two business units cause problems when their ERP systems are consolidated. Shared services and centralized management add overhead by demanding formal interactions between the center and the periphery: ticketing systems, periodic status meetings, contentious prioritization, budgets, chargebacks.

At DHS, we watched a dynamic of centralization and decentralization play out. DHS, remember, was formed through a merger of agencies with very different goals, practices, and cultures. It includes among its twenty-two component agencies FEMA (which has to respond quickly and flexibly to disasters), USCIS (primarily an application-processing agency), ICE (a law-enforcement agency), the Coast Guard (a military organization), and the Secret Service (the agency which guards the president and fights counterfeiting).

[perfectpullquote align=”left” bordertop=”false” cite=”” link=”” color=”” class=”” size=””] Shared services and centralized management add overhead by demanding formal interactions between the center and the periphery   [/perfectpullquote]

Despite this diversity of missions, “corporate” DHS must oversee the whole. It had to devise a framework that would apply equally to all of the component agencies and all of their activities, ensuring that their investments were productive and directed at the right mission needs, that projects were well executed, and that infrastructure remained secure. They had to answer to Congress and the public for runaway investments, and cope with budget limitations when Congress reduced appropriations. This is how MD-102 arose.

Because the overseers were so far removed from our day-to-day activities, their oversight had to be conducted through formal mechanisms and documentation. Each project disaster—and there were plenty—was answered with the creation of new formal controls to reassure Congress and OMB (the Office of Management and Budget) that it would never happen again. But how could there be an alternative? DHS was, itself, overseen.

Joseph K. Files a Ticket

There are many good reasons why IT departments have inflicted ticketing systems on their colleagues, but there’s no denying that they’re a piece of IT bureaucracy that inspires our coworkers with dread and loathing. Tickets are impersonal and unpleasantly formal. They require information to be entered that is only occasionally relevant. They create a formidable “paper” trail, as email follows email with the ticket’s status changes. They trigger predetermined workflows of approvals and handoffs from which deviations are difficult.

[perfectpullquote align=”right” bordertop=”false” cite=”” link=”” color=”” class=”” size=””] I’ve had tickets auto-cancel because no one had taken timely action, and then been directed to a survey asking if I was happy with how my problem was solved.   [/perfectpullquote]

Tickets make employees feel like they’re making requests of a machine. The ticket management process is opaque—who knows when someone will next take an action on the ticket or what they’re busy with now that prevents them from doing so? For all the requestor knows, trolls in a cave somewhere are waiting until they finish barbecuing the last requestor who tried to get their ticket processed faster. A ticket winds its way through organizational silos on its way to fulfillment, with each silo given a seemingly arbitrary SLA (service level agreement) that specifies how slowly it can process the request. I’ve had tickets auto-cancel because no one had taken timely action, and then been directed to a survey asking if I was happy with how my problem was solved.

Imagine what Kafka would make of this process. Joseph K. might fill out a ticket asking what crime he was accused of and would periodically receive status messages: “Your request has now been given the status of ‘pending’!” or “Your case has been routed to the appropriate authorities. Please click here to answer a few questions relating to your case that will help us improve our customer service.” It’s an IT equivalent of “All lawyers are currently helping other defendants. Please continue to wait as your case is very important to us.”

Ticketing systems grew, I think, from the idea that IT is a service provider to the rest of the business. Their intention was to formalize the interactions between the business and IT so that IT could show that it was providing predictable levels of service. But what a great tool for implementing a siloed, specialization-of-labor bureaucracy!

Security, Mom

Imagine you’re a non-IT employee in an enterprise. You’re given IT’s Acceptable Use Policy to sign and told you must take an online security training every year. If you don’t, automated reminders threaten to escalate to your manager. You’re told never to click on an email that looks “phishy”: that is, any email that has misspellings, strange return email addresses, comes from Nigeria, or is absolutely ordinary and appears to come from your mother. Never click on an attachment, the mandatory training tells you, unless it is from someone you trust and not from someone pretending to be someone you trust.

What you see, simply, is a security bureaucracy. The rules come from people you don’t understand, are a barrier to what you want to get done, and can’t be appealed. You’re set up to fail, since you can’t distinguish between an email from a friend and an email pretending to be from a friend. Hide from the trolls—you’re probably already guilty of noncompliance. Good luck.

Compliance Audit

IT enforces company bureaucracy. It helps the enterprise ensure compliance and achieve clean audits. That’s convenient, because today enterprises are subject to an acronym soup of compliance regimes—one part HIPAA to several parts GDPR, FISMA, KYC, and PCI-DSS, salted with SARBOX to taste. These frameworks assign formal accountabilities to particular roles in the organization. To satisfy these  frameworks the company must show that formal controls are in place and effective. If there is any way to do so without bureaucracy, I can’t imagine it.

Since all work flows through IT systems, it is IT that plays the role of bureaucratic troll, essentially posting the signs saying “if you push this door an alarm will sound” and then making sure that the sound is loud and annoying. IT not only enforces compliance but can also demonstrate through its electronic audit trails that compliance has occurred. An automated DevOps pipeline tracks every change made to code. The company can tell who made a change and when, and what follow-on tasks were triggered. When tests are run, their results can be recorded automatically; when deployments are made, it’s a matter of record who did the deployment, when, and what code was deployed. This is bureaucracy made effortless and invisible. Nevertheless, it’s still bureaucracy. The trolls have just found a new home, inside software code.

Agile Bureaucracy

Recall that in Chapter 2, the Chaos Monkey was defeated at one point not by government bureaucracy, but by Scrum bureaucracy. Scrum is a popular Agile IT framework. It provides a structure that incorporates Agile principles within which delivery teams develop and deploy IT capabilities. It’s sometimes considered a transitional phase between traditional and more agile ways of working; while it incorporates Agile principles, it’s nevertheless palatable to established enterprises. Of course it is: it has all the feel of an authoritarian bureaucracy.

[perfectpullquote align=”right” bordertop=”false” cite=”” link=”” color=”” class=”” size=””] Since all work flows through IT systems, it is IT that plays the role of bureaucratic troll, essentially posting the signs saying “if you push this door an alarm will sound” and then making sure that the sound is loud and annoying.   [/perfectpullquote]

In The Scrum Guide, Ken Schwaber and Jeff Sutherland, the creators of Scrum, command, for example: “the Development Team isn’t allowed to act on what anyone else [other than the product owner] says.” Requests for features, according to the Scrum scriptures, must be written as user story cues (“as an alien I want to enter the Earth’s atmosphere and abduct a human so that I can learn about their bureaucracy”), then placed into a product backlog where they’re sorted by a spreadsheet master occupying the role of product owner. The team must stand together for fifteen minutes each day to ask each other precisely three questions: What have you done since yesterday? What will you do by tomorrow? Do you have any impediments? They must estimate story points (what?) and calculate their work velocity by counting those story points (what?), and then flagellate themselves for not accomplishing enough story points (what?). And, as the government auditors pointed out to me, if you change any element of Scrum, you’ve sinned. Here’s the relevant text from Scrum’s inventors: “Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety.”

Verdict: IT—Human, Annoying

If you’re an IT geek, don’t fool yourself into thinking that because you love to get things done quickly and effectively, and because you rebel against rules imposed on you, you’re free from the bureaucratic urge. No, it’s more likely that you have an impressive ability to optimize processes and implement controls by turning people’s freedom into constraints. You, mon semblable, mon frere, are probably a bureaucracy savant.

In my next post, I’ll explain more about the good and bad of bureaucracy, which is essential to learn before we can master wielding bureaucracy for good rather then evil.

Continue reading in Mark Schwartz’s The (Delicate) Art of Bureaucracy: Digital Transformation with the Monkey, the Razor, and the Sumo Wrestler.

- About The Authors

Mark Schwartz

Mark Schwartz is an iconoclastic CIO and a playful crafter of ideas, an inveterate purveyor of lucubratory prose. He has been an IT leader in organizations small and large, public, private, and nonprofit. As an Enterprise Strategist for Amazon Web Services, he uses his CIO experience to bring strategies to enterprises or enterprises to strategies, and bring both to the cloud. As the CIO of US Citizenship and Immigration Services, he provoked the federal government into adopting Agile and DevOps practices. He is pretty sure that when he was the CIO of Intrax Cultural Exchange he was the first person ever to use business intelligence and supply chain analytics to place au pairs with the right host families. Mark speaks frequently on innovation, bureaucratic implications of DevOps, and using Agile processes in low-trust environments. With a BS in computer science from Yale, a master’s in philosophy from Yale, and an MBA from Wharton, Mark is either an expert on the business value of IT or else he just thinks about it a lot.

Follow Mark on Social Media

• 
•