Towards a Taxonomy of Failure

Introductory note: I intended this talk, given at the "On the Benefits of Failure" workshop at the University of Alberta in March 2018 (video available here), to be my "swan song" for engaging with DH. It came about a year after the funding for my involvement with DH was eliminated at UC Berkeley, and I was working on reinventing myself in the world of research computing. Some of the issues with my organization were beginning to come to a head, but I couldn't have imagined while giving this talk that seven months later, I'd be in a new, DH-centric position in the Division of Literatures, Cultures, and Languages at Stanford University. See the Stanford DH blog for more reflections on the talk a year later.

Also worth noting: I was 7 months pregnant at the time with my youngest child, and was barely able to squeeze into my Windows Blue Screen of Death hoodie, which I sewed myself with fabric from Zenith & Quasar.

Addendum (2/12/19): Thanks to Thomas Padilla and Alex Gil for pointing out in Twitter threads starting here the fact that the potential for negative consequences for any kind of failure are relativized to identity -- and amplified through racism, sexism, classism, and similar structural barriers. Being able to talk about it openly without concern about damaging professional consequences is privilege, and while advocating for people in a position to talk about failure to do so, it's important to not pressure colleagues in a more vulnerable position to do the same.

 

Thank you so much for having me today. Why am I here? I think it probably dates back to the international digital humanities conference that was held in Nebraska in 2013. I stood up in front of the large room like this one and possibly for the first time in the history of the conference spoke very frankly about the failure of a multi-million-dollar cyberinfrastructure project for the humanities known as Project Bamboo.

People didn't know what to think about that because no one wants to talk about failure. When it happens, it happens quietly. Projects just go away, centers shut down quietly, but one of the privileges and advantages of working in central IT is that—compared to the academic side of the house – central IT is pretty comfortable with failure, for better or for worse. Central IT can fail to the tune of millions of dollars every year, and no one gets sacked. In that context, I felt like it wouldn't be an issue at all in my organization, or for my career, to go up and say, “Here's how we made some mistakes.”  This stands in contrast to the culture of academia.

Personally, I've done lots of failing. This was me in the Project Bamboo days failing to transcribe the hundreds and hundreds of flip charts from the workshops I went to. I literally got buried in them and we thought we'd have some fun with documenting that.

I'm pretty comfortable with failure because the path to learning runs through failure. It's not something that we think about a lot in the humanities, though in the digital humanities we're getting to a point where I think this is is becoming more obvious. In other disciplines it's much more evident that failure and learning are so closely tied.

Consider, for a moment, science labs – and I’ll admit I haven't spent a lot of time considering science labs until my most recent position, where I'm now working with grad students and undergrads from across the entire university: everyone from nuclear engineering, to chemistry and molecular biology, and digital humanities. I asked some of them about failure in preparation for this talk. “Failure -- does this happen a lot to you? Do you guys talk about it? Is this a big part of your life when you're working in a wet lab?” And one of the graduate student researchers I've worked right said, “Yes, we definitely fail. Probably half the time experiments fail – and that's what you know what you're doing. When you don't actually know the procedure, the rate is a lot higher. Failure is expensive and hard to sweep under the rug. Sometimes you prepare a specimen and for being sent off for a lot of testing, and a lab test can cost between $1,000 and $15,000 and you come back with complete garbage. Then you have to start over and send it off work for lab work again.” And I asked, “Do your PIs get angry with you?” And he said, “Yeah, I think they do.” PIs are people too, sometimes they have difficulties managing their emotions, but it’s more frustration than actual anger. They understand that this is part of the process, this is part of running a lab, this is part of discovery, and this is part of learning. This is how you push the boundary forward in science.

I've also had some tangential dealing in the world of medicine, and as much as you don’t like to think about it when you go into for medical procedure, the fact is that the person performing that procedure on you first had to learn by doing it on someone for the first time. That’s kind of a scary thought, but it has to happen. The stakes are much higher for mistakes but still there's a sense that the value that you get out of learning these procedures is worth the risk having to take tentative steps forwards into things that you don't really know.

Technical failure. I thought through how I got from where I started in DH to where I am today – arguably on the other side of DH – and looking at it through a set of different lenses of failure.  The first one I'd like to start with is technical failure, which has some parallels in the sciences. There are lots of opportunities for technical failure: learning to code, or learning how to use a content management system. Even learning what a content management system is, and how to choose between them, and which one is the best fit for your kind of project, and how to run one in the long term. There's lots of procedural things that have analogs in labs, and analogs in medicine in the sciences, that you don't necessarily see so obviously in other parts of the humanities.

A brief digression on Slavic linguistics. Back when I did academic things, these were the academic things that I did. It ties in really well with the theme of this talk because Slavic Linguistics – at least in the US—is an example of disciplinary failure. Which is to say, it basically doesn't exist anymore. Fifty years ago, in addition to having linguistics departments, which were theoretically oriented, there was also area studies linguistics: Slavic linguistics, Romance linguistics. There was a whole set of these disciplinary linguistics. They were different in the sense that the people who studied them knew the languages intimately, learned the history of the languages, the structure of the languages, how they tied into other languages in the family, and looked at issues within that language family from a deep perspective situated within the language, rather than just treating languages as data in the same way as theoretical linguistics. The problem was, as time went on, these disciplinary linguistics departments had a hard time articulating what challenges they were trying to solve. What were the big questions? Why, fundamentally, should anyone care? What is this going to tell us about much of anything? In part it was a marketing issue, in part it was a lack of engagement with people doing the same kind of work in Europe, or people dealing with similar questions in linguistics. But one way or another, these were fields that weren’t really able to make a case for why they should exist, and ended up becoming places where prospective grad students would apply to when we were unable to get into a theoretical linguistics PhD department, and that death spiral continues to this day. There's maybe a couple of places in the US left where you can even get a degree in Slavic linguistics, and those probably won't last another 15 years.

So, Slavic linguistics, my home discipline: I did a BA/MA in Slavic linguistics at the University of Chicago and my first taste of DH, my first taste of technical failure, was a medieval Slavic linguistics project. A faculty member, Daniela Hristova, had gotten a small seed grant from the university to build a database of medieval Slavic manuscripts. She found some online and she wanted to annotate them a little bit, clean them up (the OCR wasn't very good), and make them searchable. The department had gotten wind that I was someone who “knew computers”. It was my second year of undergrad, all of 19 years old, and I “knew computers” because I was embarrassed by my department's website, which had these little bouncing Russian nesting dolls all over it. And I said, “Please, Slavic department, you don’t even have to pay me, let me redo your website, this is embarrassing for all of us.” I had done that but this had tipped my hands that I “knew computers”, so when Daniela got this grant, she decided, “Quinn's in charge of making this thing work. We’ll take Quinn, and Quinn can talk to tech people, and she’ll do that part. And this other undergrad, Andy, he can even do all the cleanup of the documents, since he's really good with old Russian.” (The other guy is now my husband, as it happens.)

This DH project had pretty bad planning. “Let’s just pass it off to the undergrad.” As much credit as I give myself, maybe not the world's best idea. Underestimating the work required: that's another common thing when you're working on your first project. You just have no idea how long these things take. There were some major mistakes in technology choice starting with the fact that we had these manuscripts available in HTML that was reasonably well marked-up. We had encoding for things like when lines started, when pages started, etc. But the faculty member thought, “You know, these texts need to be cleaned up. Where do you clean things up? In Microsoft Word, of course! That's where you clean everything up!” She copied and pasted all of the wonderfully encoded HTML, pasted it in the Word and handed it to Andy to do all the cleanup. After he finished the cleanup, the next thing was to encode the text in TEI. Maybe we could’ve crosswalked it from the original HTML, but instead we were starting from scratch because it was coming from Word. We ended up talking to the folks who run Philologic at the University of Chicago, and they came up with an amazing system of using some of the colors in in the documents to reintroduce some of the encoding. And to this day, if you say “light seafoam green” around Mark Olson from Philologic, he’ll start to twitch slightly in remembering some of the machinations they had to come up with to fix some of the really bad technology choices. Technical failure. But we learned a lot.

Technical failure, while most obvious in DH (in the sense of using the wrong technologies, planning your projects badly, etc.) is not unique to DH. If you think about the humanities in general, and some of the things that you've learned as a grad student, there are certain processes and procedures and ways of doing things where you have no idea of how to do them coming in. In a lot of cases, no one teaches you, and you only can really learn through failure. You don’t have to raise your hands but I'm guessing from some of the nods in the room that some of you might have had a conference talk with no questions—or even worse, the pity question. That's always really awkward. Or lesson plans, or even whole courses that don't work out the way you thought. That's another kind of technical failure. Rejected grant proposals. While grants are seen in many ways the lifeblood of DH in particular, there’s travel grants, and everyone writes grants these days to a greater or lesser extent. Having those rejected – sometimes without even a clear explanation to help you improve for the next one – it’s frustrating. It's a common kind of technical failure I think everyone experiences.

Career planning failure. This this is one that I discovered when both I and my future husband started the PhD program in Slavic linguistics after finishing up our BA/MA. We stayed in Chicago just there were not many other universities that even offered a Slavic linguistics program. When you're a grad student, inertia is the enemy when it comes to thinking through what your career is. Once you're on the grad student track, the easiest thing to do is to keep showing up and keep following the instructions about the next thing. You have classes, a qual paper, propose a topic and you work on the dissertation. There's a lot of disincentives to stop and think about what this means for your bigger career. Is this really the path to get where you want? It's a very uncomfortable question because you know stepping away from the grad school path means stepping away from a community, a lifestyle, a set of easy choices that can get you through the next 5+ just by following them step by step. Then, the question is, “If this isn't really where you want to go, who’s around to help you find a different path?” And when you're in grad school, you have your advisor who you can talk to, who is probably quite good and quite savvy about how to find an academic job in your field. But how much do they know about other options for you? In many cases, by definition, the fact that they are faculty and have probably been faculty for some time, means they may not actually have much of a clue about what the options are or how one would get there. It takes a little bit more work to find other people to talk to.

I was not happy with the reality of being in grad school. I started in the fall, right after I had graduated and I realized as I was facing prepping for my PhD exams that I was going to have five years of first prepping for these exams, and then finding a topic, and then writing on the topic. But I didn’t care about any one topic that much. I couldn't even imagine caring about any one topic that much. I realized that what I was interested was the question of how people do research rather than actually wanting to do research myself. A month or so after starting the PhD program – give me this much, I was decisive – I decided I was going to leave.

For a little while I worked in the computer lab where I had had a student job that had continued. I talked to Mark Olson of Philologic about what other tracks there were that would get me closer to thinking through these questions about how to support research. Where he pointed me was a Masters of Library and Information Science program at the University of Illinois. So I ended up doing that while I also found myself a job working in the central academic IT unit at the University of Chicago. The big-big-boss of the computer lab had noticed me – I showed up for meetings, was enthusiastic, got stuff done. It was 2007, and he said, in essence, “I like the cut of your jib, I’ll just make a position for you and hire you into it.” UChicago is a private school, it was 2007, we had money. Sometimes I feel like I got the last boat off the Titanic in terms of that even being possible before all of the budget cuts that followed. I don’t suggest trying the same path today, suffice it to say. But back then, it worked and that's what I did.

Working in a central academic IT unit, while simultaneously working on a master's degree in Library and Information Science, it really gave me a new vantage point on failure. Whereas before I was on the academic side, trying to build a project, and failing at doing so at times, I suddenly saw how a lot of the failure and some of the dysfunction of these projects was really due to communication failure. Being on the IT side, we would have people come to us with questions and we would try to respond as best we could. One of the advantages of coming from the academic side the house, myself, is I was in a better position to try to translate some things that people were saying to us into what they actually wanted, rather than taking the words that came out of their mouths literally. Sometimes there were people who came to my group for help after things had gone terribly, terribly awry with some other IT group. For instance, a few things that I got to hear a lot: “I need a database.” Lots of people build databases. It's a common type of project. But if you show up to an IT office and say, “I need a database,” you might not be happy with what you get.

There was a project that initially went to a different IT group. They’d told this group, “I need a database,” and the group says, “Great, we'll set you up with FileMaker Pro. That’s a database, all right, I'll take your word for it.” The faculty spent a year populating the FileMaker Pro database – they filled in everything they wanted – and they thought their project was almost done. They were really excited and went back to their IT group and said, “We filled in the database—now  how do we get this online?” And the IT people looked at them and said, “Whoa, whoa, you didn't say anything about online. What’s this ‘online’? You said you needed a database, we got you a database… we’re done. We’re good. ‘Online’, that’s a different thing altogether.” And so they came to us and we tried to help them.

Around the same time my boss in the central IT unit was talking to various funders and through his own experiences of working with these kinds of projects, he noted that there it was, to his mind, the “canonical bad digital humanities project”. I think, particularly from the perspective of failure and learning, that’s really taking a very limited view of what digital humanities projects do. It assumes that given the value of digital humanities projects should be taken at face value. If you say you're going to build a tool, you should be building a tool in an efficient, scalable, and sustainable way that many people can use so that funders don’t have to pay for that tool again. If you're building a project that's a collection of things, you should be using standards and best practices and make sure the data is stored in a way that the librarians approve of, and it can be sustained for the next 20-30+ years. In reality I think the value of a lot of digital humanities projects – including fairly large ones that get funded by major funding agencies – is to provide the people who work on those projects an opportunity to try something, and build something, and learn and learn through a failure. To learn through things not working out, and being able to have the time to have those hands-on experiences that are really important for taking the next step with your work.

It was a very IT-centric proposal: there's this problem with the “canonical bad digital humanities project” – just look at those plastic blocks, those will be knocked over in two seconds, and what's more, the scholar is calling them a “salad” rather than a “tower” so who knows what they're even thinking in terms of the architecture? I asked my kid what that was, and he told me it was a “salad”, so there are analogs here, where IT people are looking at digital humanities projects and think, “What on earth are you doing?! Why would you architect it that way?! Why would you choose these tools?! This is this is no way to run a field, this is not an efficient use of financial resources, we can fix this!”

So, cyberinfrastructure to the rescue! We were going to build something that would put an end to the bad digital humanities projects. The Mellon Foundation would rest easy knowing that their resources were being used wisely and scalably, for tools that multiple people could use in the future. We had this grand fantasy of this concept of the Borromean rings: three rings that are  interlocking and can't be separated from each other. We had a great story of the Borromean rings, depicting community and technology, and we were all very excited about this project idea, for Project Bamboo.

I think Project Bamboo was a case of strategic failure. While the overall project strategy of doing Bamboo sounded like a good idea, but when we talked to people, we've heard loud and clear that wasn't what they needed, that wasn't what they were looking for. Maybe that would’ve been useful information to the extent that they understood what we were actually talking about, but it really wasn't where the field was, and what it needed at that time.

Going through that experience, the learning value was quite high, and the risks of talking about it, as I discovered, were lower than I expected. People like to hear what train of thought led to a road that wasn't very productive. In the end it seemed like people appreciated the frank postmortem of the project more than they penalized us on subsequent grants for having failed.

Project Bamboo had it all figured out. We were going to help scholars find existing tools and content. We would track the use of tools and content, and build a platform for interoperable shared services. If you develop piece of code for analyzing one kind of literature, you could run it on a high-availability system, it could be disseminated scholars across the globe, and thousands of scholars could be using your code all at the same time on this stable platform in order to analyze literature. I don't think we really realized the fact that there weren't that many people who this would apply to. If everyone in digital humanities decided to run code at the same time, maybe we might be pushing the limits of expected scalability but really weren't that many people back in 2008, and especially not all working on literally the exact same algorithm at the same time. But Bamboo had a community design process, and they expected that would validate all of our assumptions, and then we ultimately put together a proposal that appeared to be a straight continuation of Bamboo’s original vision.

We worked really hard. All of us worked extra hours, we ended up traveling, we ended up staying late, and we built these amazingly elaborate diagrams of service architectures, of wedding cakes and cabbages. I, being a snarky new entrant into the “being-paid-to-do-a-grown-up-job” field enjoyed sitting in meetings and making sarcastic logos like “Project Bamboo Survivor”. But there was there was something to it, and we all were onboard with the idea that we could make this work it somehow, and conveys to scholars the value of this proposal. Once they understood, they would agree with us.

In reality, though, there were a lot of different views of what Bamboo actually was and what it was supposed to do. There was the vision of Directors had. Some of the scholars who were going to the workshops saw it as a solution for tenure, for respect, for copyright, for social justice, even for funding issues that – as it was 2008+, were beginning to plague the field. In reality, everyone had a different view of what it was and what it was supposed to be.

The project generated clumps of participants: the IT people who wanted this technical infrastructure, the library folks who were more interested in collections interoperability—being able to pull in content from different places, and the scholars who wanted a community. Scholars wanted to be able to share information about who was doing what, and they wanted a scholarly narrative they could take back to their dean to justify funding for a digital humanities project.  Everyone saw the elephant (or the unicorn) as something different.

I’ll admit that between 2013 when I gave that talk on the failure of Bamboo and today, I'm starting to view the project a little bit more charitably. There’s been some developments in the last couple years in terms of shared algorithms that the HathiTrust Research Center is making available, in terms of some of the metadata aggregation that the SHARE project is doing, that really have echoes of some of the things that we were talking about doing with Bamboo, but in a more focused and smaller-scale kind of way. In the end I wonder if Bamboo was less of a strategic failure and more of a timing failure—but at a certain point the difference doesn't really matter. The point is it didn't work out in 2009-2012.

One of my favorite quotes about Project Bamboo (that, sadly, was excised from the article that I wrote because LLC will not stand for scatological humor, however oblique) is Bamboo as fertilizer. This came from Brett Bobley from the National Endowment for the Humanities. He came to some of our workshops, and the way he saw Bamboo was as an opportunity to bring people together from even within the same institution, who hadn’t met each other. There were groups of scholars, librarians, and some IT people from the same institution who had never even talked to each other before, and now they were stuck in a room together with these IT people who were jabbering on about wedding cakes and cabbages and stuff, and no one really knew what we were talking about. So instead, it gave them a chance to talk to each other and spin up new ideas and thoughts and collaborations that bore fruit later on.

For myself, I was probably one of the most scholarly-oriented people on the entire project team, having come right from a PhD program, and I was frustrated at the way that Bamboo went. The fact that it ultimately didn't get funding for anything other technical infrastructure, which alienated a lot of the people who saw value in some of the more scholar-facing pieces. So I thought to myself, “Well, if Project Bamboo can't do it, then I bet I could do this. Why don't I just do it?” And so with the hubris that comes from being young and having a lot of time on your hands, I started working on Bamboo DiRT which was a reinvigoration of a tool directory that Lisa Spiro had created some years before, and along with Ryan Cordell started DHCommons, which was going to be a project and collaboration directory. I'll get back to those in a moment, and where those ended up failing.

In the middle of this comes a flavor of failure that I think is best to characterize as “arbitrary failure” – which is to say, job market failure. Things started to go south in IT at UChicago, and my husband was finishing up his PhD when a new job came open at UC Berkeley. As it happens, it was probably one of the very last jobs ever to come open in the field of Slavic linguistics. On one hand it's a terrible thing to be in English and have 40 jobs to apply to in a given year where you might hear back from three of them. I don't know if it's better or worse to have one job come open every five years, and that's it. Needless to say, he applied for the job, he was a finalist for the job, people felt pretty good about him getting the job… and then an older Russian professor who had never thrown his weight around politically before put his foot down. Something that my husband said in his job talk was unacceptable, and over his dead body would my husband be hired. So he wasn't hired. That was that. That’s arbitrary failure. How can you plan for that? What can you even learn from that? What’s even repeatable from that? I feel like with the job market there's a lot of randomness in the system that's really hard to prepare for and really hard to learn from. I had another friend who was a finalist for a literature job in a small Midwestern agricultural engineering-oriented school. Everything was good, she had great job interview, and they asked her to send one more chapter from her dissertation to serve as a final checkpoint – and she didn’t get the job. And then the next year, or a few years later, she got a literature position in the Ivy League, with the same dissertation materials.

So what do you make of any of that? What is that but arbitrary failure? The unfortunate thing is, of the kinds of failure, it’s the one that we learn the least from, but there's a whole genre of this now in the blogosphere. “Quit lit”: how I left academia, how the job market did me wrong. We have lots of people talking about it, which I guess is a good step forward for failure insofar as anyone's talking about any kind of failure. It has some value in terms of solidarity when you're in that position of not getting a job for reasons that you don't even know, or don't even make sense, or just seem to fall from the sky. But one hopes to cultivate a genre of talking about failure that we can learn a little bit more from, where it's more representative, and indicates more personal learning and more learning for other people.

As it happens, we still managed to make it to California. Project Bamboo had made some detours here and there but it was closing in on its grant proposal for its second phase, and the folks that I had worked with on the UC Berkeley side decided they would hire me to help finish off the grant proposal and implement the second phase. So we moved from Chicago to California, and over the next couple years I was involved in a bunch of different activities starting with the death of Bamboo. Bamboo died maybe four months after I arrived in California, which is really awkward because that was ostensibly the reason why I was hired. But they didn’t fund our second phase proposal. I think that was merciful for everyone in retrospect, but it was it was hard at the time. They did say that they were willing to fund a grant proposal for DiRT, so that occupied my time for a while, building up the new DiRT, implementing that grant proposal, but I also increasingly transitioning to building a digital humanities program at Berkeley. While we had spent a lot of time investing in cyberinfrastructure, no one had a good sense of who was even doing DH on campus. Was anyone doing DH? There had been no effort to catalyze community-building. So Berkeley turned its attention from these multi-disciplinary cyberinfrastructure initiatives into cultivating a local community.

Failure to probe assumptions. I feel like this is at the core of what went wrong with DHCommons and DiRT which were both still going on during this time. Here are some assumptions behind DiRT: that crowdsourcing is effective, low cost, and sustainable. It was an article of faith for a while, that this was the way to do it. Look at Wikipedia! That was great! Crowdsourcing was the way to go. Having a parent organization is crucial for sustainability. We thought one of the problems with DiRT in its current form where it was to Berkeley was, what if we have budget cuts? What’s going to happen to this thing that wasn’t related to resources that Berkeley supported? So we thought we needed to find a parent organization. Making it easier for people to contribute it will lead to an uptick in contributions. In principle, that seems like a reasonable assumption; in practice, not so much. Documenting contributions to give people “credit” will incentivize contributions. That didn't really work. “Bells and whistles” are important for directory to stay relevant… we built them, but people didn't really come to sustain the directory, which is the core thing. You need to keep adding new tools to a tool directory, and get rid of spam and add reviews, and do these things in order to keep a directory alive, beyond just keeping the server on. That piece never really worked out. We also thought an editorial board would be a reliable source of contributions, but it turns out that a group of overwhelmed, busy people is no more effective than a single overwhelmed, busy person.

DHCommons was the project-collaborator matching directory that Ryan Cordell and I started, and later we added an overlay journal, which would become the journal of centerNet, one of the DH organizations. For the directory side, we thought, if people only knew about project collaboration opportunities, they’d take the initiative and follow up on those opportunities. People had profiles where they said what they were interested in working on, and projects could list what sort of help they needed, and we thought people would match themselves with projects. People mostly did not match themselves with projects. We thought people would contribute to and update the directory of projects, given the benefit it would provide doing things like environmental scans. That also didn't happen.

With the journal, we thought people with mid-stage projects would need a publication to justify all the work they had put into the project so far. It seemed like a better idea that it turned out to be. The biggest failure was our assumption that people can easily adapt to new forms of scholarly writing and peer review. But we discovered that it's hard enough to write a regular journal article, and it's hard enough to write a grant proposal already. When people are asking you to write something that's a hybrid between an article and a grant proposal, with elements of self-reflection on your process and your interventions, that was too much – let alone asking people to review it, to say nothing of asking people to write reviews that would then be published publicly along with the work itself. Innovating new genres of writing was less of a good idea than it seemed.

Through all of these failures, I think my own biggest failure was failure to acknowledge change. I started DHCommons and DiRT when I lived in Chicago and had no kids, and that meant I liked to be inside where it was air conditioned or heated for most of the year. I had my evening stretching out into infinity beyond me. I had nothing but time to fiddle with code and even do tool updates myself. But then I had two kids, and discovered that I enjoy sewing, and furthermore, it’s okay to have a hobby that's not an academic work-hobby. You can do something just because it's fun. That's a lesson that it took me moving to California to learn. For a long time, I failed to acknowledge that the circumstances that I faced were really different than the circumstances in which I started these projects. The time ultimately came to make a few changes. I had to let go and the emails that I had to write saying “I am stepping down from DHCommons, I can't do this anymore,” and “I need to move on from DiRT, I can't do this anymore,” were some of hardest emails I have ever written. Luckily, at least for DiRT I've been talking to Geoffrey Rockwell about the possibility of salvaging some pieces of DiRT and adding them to TAPoR. Despite having a very difference sustainability model than DiRT, it’s one of the longest-running directories around. With DHCommons, I don't really know where things stand. I don't know where things are going, but I also need to stop worrying about it, because I needed to move on.

Other recent failures include failure to forge a shared vision. I've been working with a digital humanities program funded by the Dean of Arts and Humanities, and they had a certain view of how that program should be run, how the consulting should be run, and we didn't necessarily see eye-to-eye. I thought we were more on the same page then we ended up being, but push came to shove and funding was cut, and they decided not to continue to fund my involvement in DH anymore. Because I worked for a central research IT group, that meant that I needed to shift my focus to other things that the group already ran: high-performance computing, research computing, cloud computing, and research data management, but not DH. That was the end of my involvement with DH as a formal part of my job, just last summer.

But new jobs bring new opportunities for failures! I have been learning all sorts of things over the last year, and honestly, it's pretty exciting. I realized I've been doing this sort of standard DH support role in one form or another for about 10 years and so moving into supporting high performance computing and research computing is really exciting and different. I ask stupid questions all day long. I sort of manage a group of grad students and undergrads, and frankly, even the undergrads probably understand this stuff better than I do. My job is to get obstacles out of their way, to help them reach consensus and make decisions on things while trying to broker different interests. I have learned slews of new acronyms. Now I can say things like, “Gee, it seems like we're having an issue with SLURM this morning,” and only slightly chuckle in the back of my head. Am I really saying this? If things get bad, I can always fall back on saying, “Sorry, just a medieval Slavist here, sorry for these stupid questions, thank you for your consideration.”  But it's been exciting.

The last kind of failure that comes to mind is the one that keeps me up at night, especially in my current role. It’s failure to do right by others. This has come to the fore in the last year fairly dramatically with some of these sexual harassment allegations against Franco Moretti, and others in the digital humanities community, but it's not always that dramatic. There are other practices that are not necessarily doing right by others, such as not necessarily providing equal compensation for equal work. There are lots of situations in grad school I’ve seen, here and there, grad students being asked to provide unpaid domestic labor for their advisors. That one’s clearly dubious, but there are other situations that are even more subtle. I'm really glad to be an IT person who works in IT organization and the structures are in place and everyone’s incentives are aligned to do right by people administratively. I get performance reviews because my boss doesn't get his raise unless he gives all of his staff performance reviews. I also know that there are lots of IT people out there who are managed by faculty who have never looked into what it is that IT people need to get raises or correct compensation for their work, and don’t seem particularly interested in spending the necessary time to figure out how to help your people towards the next step in their career – whether or not theirs is a path that you yourself even understand. Things like that. Or a manager who is really into projects and wants to play a hands-on role, and tramples on other people’s getting to learn and engage with these materials because they're just so excited about it. That's not really doing right, either.

As a woman in IT*, I've had far fewer ridiculous experiences than most. I'm not entirely sure why that is, but still, there was the time I had a manager who got in my face asked why I wasn't hanging out socially with the only other woman that I worked with. Because sharing the same gonads was definitely enough reason for like him to be friends with all the guys? I think he meant well, and people also probably to are trying to mean well when, for instance, just in the last week, two people of the managerial class have come to me and said, “Whoa, you're really pregnant.” It’s like, what, you think I hadn’t noticed? Again, they didn’t mean anything by it, but I try to think a lot about these kinds of things. What you do, and what you say, and how you work with people – especially people who don't really understand the systems that you understand, or what opportunities are available to them. I want to ensure that they can get those opportunities, and give them chances to fail, and chances to try things, and give them feedback and move obstacles out of their way. Those are the things that I think about a lot, and I try really hard not to fail. I think that this is a one kind of failure that maybe is an exception to the rule. You don't need personal experience failing in this way to learn lessons abut how to do better. But it’s hard – I think everyone fails to live up to their own expectations for themselves from time to time.

So here's my taxonomy of failure, roughly construed after fourteen years of failing one way or another along my path of doing digital humanities. You can argue with many pieces of it, but I think these are some lenses to consider in your own work as you move forward. And I think it’s worth talking about them. There really aren't a lot of established examples of people doing this. But in a lot of cases, sharing the failure that you've had, sharing how you got there, and how you recovered from it – even if that recovery looks like stopping altogether and trying something else – it’s valuable for you as a form of self-reflection, and for the whole community. May you learn from your failure and grant others the same.

* Note: I've always hated using that phrase, but it felt unavoidable in this and similar circumstances. Since this talk, I've started identifying as non-binary -- which has been made easier by not being in IT.