Reciprocal knowledge networks and the iFixit Technical Writing Project -- Conversation with Guiseppe Getto
Article for discussion
“Networked Rhetoric: iFixit and the Social Impact of Knowledge Work,” by Guiseppe Getto, Nathan Franklin, and Sheryl Ruszkiewicz. Published in Technical Communication (Volume 61, Number 3, August 2014). You can read the full text on academia.edu (or if you have access, on STC or Ingenta).
Our conversation
TJ: Guiseppe, I really enjoyed how your article focused on a specific documentation project and your engagement with it. I wasn’t aware that iFixit had such an extensive partnership with technical writing programs across the country. It’s quite impressive.
To start things off, can you provide a brief overview of iFixit’s Technical Writing Project, and how you’re implementing it with your tech comm students? What drew you to study iFixit’s Technical Writing Project in the first place?
GG: Certainly. iFixit’s Technical Writing Project is a service-learning partnership the company has formed with colleges across the country. Essentially, they ship broken devices and tool kits to instructors who agree to run the program in their classrooms. They have an entire curriculum the instructors can use or the instructor can create their own curriculum in service of the project.
The main gist of the program is that the students will use the devices to create repair documentation that will then be added to iFixit’s massive, free wiki of repair docs. The students also get authorial credit so they can add their doc to their portfolio. iFixit technical writers are also very supportive and do peer review of the students’ repair guides as they develop and are available via email for any questions.
I’m always excited to do service-learning projects with industry partners because it provides students with real-world scenarios to respond to. I haven’t had the opportunity to teach the Technical Writing Project since I moved to East Carolina University, but as soon as I do, it’s my preferred choice for teaching technical writing.
TJ: You mentioned that your initial assumptions about the project evolved during some core experiences. You wrote:
“When we realized that Kurt was engaging in a very interesting, and networked, writing process, a writing process that involved a kind of feeling out of all the available affordances among other people, tools, and technologies, we stopped thinking of our study as a simple writing process case study and began thinking of it as a case study of a network, a network involving various interrelated, and reciprocally impactful, components.”
How would you define a network in this instance? Why are networks important in the writing process?
GG: This is a very good question that any academic readers will probably giggle at because this is a question that has fascinated tech comm researchers for decades now. Essentially, what we now know about technical communication is that it’s not just about a writer working in isolation from other people and resources. What I noticed when my students were working in the Technical Writing Project is that the tools they used (literally, from the tool kit provided by iFixit) and the wiki technology they used to write their guides profoundly impacted their writing process. I would have observed a very different process, for instance, if I’d had them just Google information online and write their guides in something like Word.
Essentially, an important implication I uncovered in this study was that student writers need to be put in scenarios that mimic real-world technical communication situations as closely as possible. It’s very different to create a document in a word processor than it is to do so in a wiki viewed by millions of people a month. Everything is different: the workflow, the affordances provided by the technology, the types of knowledge the writer needs to leverage, the expectations of the audience.
After this project, I began to reconsider much of the way I was training students to be technical communicators. I began talking more and more to people in industry about what their day-to-day work lives were actually like. Then I would try to create assignments that mirror those work lives, and the networks of people and resources they draw upon, as closely as possible. My research has obviously been a key part of that process.
TJ: I do think networks are a fascinating dimension of the writing process, specifically in the way they create feedback loops across multiple people. You wrote: “Our goal was to understand how several different kinds of actors rhetorically impacted one another within the network surrounding the Technical Writing Project.” In what way does everyone in the network reciprocally influence everyone else?
GG: This is another meaty question because there are so many possible answers. The prototype theory I develop in the article with my co-authors, something I’ve started calling Networked Rhetoric, holds that when technical communicators are at work, there’s a lot of give-and-take with all the elements of their immediate environment. By “reciprocal impact” I’m invoking a lot of different elements of rhetoric and also Actor Network Theory.
First, in modern rhetorical theory, we know that a communicator’s context is as important to their efforts to communicate as any other element. Many decades ago, rhetoric was viewed as a response to a given situation, but it was largely a linear process: the communicator would encounter an exigence, or a reason for communicating, and would respond with the appropriate means of persuasion.
In the 21st century, we know that things work quite a bit differently. We know this because theorists have advanced the way we think about rhetoric, but also because of all the new communication tools we have at our disposal now. It’s probably too oversimplified to say that today a communicator simply responds to an exigence and that’s the end of it. In an age where technologies like wikis exist, for instance, it’s much harder to put your finger on a starting and stopping point for a communication context.
Think about a guide on iFixit’s wiki: it gets written, say by a technical writing student. And let’s say that the guide is about an older model Nokia phone that isn’t sold anymore, but there’s still an audience of people out there who have them and want to keep them running. So, the technical writing student uses search engines like Google and Bing to research the phone: what are the things that commonly go wrong with it? What parts go out first? What are the biggest pain points users of that phone are experiencing? During this process, the student is also talking to other students and tearing down the phone using iFixit’s tool kit to get at its components in order to document them.
Having found some common exigences for repair, the student now has to create a guide for doing all those types of repair, such as how to replace the motherboard, how to replace the screen, what to do if the keyboard stops working, etc. While drafting this guide, the student is also photographing the phone in stages to depict a repair process. They’re adding photos and instructions to the iFixit wiki, which contains certain affordances for writing guides, such as choosing a specific genre (in this case repair guide), adding photos in a specific format, adding textual instructions in a specific format, etc. The student finishes drafting the guide and it goes live.
Decades ago we used to think that written communication stopped there: the documentation has been published and gone out into the world and now readers passively consume it. With technologies like wikis, however, writing rarely stays the same for long. On iFixit’s wiki, for example, they have a small army of moderators who review every guide that gets published to their site for accuracy. This is in addition to their staff technical writers who also do some of this work while mentoring student writers in the process.
The biggest limitation of student work, as any instructor knows, is the academic semester, however. So, my students would work on their repair guides all semester in various stages, from learning about technical writing in the first place to creating some practice drafts of documentation, to actually starting the Technical Writing Project. But in the end, the student finishes the semester and the instructor has to grade what they’ve produced. Their writing doesn’t stop changing, however, when it’s published to a public-facing website moderated by thousands of professional and semi-professional writers. It keeps growing and getting updated as new exigences arise.
So: it’s very hard now to wall off a specific communication situation and say: “here it is; this is where the writing happens!”
TJ: Ahh, you’re helping me see this reciprocity in much clearer ways, and I think you’re definitely on to something unique here. Let’s dive into some of the theoretical frameworks you draw upon in your analysis. In your article, you wrote,
“A central theme in the body of literature come to be known as speculative realism is the de-centering of the human actor as the sole arbiter of action within networks.” And later you talked about how the spudger (a tool for prying) influenced some of the students. You wrote, “Becky first perceived the spudger as having virtually no affordances for her writing process. When the spudger enabled her to complete a necessary task, dissembling her device so she could document its repair, the spudger also impacted her perception of it, and what it could do for her. In a very real sense, it became an actor in that moment, in the form of a tool that had suddenly demonstrated its usefulness.”
It’s interesting to think of non-human components as influential actors in a network. How did the spudger influence the students? Did the students likewise influence the spudger? Would you say that tech writers have reciprocal relationships with the authoring tools they use (or which use them)? Are the systems we’re documenting influencing us just as we are influencing the systems we document?
GG: Yes, this is at the heart of what I mean by reciprocal influence: the whole non-human actor ball of wax. I know you have a question later about Latour, so I won’t jump into his entire theory now, but let’s just say this guy named Bruno has suggested that we need to look beyond humans for potential actors. Essentially, we need to look at the ways non-humans, like tools and technologies, behave in ways that we previously only thought humans could behave. This has spawned a whole branch of theory, but it has also strongly affected the way tech comm researchers think about communication.
The simplest way to think about reciprocal influence between human and non-human actors is to think about what we mean when we say “actor.” Latour spends a lot of time in his work delving into this question, largely because he’s a French philosopher and this is what such beings love to do in their spare time. And he has a lot of different answers to this question, but mainly he comes down on the side of an actor being an object in a network that somehow changes an element of the network.
So, in the case of a spudger, this was literally a tool developed by people in the repair industry to pry apart devices that manufacturers have done their best to make unfixable. There’s a thin, flat end to get between the two sides of a case and pry it apart. And there’s a sharp, pointy end to push into a small opening, such as a screw hole that has been glued together (yes, manufacturers do nasty things like that to prevent their devices from being repaired by consumers).
If the spudger didn’t exist, then an entire realm of repair documentation might literally be impossible, because it would be so difficult to get into the internal components of many devices without destroying them that people might just give up trying to repair their devices. That whole network of people, resources, and information might not exist, or at least it wouldn’t exist in the same form it does today. So, yes: non-human actors heavily influence communication situations and by making use of their affordances (such as the opportunity to pry apart a small device) we humans also influence the way they are able to impact a given network.
TJ: Let’s talk more about wikis, because iFixit is based on its own open-source wiki. Are wikis, which enable more networks with reciprocal actions, better platforms for the creation of knowledge? If so, why are wikis more or less dead today as a platform for external doc sites? (Granted, iFixit seems to be an exception, as are some others, like Wikipedia.)
GG: This is a very good question that I’ve never really thought of. You have a company like iFixit which was started by two college kids in their dorm room (Kyle Wiens and Luke Soules) and now is one of the key players in the tech comm landscape. And they use a technology that the rest of the industry has largely abandoned.
And as I think about it, the answer seems obvious: wikis open up knowledge. One of my participants, Miro Djuric who was with the company for many years but has since moved on, compared iFixit to Wikipedia. And he basically said in his interview that the reason they chose a wiki was that they didn’t just want to market specific repair guides for specific devices. They wanted to create a community where people could talk about repairing any device.
This is a much different business model than if they had decided they wanted to do a kind of on-demand thing where they created custom guides and then sold them to individual users with some kind of license (an idea that Kyle and Luke apparently entertained back in the day). It’s also the kind of business model that many companies use, however. How many companies out there are creating a product and saying: “hey, we’re going to put this out there. Please use it however you’d like and remake it and also: write whatever you want about it on this public-facing website and we’ll respond. We may moderate your responses, but we welcome your participation.”
Very few companies. Now, this is a hallmark of the open source companies like iFixit and Red Hat and WordPress and Drupal, etc., etc. That’s their mission statement: we’re making this technology and we want you to remake it with a few restrictions. For those companies, something like a wiki is great because it facilitates user input.
But if you want to carefully control knowledge, it’s very bad. And this isn’t to say that carefully controlling knowledge is a bad thing. If you’re creating repair documentation for a nuclear reactor, you probably need to carefully control that knowledge. There’s only a handful of experts in the world who have the knowledge required and including incorrect knowledge could literally be catastrophic.
But also: I do think it has a lot to do with the business model of the company that’s facilitating the documentation. It’s a lot easier to get people to pay money for a product if they can’t replicate it themselves and they have to go back to you for any problems that arise.
TJ: One of the students wrote, reflecting on what he learned from the project, “you really have to check and recheck and recheck your information to be a technical writer.”Another student said, “Each time our group was hoping to be finished with our guides, there was another area to improve, correct, or modify.” It seems that while you were more interested in the reciprocal influences within the network that contribute to the creation of knowledge, your student’s takeaway here is mostly that he needed to triple-check his work. Did the network’s feedback loops prompt the student to constantly fix errors, and thus the student had to keep checking and iterating on his documentation? Or was the student’s takeaway unrelated to your larger investigations about networks?
GG: No, I think this is a key point. And I think this gets back to the notion that modern writing often changes after its initial delivery. I included these student comments because I thought they were indicative of the students realizing that the writing they did in my class was very different from their other school assignments.
Typically, even as technical communication professionals, there’s a certain writing process we teach. It goes something like: stage 1) research the writing situation, stage 2) draft a document, stage 3) peer review, stage 4) revise. And there’s nothing wrong with this writing process. It roughly resembles what all technical communicators do, to some extent. Its economical in that it fits within a learning module within an academic classroom.
But the issue is that when you’re writing in an actual industry context, the devil’s in the details. From my research, and also my work as a consultant, I know that some of those writing processes take months or even years and involve a small army of people. The docs are vetted by tons of SMEs and every time they get vetted there needs to be another peer review process, another revision, etc. until finally the document meets quality standards (or it’s just due to the client, whichever comes first).
So, projects like the Technical Writing Project give students a taste of what it’s really like out there. And it’s a lot tougher than their school writing would have them believe.
TJ: Is iFixit’s larger motivation (besides simply getting college students to write docs for free) to engage in the production of documentation in more of an interactive, feedback-oriented space? You wrote something that made me reconsider who’s really benefiting:
“Writers are ‘able to arrive at information’ as part of the Project because that information is produced via emergent, knowing-how formulas, formulas which encourage writerly engagement and participation in the networked production of knowledge.”
Is iFixit “arriving at” their needed information through the emergent network they’ve created with this wiki and the collaborative partnership with college programs? Surely the fresh eyes and minds that the students bring help contribute to a better information project, right?
GG: Another interesting question. And a question I’m going to answer a little sideways, because I think the context is important. iFixit is a very mission-driven company. I’ve interacted with enough people who work there, including Brittany McCrigler who is their Director of Education Services, to know that they’re true believers. When they say they’re trying to create the biggest, free repair wiki in the world, they mean it. They believe in the Right to Repair, which is the view that consumers should be able to repair their own devices, to keep them out of landfills, and to preserve them, even indefinitely.
So, the real reason that iFixit created the Technical Writing Project is that they want to invite more people into the repair community, plain and simple. Anyone who has ever worked with students should know that rarely do students create usable documentation on their first go-round. Technical writing is hard, and learning how to do it well is equally hard. This isn’t to say that the students I’ve mentored didn’t create usable docs. They absolutely did. But it took an entire semester and once the docs were reviewed by iFixit moderates they probably were revised additionally.
And the last time I spoke to Brittany, she had standing partnerships with something ridiculous like 70 universities! And for each one of the instructors, iFixit ships several devices to the instructor, for free. They ship free tool kits that the instructor can keep as long as they’re engaging in the project. And they provide dozens of hours of mentoring work for each instructor.
And in return they get some repair guides for devices that are not the most in-demand searches on their website. They’re not having students repair the new iPhone so that their technical writers don’t have to do it. That’s the core of their business model: iFixit tries to be the first reputable repair guide on the internet for every new device as it comes out. This sometimes involves Kyle flying halfway around the world to be one of the first human beings on the planet to get the new device so he can be the first to tear it apart. That’s what drives their page views, not a Nokia model from 10 years ago.
The Technical Writing Project is just what it’s billed at: an outreach project. Now, this is not to say that iFixit isn’t benefiting from the Project. They do get free repair guides and they do get to inform students they exist. But that goes with any industry partnership. It’s always a two-way street. If it wasn’t, why would the company agree to participate?
But the other part of your question is about knowledge, and that’s equally important here. And yes: iFixit is also committed to opening up repair knowledge. If they weren’t, they wouldn’t be going to all this trouble. They want people participating in the repair community. They want people to create their own guides. They know they can’t meet the needs of every user out there, so that’s why they invite them into their project of creating all these repair docs.
So, anyway: I’m not sure I answered your question here, but I think I answered an important one about the Technical Writing Project.
TJ: I’m curious to dive more into the Actor Network Theory from Latour. You wrote,
“To be considered an actor for Latour (2005), in fact, means being able to ‘translate, transform, distort, and modify’ other actors (p. 39). Further, actors come in all shapes and sizes (for example, both human and nonhuman). … Our goal was to understand how several different kinds of actors rhetorically impacted one another within the network surrounding the Technical Writing Project.”
My biggest takeaway from your article is that documentation can’t be written in a vacuum, and the more people involved in the review process (that is, the more feedback we can capture from users, and the more intelligence can extract from any systems related to the documentation), the better the knowledge becomes. Would you say that documentation is an iterative process, one that requires multiple layers of edits over a period of extended time from many different perspectives and actors? Or does that condition merely result in fragmented, piecemeal documentation that loses the coherence that an original and single author might provide?
GG: Oh, boy. cracks knuckles So, this is really getting into the meat and potatoes of Actor Network Theory and what it means for documentation, so I’m going to get on my soapbox about it for a minute. As I said earlier, a big part of Latour’s project is thinking about all the different ways actors can influence a specific network. And he has this massive classification scheme that he’s developed for all the different ways, including not at all. He’s even theorized what the opposite of an actor is. He calls these objects “monads,” which are objects that refuses to interact with a network even though they’re in the vicinity of it.
And at the heart of Actor Network Theory (or ANT), is that a lot of these influences aren’t readily apparent to humans. We take them for granted. We pick up a tool and use it without fully considering how that tool is influencing us. At the center of Latour’s project is a philosophical push to de-center human beings as the most important actors in any given network.
And this is where a lot of people get very angry with Latour and accuse him of all sorts of things like objectifying human beings and elevating tools to the level of humans, etc., etc. But what he is really trying to say is: we need to look at all the actors on the playing field. We need to think about how a given network is assembled before we can be useful to that network.
Another way of saying this is that no human being joins a network and is instantly useful to it, at least not typically. We have to learn. We have to understand how the network operates. When you start a new job, you don’t just walk in on day one and know exactly how to operate within this brand new network you just joined. You need a password for your work computer. You probably need to get added to the IT network. You may need some kind of security badge if you work in an industry that calls for them, etc. You have to interact with all these non-human objects and understand what actions they make available to you before you can really get to work. Then you need to learn how to make use of them based on what they can and can’t do in order to perform your work effectively.
And in regards to the solo author vs. multiple author question, I would say it depends on the writing situation. I have certainly worked on writing projects where having multiple authors was a hindrance to developing a coherent document. I have also worked on projects where my ability to interact with other authors was the whole reason for the project in the first place.
This article is a perfect example. I only sound as smart as I do in the article because of my co-authors. Nathan, for example, is a full-on philosopher. Whenever I have a philosophical question, he’s my go-to SME. And Sheryl is also involved with the Technical Writing Project, so learning about how she worked on the project, and comparing notes, was key to this writing project.
To risk over-generalizing: every network has its own configuration. And as actors within a specific network, we have to understand this configuration before we can be a useful member of the network, before we can start to create productive knowledge.
TJ: You mentioned some additional takeaways from students participating in the iFixit project. You wrote,
“After several assignments traditional to technical communication pedagogy (which asked students to craft materials for fictionalized cases), student participants were surprised by the degree to which the Technical Writing Project required a hands-on knowledge of their assigned devices (including how to disassemble and reassemble them), and how to correctly describe and photograph each step of a specific repair process.”
I was surprised by this. How did students think they were going to write a repair procedure without tinkering around with a device at a very hands-on, intimate level? Do you think documentation scenarios where tech writers don’t engage in deep tinkering can still produce valuable information? Or is an extended tinkering a prerequisite to generating knowledge? If so, does this place more value on the technical aspect of documentation rather than the theoretical?
GG: Part of the students’ response here is that they had never been in a writing class where they were handed a tool kit and a device and were told: “write about how to fix this.” This was so outside their educational experience that they couldn’t help but be shocked by it.
On the other hand, though: I think this reaction speaks to how foreign the repair process is to most of us consumers. I will even admit that when I started working with iFixit I felt like the biggest impostor ever because I had never really repaired anything before, especially not an electronic device.
An interesting side-story is that iFixit actually gifted me and my wife one of their premium repair kits for our wedding. And I probably have used that thing more than any other gift I’ve ever received. I’ve repaired my glasses with it. A laptop. A phone. It’s definitely changed the way I think about my devices and the objects around me.
Most consumers won’t ever encounter repair discourse, however. When a device stops working, they take it to a repair specialist or throw it away and buy another one. So, I think the students were coming from this place when they said things like that. They were encountering the repair network for the first time and trying to get acclimated. I think all networks are foreign to us when we first join them.
TJ: In your conclusion, you said, “If we have learned anything from this research project, it is that tinkering involves failure, frustration, and being willing to be wrong, but that this is a good thing. It’s important. Failure is learning.” Did students learn that they were wrong through their network, including the non-human components in the system, or are you moving away from Latour and actor-network theory here in the conclusion? Also, do some students have a knack for tinkering intuitively, or is tinkering something that can be learned?
GG: No, I think failure is a key part of learning. And learning is how we become useful actors within networks. Much of ANT involves sifting through layers within a given network to attempt to understand what’s going on in it. I think Latour would be a fan of the idea of tinkering, of trying different tools, technologies, and workflows to see which is best suited for a writing situation. And I’m definitely not the first Latourian to suggest this.
What I’m really trying to say here is that tinkering is an essential element of all learning, and ultimately all work. If we’re afraid to fail, then we will be stuck in the same rote activities, no matter how effective (or ineffective) they are. I fundamentally believe that if you want to innovate, you have to be willing to fail. Very few innovations occur because people were playing it safe.
TJ: Thanks for the interview. Would you like to tell us a bit more about the program where you’re currently teaching?
GG: Sure! My colleagues certainly wouldn’t like it if I didn’t take this opportunity to mention our program. I currently teach as part of the Technical and Professional Communication program at East Carolina University. We have an online certificate and Master’s where students can specialize in technical communication and also a Ph.D. in Rhetoric, Writing, and Professional Communication. At the undergraduate level, we currently have a certificate in Business and Technical Communication that students can use to supplement their majors from any disciplines.
We serve a wide variety of students with our programs. At the undergraduate level, we have a fair amount of business and communication students who supplement their coursework with one or more of our technical communication classes in order to be more marketable in their primary fields. At the Master’s level, our program is probably equally divided between English majors looking to do a more practical, hands-on degree as their entry into graduate study and career-changers who are looking to breaking into the tech comm industry. At the Ph.D. level we mostly attract students who want to be college professors with some expertise in tech comm, but we have had a few industry folks complete our program as well.
One thing I’ll say about all our programs is that our instructors are very highly rated by students. And the thing students say about us is that we’re very hands-on, very available, and very approachable. It can be scary approaching a college professor and asking for help, but we pride ourselves on being available to all our students to serve them anyway we can, but also to challenge their assumptions in order to help them become the type of professional they desire to be!
Thanks for the opportunity to talk about my research! Hope I clarified some things for you and your readership!
About Guiseppe Getto
Guiseppe Getto is an Assistant Professor of Technical and Professional Communication at East Carolina University and is President and Founder of Content Garden, Inc., a digital marketing and UX consulting firm: http://contentgarden.org. He consults with small businesses and non-profits from a variety of industries who want to develop better content, better SEO, better writing, better websites, better user experiences, and better reach for their target consumers. He has taught at the college level for over fifteen years. During that time, he has also consulted and formed research and service-learning partnerships with many non-profits and businesses, from technical writing firms to homeless shelters to startups. He is also a poet. His first book, Familiar History, is currently available from Finishing Line Press: http://guiseppegetto.com/poetry. Read more about him at http://guiseppegetto.com.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.