The Soul of Maintaining a New Machine
Viktor Zhdanov's historical project involved Xerox technicians who relied on social interactions and shared narratives to address complex photocopier issues, emphasizing user education and communication for effective maintenance.
Read original articleViktor Zhdanov, though not widely recognized today, played a pivotal role in a significant historical project. The narrative focuses on the maintenance of complex Xerox photocopiers in the mid-1980s, highlighting the social dynamics among technicians responsible for their upkeep. These technicians faced challenges due to the machines' intricate designs and the varied user behaviors that often led to malfunctions. Julian Orr, an anthropologist, studied these technicians and discovered that their problem-solving relied heavily on informal communication and shared experiences, termed "war stories." These narratives not only facilitated knowledge transfer but also established the technicians' reputations within their community. The technicians often found that user errors were a primary source of issues, leading to the adage, "Don't fix the machine, fix the customer." The technicians' work was characterized by improvisation and a deep understanding of the machines, which were often idiosyncratic and required tailored solutions. The relationship between technicians, customers, and machines was crucial, as effective communication and education of users were necessary for successful maintenance. Orr's research underscored the importance of social interactions in technical work, revealing how technicians navigated the complexities of their roles while fostering a collaborative environment.
- Viktor Zhdanov contributed significantly to a major historical project.
- Xerox technicians relied on social interactions to solve complex machine issues.
- User errors were often the primary cause of photocopier malfunctions.
- Technicians shared knowledge through narratives, enhancing their community's expertise.
- Effective communication with customers was essential for successful machine maintenance.
Related
An arc welder in the datacenter: what could possibly go wrong?
A former IBM engineer fixed a cracked metal frame on a stock exchange's printer in the 1960s. A later inexperienced repair attempt caused chaos, emphasizing the need for expertise in critical system maintenance.
The AI we could have had
In the late 1960s, a secret US lab led by Avery Johnson and Warren Brodey aimed to humanize computing, challenging the industry's focus on predictability. Their legacy underscores missed opportunities for diverse digital cultures.
Stop installing that software – you may have just died
A tech support incident at an Air Force base during wargames led to a simulated bomb disabling the base, causing work stoppage. The story highlights inefficiencies and challenges in tech support roles.
Yes, I am being intolerably smug – because I ignored you and saved the project
Nina, a tech support professional, successfully restored a WAN connection during a datacenter maintenance task, earning her boss's respect and highlighting the importance of checking basics in troubleshooting.
Computer Archeology: Exploring the Anatomy of an MS-DOS Virus
The article discusses two former computer enthusiasts who created a benign MS-DOS virus named PARANOID in the early 1990s, reflecting on their experiences and the challenges of accessing old source code.
- Recognition of the transformative work done by Xerox technicians and the importance of understanding the social dynamics of repair work.
- Discussion of the practical insights gained from studying technician interactions, which led to significant improvements in copier design and maintenance.
- Critique of management's failure to fully appreciate the value created by repair technicians, often viewing them merely as cost centers.
- Personal anecdotes highlighting the complexities and challenges faced by technicians in the field.
- Recommendations for further reading on related topics, emphasizing the ongoing relevance of these discussions in technology and management.
I knew Orr’s and Suchman’s work (they worked in a physically adjacent area, but completely different group, though we were all under John Seely Brown and because they were nice people). Thankfully I was grown up enough to be polite, but really I was such a techno-determinist that I figured user problems came from ignorance.*
To be fair, I was not the only one: the insights described in this book draft surprised a lot of people, not just how they improved the copiers but how those two even approached the problem (starting with the sociology of the repair workers). It sure surprised Xerox management. But I’ve heard it said many times that this work led to restructuring the paper path in a way that justified (paid for) everything spent on PARC.
I did grow up of course and now do see my work (machines, chemistry, etc) as a small part of a large social system. A successful company has to base its product plans starting this way.
To choose an example of failure to appreciate the social scope (but not pick on it) the crypto folks spend their time on technology, based on a social model they want to exist rather than the one that currently does. I think it’s a big reason why it’s barely impacted the world in, what, 15 years? Xerox was the same, and it helped them sell a lot of copiers, but didn’t make them as ubiquitous as they could have been. Another example: everybody laughs at Google for launching “products” that go nowhere and are quickly forgotten. We all know it’s because of a screwed-up, internally-focused culture. But sometimes a product succeeds without marketing (e.g. gmail, at the time) because it happened to be matched to the actual, external need. It makes this kind of continuous failure even more damning.
* TBH, 40 years later I have not 100% shed this view — e.g. my attitude towards complaints about git. Maybe this means I’m still a jerk.
On a related note, I'd like to highly recommend Lucy Suchman's work, mentioned in this article as Plans and Situated Actions: The Problem of Human-Machine Communication, but the updated version now called Human-Machine Reconfigurations: Plans and Situated Actions. The new version has several extra chapters and some other revisions. I've read it several times, and had my mind blown each time.
They were amazing at doing things which really mattered: shrinking an A0 architectural drawing down but maintaining aspect ratio. Adjusting offsets for the print for binding signatures, so the 1st and 16th page was not too far out because of wrapping around the other 8 pairs of pages. Even just working out how to rotate the pages for N-up printing. But the GUI sucked. I think they called ours "the bindery" because it's main gig was doing PHD from soup to nuts, binding included.
The repair techs had the most amazing flight cases, packed with tools which served one specific purpose.Like, A doohickey to adjust the corona wire, without dismantling the imaging and toner roller, with a tonne of equipment hovering over your head on a gas-lift. Screwdrivers with very very carefully chosen lengths. Torque wrenches. It was high tech meets motor racing meets.. IBM.
I am told they were paid better than many computer techs. The IBM guy was paid IBM scale to fix it on IBMs timescales. the xerox guy did more random shit, with more devices, more often.
They had a very corporate look. that amazing briefcase or six. Suit, tie. Very acceptable.
I know a guy who worked for a paper-folding-and-envelope-stuffing company and it was very similar culturally: can-do, fix anything, but working on giant multi-million dollar machines which were used twice a year to do tax mailouts, and election materials, and the rest of the time rented to the original spam merchants for 10c per thousand mailouts. The secondhand value of these machines were like photocopiers: Really significant. He was brought out of retirement to help take one apart into TEU equivalent chunks to be shipped to Singapore from Brisbane. His retirement gig at one point was repairing Espresso machines, he said it made him feel familiar and useful.
The era which was the end of the typing pool was fascinating. All kinds of arcane roles which only make sense in the absence of email and tiny printers everywhere. Some of those jobs had been there from the days of hand-copying, Dickens-era and before.
The article claims that PARC paid for itself (1) through the anthropological sociological studies of copier repair technicians which revealed shortcomings in the engineering of the copiers and resulted in changes to the paper path and handling in newer designs and significantly reduced maintenance cost and difficulty. Two, enabling information sharing between repair technicians over radios and technician created and maintained documentation, saved the company 5-8% of service cost and these innovations were resisted by services management which was invested in the idea that copier repair technicians should be cheap, interchangable monkeys. Three, Xerox management likely left significant money on the table because they fundamentally and willfully misunderstood copier repair and copier repair technicians and the value they were creating for the company. Likely, mostly because repair was seen as a cost center which in an ideal world would be eliminated entirely.
1. It's really astonishing how much and in how many ways PARC paid for itself and yet business literature and likely Xeroxes management often focuses on the money left on the table for others to grab and asserts there was a failure.
We don’t carry tools in briefcases because it makes us appear white collar, but because the shell is hard and protective, there are many sizes, and the boxy interior can be formed to however you like if you use foam and cut it to fit your tools. Briefcases fit readily into many tight spots for transportation. The photo shows the usual layout of tools that techs use. Companies sell high end equipment in briefcase-like containers because it keeps them safe and waterproof in needed situations.
Not a big fan of the anthropology aspect. It’s a job. Techies improvise, it’s not a clandestine operation to fix a machine.
Also I found areas where the product could be and needed to be improved and my manager went to bat for those changes and they made huge differences. 40% shorter support calls, 60% less calls, and a performance increase of 35x because I brought up things that looked like that would help customers.
It drives me nuts how management and engineering can't seem to relate to how customers actually use the product and actively refuse to want to learn. Not all companies, of course, but in most cases when I introduced a developer or engineer to a customer and they discussed or watched how the product was used, there's often a huge gap but at least a bridge was formed sometimes.
I am beginning to think that how a role is compensated can totally overwhelm what the company wants done. Sales people will make the sale promising the product can do something when it can't. Managers will do things that cut costs when a small increase will produce massive dividends.
Anyway, these printers were finicky, and I remember we were visited by the same two Xerox service techs on a regular basis. In addition to repairs, they were faced with the near impossible task of keeping the toner (which was dispensed by hand from a plastic container, similar to powdered clothing detergent) off their white shirts and ties. We saw those guys so often that even now, 38 years later, I still remember that one of them was named Randy.
I'm reminded of how an anthropology professor, under the name "Xerophonics" released an album "Copying Machine Music" consisting purely of sampled photocopiers
https://music.apple.com/us/album/copying-machine-music/60110...
I've not been able to get into the third chapter, but it looks equally interesting.
I open the article and it is not about "maintaining" the old Data General and DEC machines (the original "The Should of a New Machine" was about the race to create the first 32-bit minicomputer --between DG and DEC. DG was a former group of DECies --spoiler: THEY LOST! It was a hell of a lot more worthy a battle than Qualcomm vs Apple, which is almost the same situation.) The old XEROX machines were boring as they competed with IBM in the business space whereas DG and DEC were more focused on Science and Engineering. The XEROX Star was pretty cool, but not nearly as cool as History has recorded it to be (apparently because Steve Jobs, who later became an icon of sorts himself, once saw a demo and rushed to recreate it using microprocessors in his poorly implemented Lisa/Mac system). I developed on all of these machines (though I only used the Star to write documentation for my VMS internals code hahah) and these are MY opinions.
Related
An arc welder in the datacenter: what could possibly go wrong?
A former IBM engineer fixed a cracked metal frame on a stock exchange's printer in the 1960s. A later inexperienced repair attempt caused chaos, emphasizing the need for expertise in critical system maintenance.
The AI we could have had
In the late 1960s, a secret US lab led by Avery Johnson and Warren Brodey aimed to humanize computing, challenging the industry's focus on predictability. Their legacy underscores missed opportunities for diverse digital cultures.
Stop installing that software – you may have just died
A tech support incident at an Air Force base during wargames led to a simulated bomb disabling the base, causing work stoppage. The story highlights inefficiencies and challenges in tech support roles.
Yes, I am being intolerably smug – because I ignored you and saved the project
Nina, a tech support professional, successfully restored a WAN connection during a datacenter maintenance task, earning her boss's respect and highlighting the importance of checking basics in troubleshooting.
Computer Archeology: Exploring the Anatomy of an MS-DOS Virus
The article discusses two former computer enthusiasts who created a benign MS-DOS virus named PARANOID in the early 1990s, reflecting on their experiences and the challenges of accessing old source code.