The case for sabotage
Creative tactics for a tech worker strike
This piece was written by an anonymous software engineer as a response to our call for new organizing tactics in the tech sector.
Since 2019, the US has seen a wave of tech worker unionization, in both classical Silicon Valley-esque software and web-based companies and in video games. This labor movement has not exploded, stymied perhaps in part by the subsequent and connected wave of tech industry layoffs beginning in 2022. But some of the new unions of professional tech workers have bargained their first contracts and even gone on strike, enormous firsts for a larger population of millions of tech workers whose labor sits at the nexus of finance, logistics, communications, entertainment, and, well, every other industry. At a time when the AI tools we develop and use are being built on the labor of exploited ghost workers in the Global South, when Google, Microsoft, and Amazon’s contracts with the IDF to provide cloud computing for automated missile- targeting in the genocide of Palestinians in Gaza, when the Department of Homeland Security is scraping social media to abduct students off of the street and detain scientists at the border, our position as workers who build these and similar tools becomes highlighted not by flashlights but floodlights. The same is true for bread-and-butter issues; at a moment of precarity (caused by layoffs and automation hype) in a previously secure labor market for technologists, the need for collective bargaining power is stark. This strategic position makes us a sleeping power: imagine what an organized tech worker movement could do! Imagine what threat we pose to capital and to states, if we organize enough to be able to shut down the services we build and maintain. What a threat! What a promise.
But the wave of activism in the US tech industry in the late 2010s and the labor action taken in the early 2020s has trickled. The protests over #metoo and against government contracts seem to have had no repercussions for Big Tech, and there have been no more than just a few new tech unions per year since 2022. The tech worker movement is at a crossroads: after years of action and with few successes, is it time to rethink our leverage?
We are beginning to discuss amongst ourselves: how do the tools of the labor movement, forged in struggles for decades before we even considered them relevant to us, work for us? Every worker in every industry has a labor process unique to their specific position in the economy, the things they build or provide with their labor, and their position in their company. But there are particularities to the tech industry that make traditional labor actions more difficult to carry out, or even less powerful, given the way we work and what we build. A strike, where we withhold our labor until our demands are met, is the most powerful tool in the toolbox of organized labor. But what does it mean for us engineers who pride ourselves on building resilient systems that can run without our presence to go on strike?
Software engineering as a job is fundamentally about automation. We create software to do work that would be difficult or tedious for a person to do, or impossible to do by hand because of the size and scope of the task. What we produce are, in the case of software products, objects which can be electronically copied and sold an infinite number of times after our work (writing the software) is done. In the case of websites, it is one product that can be accessed an infinite number of times by users once we finish our work. There are maintenance tasks, and the ever-evolving work of creating new features or products to sell or attract users, but generally, once we complete a task once, we are finished with it. This means that if we put our keyboards down, so to speak, and walk out of the office (or home office) on strike, the parts of the machine which we automated would continue running, generating revenue for its owners, without us. The companies we work for will continue to collect revenue from those systems while we are picketing outside the office.
If classic labor movement tactics won’t map directly onto our workplaces, then we will need to think about our workplaces differently in order to create tactics that will work for us.
I propose we think about the modern tech company as a sociotechnical system, one in which people and technology (and those people’s understanding of the technology and their work processes) interact as parts of a whole, complex infrastructure. A tech company is a sociotechnical machine because it is made up of the software that its workers have created, the third-party software workers use to do their jobs, the hardware it all runs on, and, of course, all of the people. The people create software and run every other function of the company to contribute to the overarching system that generates profit for the company’s owners and executives. And unlike other sectors, where removing workers from the company would immediately disrupt production, doing so at a tech company wouldn’t.
By conceiving of the modern tech company as a large machine, made up of these component parts, we can imagine ways to disrupt the machine using collective and individual action in creative ways both old and new, that will allow us to win our demands.
How to Destroy a Machine: Sabotage
In 1970, Boston’s Broadside & The Free Press published a short essay titled “The Technology of Computer Destruction.” In it, the anonymous computer scientist author put forth, in case it were useful for readers, information about the most important, expensive, and vulnerable parts of a computer. Details included specifics on not just where data was stored (punch cards) but specific ways to damage it that would be most difficult to repair and replace (“if the cards are bent, ripped, or even seriously frayed at the edges, they cannot go through the card processing equipment”). The information included analysis not just of the physical electronics, but also the human labor that went into creating and repairing them. In the case of replacing damaged punch cards, they described the contemporary use of low-wage women workers to do manual computational labor and data-entry to support the machines. They wrote, “If there are many cards destroyed, and they are ripped in half and scattered, it will not be practical to restore the data file in this manner.”
The essay had a broad audience. The 60s and 70s were, famously, a time of frequent protest action, including many cases of what researcher Max Larson calls “computer center sabotage,” especially as part of the student movement, most especially the Black student movement, from 1968-1971. These actions are “sabotage” in the sense shared, perhaps surprisingly, by both both Elizabeth Gurley-Flynn of the Industrial Workers of the World (IWW) and the Office of Strategic Services (the forerunner to the CIA): any action that will slow down or stop the activity of your opponent, in an attempt to encourage them to give in to your demands or slow them down enough to keep them from achieving their aims. If strikes are an open battle with the bosses, Gurley-Flynn wrote, then sabotage is the “guerrilla warfare” of the working class.
In the cases Larson documents, students effectively sabotaged campus computer centers because they were identified as not simply solitary machines but as sociotechnical sub-machines in the larger megamachine of the University, and the University as a sub-machine of the larger megamachine of the military industrial complex. The computer centers were expensive and thus valuable to the university, but they also sat at the nexus of crucial activity of the university’s research and thus valuable even more. Without the computers, university activity would entirely stop.
The students’ demands ranged from anti-war to pro-race-and-ethnic- studies-curricula to pro-Black Panther to pro-worker to anti- gentrification. To win those demands, the sabotage of the 60s and 70s addressed both social and technical pieces of the sociotechnical machine of the computer centers. This included some physical machine breaking of technical pieces. In at least one case, echoing the advice of “The Technology of Computer Destruction”, this included the destruction of punch cards. Their tactics also included disruption of the social parts of the machine: the occupation of the computer centers themselves meant that no researchers or human computation workers could do their work. Occupations included, of course, the implied threat of physical damage to the machines or their data, but often the students’ demands were met before this happened.
Note that the students did not need to know exactly how the computers were being used to further the actions of the universities or the larger hegemonic institutions they supported, nor did they need to know much about how the computers themselves worked under the hood. Simply occupying a building was enough. But as “The Technology of Computer Destruction” makes clear, it is possible to do direct action inefficiently if your analysis of where power lies is incorrect: large metal chassis of the giant computers of the 1970s were expensive but easy to replace, and damaging them did nothing to damage the data that would take tens of thousands of hours to replace. The tactics of the student protestors were varied, with varied results. Taking a hammer to the outside of the computer was not nearly as disruptive as ripping up paper cards.
The author of “The Technology of Computer Destruction” demurred on the subject of which computers to destroy or why, but encouraged the reader to make their own choices about when to deploy the tactics described therein. But it is not difficult to identify when computer systems are being used, purposefully or not, to harm and destroy. The student activists of the 60s and 70s knew that their universities were important sites of struggle. That was step one. Next was determining what parts of the activity of their universities were ripe for disruption, to grind the university to a halt. From Mario Savio’s oft-quoted speech, from the birth of Berkeley Free Speech Movement, about how activists could stop the machine (in this case, the university):
you've got to put your bodies upon the gears and upon the wheels, upon the levers, upon all the apparatus -- and you've got to make it stop!
Step two, therefore, is identifying the correct gears to throw their bodies upon, and students at dozens of universities chose the computer center. Step three is what the anonymous computer scientist lays out in their essay: what are the best ways to disrupt the turning of that gear?
This essay is for tech workers who have decided that the answer to step one (where the site of struggle is) is their own workplace. The following will attempt to aid you with steps two (identifying a good gear) and three (determining the best way to make it stop).
Mapping the Machine
Step two will require power mapping. Power mapping is often an exercise of listing all of the entities related to a social or labor movement organization for the purposes of a campaign, and analyzing their support and influence for the organization in order to pinpoint which entities to pressure or lean on for support. It can also be the classic labor movement tool of workplace mapping- mapping everyone who works for a company and who they know, and how likely they are to join a union. It is an exercise of laying out, visually, all of the component pieces of a system and how they are connected to each other, in order to identify powerful entities and weak links.
The modern tech company, here defined as a Web 2.0-style firm whose main product is software, software-as-a-service, or a digital platform which runs on code, is a sociotechnical machine made up of many component pieces. For the purposes of power mapping, the component pieces are technological (software and the hardware it runs on) but also human (made up of all of the people who work at the company). An accurate analysis of how the system of the company works, and therefore sites to disrupt by stopping or slowing down parts of the system, requires mapping several different ways that these pieces are related to each other.
The first is a map of the technological parts of the machine. Gather a group of trusted engineers, designers, data scientists, and other technical workers at the company. Build a software architecture of the services and systems they work on, and annotate it with notes on what systems are actively being built or changed and which are merely being maintained. Annotate also where the software runs: does it run on computers owned by your company, or on someone else’s computers (the cloud)? Next, annotate the software architecture with your best understanding of how revenue is created in the company and where money is spent. How much does it cost the company to run each service or piece of software? Where does revenue come from, which pieces of the software are sold directly to users or are user-facing and against which subscriptions are sold?
The second map is an organizational chart of the company. You will likely find this in HR documents or in slides from an all-company meeting where the most recent company reorganization was announced. It may or may not be complete or easily available to you, and you should take caution in trying to get ahold of it so as not to raise red flags to management. A list of everyone who works at the company and who their manager is would also allow you to recreate a hierarchical org chart. Finally, annotate the software architecture with the human parts of the system that are reflected in the org chart but not the other map. Add the customer service team, which is a crucial part of maintaining the user base and building trust for the company when product engineers push new features or run new experiments. Add the marketing team, without which the company could not grow and continue creating surplus value at an increasing rate. This is a good time to do a workers’ inquiry, with as many trusted coworkers that you can from as many places within the company as possible: what labor do you do every day? What does it create for the company, and how? What would happen if you stopped doing it? Annotate the org chart and the software architecture with your new understanding of how value is created in the company and where.
The third map is a version of an organizational chart, but from the perspective of the real ties between workers, and between workers and managers. The org chart is a map of labor relations in the company, but it is not complete: it is a map of what HR believes are accountability ties between employees– who reports to whom? But the modern tech worker isn’t accountable only to their direct manager, but also to coworkers on other teams and departments who use the things they build or who they are themselves dependent on for data, for software, or for other aspects of their jobs. To create a workplace social map, you will need to gather workers from across the company and make a list of everyone who works there. You will need to annotate this social map with the real human dependencies of the company: who does each person actually work with on a day-to-day basis, and therefore have a professional and social relationship with? How do these people work together? Is the marketing team dependent on data scientists to provide analysis of monthly metrics? Is the data science team dependent on data engineers to provide the raw metrics? Is the data engineering team dependent on the front end engineers to implement tracking cookies to collect those metrics? Annotate this map with the strength of those ties: who hangs out together outside of work? Who respects whom? Who eats lunch together every day? One way to lay this out is to picture a social network graph, with nodes (each worker) and edges (a relationship between two workers).
Once you have created all three of these maps, overlay them. For instance, annotate the org chart (the second map) with the names of the services and systems in the software architecture that each team is responsible for (the first map).
Ask the following questions:
Where is value being created for the company? In what technological and what human parts of the machine?
Where are a critical number of workers who share a desire to resist the actions of the firm or desire to achieve the aims of your group? What clusters exist already, and how are they related to the creation of that value and to each other? Where in the map of people is there potential, given the relationships that already exist, to bring new people on board?
In the lists of (1) and (2), where is there overlap?
Your answers to (3) are your potential sites of resistance. Where is value being created where you also have organizers and allies who are ready and able to take action? Rank them in order of most to least vulnerable to disruption, and most to least value-creating to the company.
Now, with your list of sites, the next question is how to disrupt them.
Breaking the Machine
Imagine a tech company that operates a website that customers visit and view frequently. The site hosts features that users pay the company for directly. The core product of the company already exists, but the company is in a constant process of development of new features for the core product in order to keep its users and grow its user base, to generate new revenue. The software architecture includes the main services that power the website and its core features: website code and the web servers it runs on (in an enterprise cloud system the company pays for), enterprise database software (which the company pays for and which also runs on servers in the cloud), caches (also on servers in the cloud), load-balancing and DDOS-prevention services, DNS services, etc. The company employs many engineers, data scientists, designers, product managers, analysts, customer service agents, an IT team, a security engineering team, a marketing team, external and internal communications teams, finance, HR, and legal teams, all of their managers and directors, and finally the C-suite. In order to build the core products the company uses to make revenue, the company uses CI/CD tools, enterprise GitHub, Google Drive (to hold its documentation and other communications), Figma and other front-end and design tools, and a staging environment of its own architecture for testing.
If we think about a tech company as a machine, we can come up with tactics that involve disruption of different parts of the machine. First, we’ll discuss the human parts. Some of the functions of the machine are not based in software or hardware at all. These are the parts of the labor process that can be more easily struck in the classical sense. Customer service, marketing, and sales teams that do day-to-day work of keeping the company running can strike and have their lost labor felt immediately. What other work tasks are done every day whose loss would be felt in the short term? What human labor is done every day to keep that machine running? Who could accidentally get locked out of their work email at an important time? Who could call out sick? Who could work so slowly that, in conjunction with other actions being taken elsewhere in the company, an important task doesn’t get done, but not so slowly that it's obvious that the issue is their fault?
Next, the technological parts of the machine. Not all functions of the machine that provide the core product of the company are based in software or hardware that is external-facing.
Continuous deployment software, staging and development environments, test databases, etc., are all necessary parts of developing and deploying new code, which in many tech companies today is a daily if not multiple-times-a-day event. What might disrupt the ability of workers to use these tools to push new code? Accidents happen.
Disrupting the ability of the company to produce new features or products in the future could involve withdrawals of efficiency that keep workers from being able to build new parts of the machine. The most obvious example is a strike during a period of heavy work before a product release deadline. Striking on the day the product is to be released is too late: the work has already been done. But a longer strike, sustained during the period when the bulk of the development work on a new feature is meant to be done, would keep forward progress on development from occurring and prevent the realization of new value in the medium-term for the company. Ask about deadlines for upcoming work: what deadlines are important to the company’s ability to raise or create revenue, and why? Is there an upcoming round of funding, an end-of-quarter, or an investor meeting coming up? Is there a large new product feature set to launch? Now work backwards from those deadlines to determine when work is getting done that, if not done, would keep the company from hitting those deadlines at full strength. One example could be an e-commerce company increasing server capacity ahead of the holiday shopping season. Withdrawing your labor in a strike or other form of sabotage on Black Friday could be powerful, but only if there are active work tasks you are expected to do on Black Friday itself, in order to keep the shopping experience smooth for users. And once the day is over, your ability to continue withholding labor to sustain pressure on your bosses is gone. It is likely more impactful to begin pressuring your bosses by withholding labor months ahead of time, in September or October, when you are meant to be hardening your systems and increasing server capacity in anticipation of Black Friday.
This gives you weeks if not months to build pressure on your bosses and threaten the success of Black Friday, which means sustained pressure on them and even opportunities to escalate from smaller, less risky actions, to larger riskier and more public ones as time goes on. A slowdown in September can become an on-call sickout in October and then a strike in November.
There are other ways to withdraw efficiency during such a period as well: refusing overtime or “crunch” work either publicly or privately (simply not doing work during those hours, calling out sick during this period, or doing the work slowly or poorly such that the work does not get done) can have a similar albeit smaller-sized outcome. These actions are much more similar to a slow down or “work to rule” strike, withdrawing efficiency from the company without obviously acting in direct opposition to the company’s aims or your job description (as taking down servers on purpose by introducing bugs would do), and therefore carries less risk. These types of actions are plausibly deniable, especially if you are working on a task that has never been done at the company before. Who is your manager to say how long it should take to do X, Y, or Z?
There are actions that only specific teams of workers can undertake, given their position within the company and within all of the parts of the machine. Product engineers, who are aware of upcoming releases of new features, can alert the customer service teams who play a crucial role in supporting the adoption of new features, about upcoming launch dates, and customer service workers can use this information to time a sickout or strike to most effectively disrupt the launch. DevOps engineers, software reliability engineers, or other workers who operate or maintain services that other services depend on are well-placed to, in coordinated fashion, ignore their on-call rotation.
Ignoring pages in the middle of the night can massively disrupt the day-to-day operations of a company (although there is an element of luck involved, as, ideally, these issues do not arise on a predictable schedule or frequently enough that this can be relied on to occur in the short- term). This kind of action works best if all of the workers in the on-call schedule or pager system coordinate being unexpectedly sick, being asleep, or having dead phones when the need arises, so that fallback pages also fail to rouse anyone with the expertise to reboot a needed system. Accidents, again, are known to happen.
There are other disruptive actions that workers could take to prevent management from undermining the withdrawals of efficiency described above. The IT team, responsible for setting up the new development environments, virtual machines, and corporate-issued laptops for newly- hired workers or sub-contractors, could all call out sick the week of a strike, even if they were not on strike themselves, preventing the company from hiring short-term contractors to scab. Moving documentation of parts of the software architecture that engineers work on, or of human-labor work processes that teams like marketing, customer service, finance, and communications work on, to places that are difficult for outsiders to find can also help prevent contractors or managers from undermining strikes, slowdowns, or sickouts.
There are many parts of the machine of a tech company that are more purely technological. In a future essay, we will turn to a more thorough discussion of, and tactics for, breaking those parts of the machine.
This list of examples is by no means comprehensive. The labor process for tech workers is vastly varied from team to team, company to company, and is rapidly evolving with the introduction of generative AI productivity tools and a tightening labor market. It remains to workers, together, in their specific workplaces, to determine upon which gears to throw their bodies.