Bureaucracy DoSing

Let’s say I have a website about why I think puppies are great, and someone else hates puppies. They get really angry about my website, angry enough that they think it shouldn’t be available anymore. They are technically savvy, so they employ what’s called a Denial of Service, or “DoS” (/dɒs/, doss), attack to try and take it offline.

A DoS attack attempts to make an online service, such as a website, unavailable by overloading it. A simplistic (but common) form of this is Distributed Denial of Service, where a bunch of “bot” computers all hammer the website at the same time to make it overload and fail.

More sophisticated forms often take advantage of the underlying behavior of the service. For example, the attacker can send data to the server claiming it is about to send a request of some moderate size (say, 2 megabytes, which is 2 million bytes) and the proceeds to send the data at a very slow rate (such as 1 byte every minute). Because the server continues to receive data, and the data is all correct, it must keep the connection open and dedicate resources to servicing the attacking client. The client can open many such connections, and tie up server resources.

Another form is amplification, where the attacker sends some data to the server constructed such that, in order for the server to respond correctly, it has to send back many times that amount of data. In this situation, again it is low cost for the client to perform the attack, but high cost for the server to respond. This disproportionality is the common thread for DoS attacks.

Bureaucracy DoSing is this same disproportionality in interactions between humans, where a request from one person can result in an outsized amount of work for the person requested. This is common in large corporations (though any organization is subject to it).

For example, say Sally sends a question to HR about their parental leave policy. There’s a few different responses HR could give:

1. Not Bureaucracy DoSing: Respond to the question, citing and linking the appropriate policy document. This is optimally helpful, and is not Bureaucracy DoSing.
2. Not Bureaucracy DoSing: Respond to the question with the policy document, advising Sally to read it. This is somewhat helpful, and so it is still not Bureaucracy DoSing.
3. Definitely Bureaucracy DoSing: Respond to Sally requesting she fill out the Request For Document Access form, and the Leave Policy Request form, and submit them back to HR and Legal through the official channels where there is a 2-6 week turnaround for request approval. This response has created much more work for Sally, who now might decide to simply abandon the question altogether.

Another example: Frank is trying to understand how to integrate a system service he is working on with another system owned by a different team in a different part of the organization. He reaches out to the product lead asking for guidance.

1. Not Bureaucracy DoSing: The project leads responds saying they should have a quick meeting to go over it, and in the meantime gives Frank some documents to review around this process.
2. Not Bureaucracy DoSing: The project lead responds asking for more details about what they are trying to do, saying he can better help once he have that clarity.
3. Definitely Bureaucracy DoSing: The project lead responds with documentation to review, and requests that Frank file a ticket. The ticket form requires Frank submit a security assessment for the proposed integration, an architecture specification, and the product review. Frank has none of these, and it is not clear how or why they should be required at this stage.

In all cases, Bureaucracy DoSing is focused on discouraging the requester from pursuing their request rather than denying them outright. The point for the one doing the DoSing is always to put the “ball in their court” in the lowest effort way that maximizes the amount of effort the requester has to go through to move forward. This means the requester is always at fault for not having accomplished whatever the task was.

Note that a bit of bureaucracy can be valuable: there is a minimum amount of effort the requester should be required to put in to get time and effort from the requested party. Additionally, Bureaucracy DoSing can be used to counter Bureaucracy DoSing. If the request from Frank is short but requires a length, work-intensive response, then Frank has engaged in Bureaucracy DoSing, and a well-constructed response can force Frank to put in effot that moves things forward without dumping his work on someone else’s plate.

Bureaucracy DoSing should not be confused with systemic bureaucracy, which is where processes are implemented over time and the requirements on the requesters becomes heavier and heavier. Bureaucracy DoSing can only occur when there is discretion on the part of the person employing it, where they are intentionally creating more work than necessary in their response.

Low trust environments are the dominant reason for Bureaucracy DoSing: if the requested party does not trust the requester, they will not want to dedicate time and effort to help. After all, they don’t know if the request is actually important and worthy of their attention, or if it is a frivolous attempt to offload work.

The best way to counteract this is by establishing personal relationships first, which makes people more likely to trust your judgement, and they will want to help. If you don’t have an existing relationship and are unable to create one, provide as much context as possible without overwhelming them. Receiving a request that is effectively demanding something, but totally opaques as to why, is a substantially different experience from receiving a request that explains the related background and impact¹.