Kafka in the C-Suite: Bureaucracy, Resistance, and the Digital Turn

There is a scene, or rather a sensation, that repeats itself across time and professions: the quiet frustration of waiting for an answer that never comes, submitting an output whose purpose is unclear, knocking — figuratively or literally — on a door that leads only to another corridor. This is Kafka. And if Franz Kafka ever needed a new setting for his dramas of helpless persistence and obscure authority, the modern corporate suite in the construction and infrastructure sectors would welcome him like a lost brother.

This man would have made for a wonderful engineer. On the other hand, if you’re looking for some insights on his relationship with architecture, take a look here.

In The Castle, Kafka’s protagonist, known only as K., attempts to gain access to a mysterious bureaucratic structure that governs a village, receiving contradictory instructions, facing unseen authorities, and finding himself entangled in endless delays.

Kafka was not writing about bureaucracy in the narrow sense. He was unveiling a philosophy of organization: systems that devour purpose in the name of process, that manufacture opacity under the guise of structure. Max Weber saw bureaucracy as the “iron cage” of modernity. Kafka handed us the key and showed us it fit no lock.

Today, one could argue that K. wears a tailored suit, carries a tablet, and sits in coordination meetings on Teams. The Castle is still there: it just has a dashboard.

1. Digital Liberation or Algorithmic Entrapment?

In the early years of digital transformation, especially in the AEC industry, a narrative of emancipation reigned. Collaborative platforms, parametric design, and integrated data environments promised to dismantle silos, flatten hierarchies, empower a new generation and restore control to those at the creative core. We told ourselves that the machine would set us free.
But freedom is a slippery concept when mediated by workflows.

Enter this week’s thought experiment: what if digitalization, instead of breaking the iron cage, is just reinforcing it with smarter, faster, more flexible bars?

This is not a neo-Luddite lament, of course, even if the Luddites were right on some accounts but that would be a conversation for another time. This is a provocation born of love and frustration, the kind you feel while watching someone embrace a toxic routine convinced it’s for their own good. In theory, digital systems should reduce friction. In practice, they often reproduce — and refine — old frictions in sleeker forms: approval workflows nested in SharePoint, permissions tangled in CDEs technological solutions, metadata fields more rigid than paper stamps ever were.

Today we ask ourselves: are we building platforms or palaces of paper with digital bricks?

And we do so through a sort of dialogue between Kafka and the C-Suite — all those people starting with a C as in CEO, CFO, and imagining the BIM manager as a CBO — not to romanticise dysfunction, of course, but to illuminate its logic in an age of platforms. Through Kafka’s literary lens, we examine the tension between rigid structures and the agile, digital processes meant to replace them. We’ll explore:

how bureaucratic logic persists through digital form;whether resistance is still possible, or simply recoded;if innovation always tends toward control once scaled.

You will find no manifesto here, but you may find resolve. Like Donna Haraway’s Cyborg Manifesto, which urged us to navigate post-human complexity without retreating into nostalgia, today’s read calls for creative defiance within the system, for allies who code workarounds and design humane interfaces. It calls for us to see the system not as enemy, but as terrain.

Donna Haraway: if you don’t know her, read her work2. Kafkaesque Bureaucracy in the AEC Industry

Anyone who has worked on a large infrastructure project knows the dance: a model-based drawing must be approved, but first by the BIM Coordinator, then by the Project Manager, then perhaps the Quality Manager, who sends it to the Contractor, who sends it to the Client, who forwards it to a third-party reviewer, who — after weeks — returns it with a note: please adjust line thickness in the legend.

No one quite knows who made the final decision. No one assumes responsibility for the delay. And yet the delay is real, measurable, and costly.

Here lies the first sign of the Kafkaesque: decisions emerge, but from nowhere in particular. Like in The Trial, where Josef K. is arrested without being told why or by whom, professionals in the AEC sector often find themselves held accountable to standards or timelines that are enforced by ghostly chains of command. You submitted the IFC model? Excellent. But has it been approved by “the client’s BIM auditor”? Has the technical note from the MEP team been “seen by legal”? No one knows who “legal” is.

This is not mere inefficiency: it is a structural opacity. An architecture of invisibility that survives the very systems meant to streamline it.

Digital tools have, paradoxically, amplified the phenomenon. With every added layer of visibility (a new field, a tracked change, a revision number), we have multiplied the points of potential obstruction. We have encoded the bureaucracy, made it faster, yes, but no less mysterious. The submission has a status. It is “Under Review”. But by whom? For how long? According to which logic?

This is the world Kafka described: not a failed system, but a system so successful in its self-perpetuation that failure becomes irrelevant.

2.1. Bureaucracy as Ritual and Labyrinth

We spoke about labyrinths before, as places to explore and in which you find yourself, but the concept has another, darker and less optimistic structure, because it isn’t obvious that you’ll ever emerge from such a labyrinth. Like ever.

In The Castle, K. is summoned to work in a village governed by a distant and inscrutable administration. He tries to clarify his role, to access the Castle that summoned him, but every encounter brings contradiction, and every path leads back to confusion. Even those who live in the system — secretaries, messengers, minor officials — do not understand how it works. They comply, they guess, they improvise. Sounds familiar?

This is not bureaucracy as rule-following, which can be virtuous, but bureaucracy as ritual: a set of motions performed because they feel official, even when they no longer serve a function. We stamp because we’ve always stamped. We request a PDF and a print because someone, somewhere, once asked for both. We log in to multiple platforms, because each department claims ownership of a different one.

The AEC industry is steeped in regulatory demands, contract layers, and liability fears, and loads of them are there for everyone’s safety, but this means it’s especially prone to this ritualism. Kafka helps us see that it’s not only inefficiency at play: it’s the need for reassurance in complexity. When confronted with risk, we multiply approvals not to clarify responsibility, but to distribute it until it dissolves. And like Kafka’s labyrinths, AEC bureaucracy in a complex project often seems not to have a centre. The goal is always just beyond the next corridor. Submittals “in review” for weeks. Change requests that “must go to committee.” Meetings to discuss whether to have another meeting. The moment one hears, “I’ll escalate it and come back to you”, Kafka smiles.

2.2. Case Parallels: Legacy Workflows in Construction and Design

Consider the legacy of drawing approvals on megaprojects: engineers mark up PDFs, which are printed, signed, scanned, and uploaded again, despite the presence of model-based coordination tools. Or the infamous “redlines” that still pass physically between departments in organisations boasting of digital capabilities.

In one project I observed, a CDE had over 1,200 permission groups, with overlapping rights and no documentation. Every change to access required a ticket to IT, a validation by the BIM Manager, and an approval from a “digital lead” whose role was unclear even to themselves. This was not accidental. It was ritualistic. It was designed for control but not designed well.

The digital transformation of AEC is littered with such examples: tools added on top of tools, not to eliminate bureaucracy but to reproduce it in new forms. An agile process is introduced, and within months, it is codified into fixed sprints, gated reviews, and slide decks. We seem to be particularly vulnerable to this form of inertia-in-motion. Rooted in regulatory obligation, insurance requirements, public procurement laws, and inter-organisational complexity, it has built a castle of its own, composed of transmittals, RFIs, submittals, change orders, minutes, logs, stamps, and revisions. Each document a step in the ritual. Each platform — be it Procore, Aconex, or Autodesk Construction Cloud — claims to streamline. But often what they streamline is the ritual itself, not its necessity.

Consider the infamous approval loop for shop drawings in large infrastructure projects. The subcontractor submits. The contractor reviews. The designer checks. The owner comments. The consultant corrects. Then back again. By the time the drawing is finally marked “approved as noted,” the site team has already adapted the solution, off-record, to meet the schedule. The system, in this sense, lags behind the work it governs, like a nervous general fighting yesterday’s war.

And yet — here’s the tragic twist — it persists because it feels safer. The ritual, however hollow, promises a sense of control. Like Kafka’s protagonists, we cling to the process because it is all we have. We fear the chaos that might emerge in its absence. But we rarely ask: what kind of order have we accepted in its place? So what can we do?

3. Digitalisation as Resistance

As I said, it all began with a promise, and it was a beautiful one. AEC professionals were told that digitalisation would free them from the shackles of fragmented files, unclear drawings, and tedious rework. I know it because I was one of those who promised it.

With BIM came the vision of a single source of truth: models coordinated in 3D space, information embedded, updates reflected instantly. With CDEs came the hope of shared context: stakeholders aligned around a common environment. With Lean Construction, before that, came the mantra of waste reduction, flow optimisation, and respect for people.

Digital tools didn’t just promise to make work faster. They promised to make work make sense again.

To a weary generation of professionals that approached an industry made of pointless paper trails and bureaucratic circularity, this was more than a technological upgrade. It was a declaration of intent: that clarity could be restored, coordination achieved, and time reclaimed not through more meetings, but through smarter systems. In the early days, this hope felt almost revolutionary.

But revolutions are fragile things. And systems, once adopted, have a tendency to reassert control.

You all know the quote…3.1. Platforms, Dashboards, and the Allure of Control

The platformization of AEC — where every workflow is absorbed into a dashboard, every decision logged, every model federated — offered the dream of control, and who could resist that dream? Dashboards show progress. Logs document accountability. Analytics promise insight. For executives, this is governance with a UX. But here’s the twist Kafka might appreciate: in seeking transparency, we often create new opacity. As permissions multiply, data validation rules tighten, and workflows lock into “best practice” templates, the system that once promised agility becomes yet another guardian of inertia. The dashboard may be real-time, but the people behind it are waiting for access, for clarity, for permission. When a model is held hostage by locked parameters or a platform demands metadata for a minor revision, agility collapses under the weight of its own infrastructure. Like the Castle, the system functions… well, technically at least. But why it functions, how it empowers (or disempowers), becomes increasingly unclear. We can see everything, and understand nothing.

And yet, resistance lives on.

It’s the one on the left, in case you’re wondering…3.2. The Digital Architect as Insurgent: Scripting, Automating, Circumventing

Within this landscape, a new figure emerges: the digital insurgent. She is the architect who writes Dynamo scripts to batch-edit model parameters that the platform refuses to expose. He is the BIM Coordinator who reverse-engineers IFC exports to strip out proprietary clutter. They are the teams using Notion boards, private Slack channels, and shared Google Drives to bypass clunky approval systems that slow real collaboration.

This is not sabotage. This is pragmatic resistance: the art of circumventing friction without breaking the system. It is motherly in its care for the team’s sanity, heroic in its defiance of slow decay, and rebellious in spirit: if the process no longer serves the work, then let the work reshape the process.

The scripting architect doesn’t wait for permission: they write the workaround.

But this raises a deeper question: why must resistance be necessary at all? If digitalisation was meant to liberate, why has it required an underground? In Kafka’s world, even the smallest act of rebellion — like asking the purpose of a form — was subversive. In ours, writing a script to fix a naming convention can be equally transgressive. And yet, this is where the future lies. Not in replacing bureaucracy with more software, but in reclaiming agency within and against the software we are given.

That’s why we teach our architects to code, or at least we try to. Not because automation is the future, but because insurgency must be fluent in the language of its captors. Let’s see how.

4. Subversion in the System

Ok, so, digital tools were meant to clean up the mess: streamline communication, reduce friction, enforce consistency. And yet, behind every formally approved workflow lies a second life: undocumented, flexible, human. That, in the words of many veterans of project delivery, is how shit actually gets done. The rebel lives not in protest but in practice, but the battleground is increasingly digital.

4.1. “Work-arounds” and Shadow IT as Digital Disobedience

Let us call things by their real names: the Excel sheet duplicated from the CDE, updated manually but shared instantly? That’s a protest. The Power BI dashboard built from an exported CSV because the official analytics suite “takes too long”? That’s sabotage. The script that auto-generates parameters to bypass a field validation? That’s civil disobedience in digital form and, of course, I admire it by default.

These acts of everyday insurgency say: the system is not serving us, so we will bend it, bypass it, or build around it. Shadow IT — those unofficial tools and workflows that live just outside sanctioned platforms — is not a failure of policy but a symptom of unmet need.

Kafka showed us that resistance in a bureaucratic system is rarely loud. It is often quiet, ambiguous, hard to trace. Today, it might look like a technician who uses an old version of Revit just because it runs an AddOn the new one broke. Or like a team that coordinates real decisions in WhatsApp, while uploading sanitised notes to the project portal. These actors aren’t trying to break the rules because they don’t understand them: they’re trying to get home in time for dinner.

4.2. The Informal Layer: Chats, Calls, Networks of Trust

Trust shouldn’t flow through permissions but through people. It still does, even when you don’t see it. Beneath every formal digital platform is an informal layer: the Teams call that actually decides what the minutes will say; the email that quietly settles a coordination issue without escalating it; the chat thread where real opinions are voiced, before the sanitised version is submitted.

This layer is alive with risk and reward. It bypasses bureaucracy, but also bypasses record. It’s the lifeblood of agility, and the loophole through which liability slips.

To pretend it doesn’t exist is managerial fantasy, and to demonise it is organisational hypocrisy. The better path is to acknowledge, nurture, and give form to this informal layer not by formalising every word, but by designing systems that trust users without abandoning traceability. As Donna Haraway reminds us: staying with the trouble means living with imperfection, not purging it.

4.3. Organisational “Kafka-beaters”: Hacking Bureaucracy with Humane Tech

Every system has its K — someone caught in its gears, bewildered but determined — but some organisations foster a different figure: the Kafka-beater. This is the professional who understands the system and how to outsmart it, not to undermine it, but to make it work better for everyone.

The Kafka-beater writes the onboarding manual that actually tells you where to find the real project files, knows which approval gates are performative and which are enforced, builds plug-ins to streamline drawing exports because the out-of-the-box tools add unnecessary steps. They are hackers, in the noblest sense: people who believe that systems should serve humans, and not the other way around.

These figures are rarely recognised in org charts. They exist in liminal spaces: power users, digital mentors, senior interns who quietly reconfigure folders because no one else will. They are heroic, yes, but not because they fight dragons. They are heroic because they fight friction. And they keep the machine running when the manual fails.

They are the kind of people I look for during the early stages of a transition to BIM because, with a little nudge, they’ll be your champions. If we want humane digital organisations, we must find and support our Kafka-beaters, give them room to script, to question, to challenge defaults. Let them redesign workflows instead of presenting out-of-the-box solutions. Let them train others in quiet resistance. The future isn’t built solely by compliance. It’s built by those who know when — and how — to say: no, but like this instead.