Test everything; retain what is good.
1 Thessalonians, Chapter 5
Test everything; retain what is good.
1 Thessalonians, Chapter 5
I firmly believe the case for the humanities is best made on its own terms. Rather than bending pretzel-like to explain how the humanities contribute to the prevailing values of techo-industrial capitalism, we should argue first and foremost for the humanities as good in their own right. We should be strong in our conviction that the social and moral goods produced by the humanities are of equal value to the economic goods produced by science, technology, and business. That said, it is sometimes pragmatic to show that even when measured by the standards of science, technology, and business, the humanities are extremely valuable. When arguing our case to decision makers who are themselves members of the STEM fields (e.g. your Dean or Provost) or who have become convinced of the central importance of STEM in the 21st century economy (e.g. legislators or members of your board of visitors), it is often more persuasive to do so on their preferred turf.
One way to do this is to argue from primary data that show the direct economic benefits of arts and humanities in our communities. The American Academy’s Humanities Indicators project is a good place to look for this kind of evidence. Another way is to refer decision makers to the frequent statements of prominent members of the tech community who have spoken out in support of the humanities education and humanities skills as useful in the tech economy. Good examples of this kind of secondary evidence are Mark Cuban’s recent statements warning students off finance and computing in favor of liberal arts; David Kalt’s assertion that “individuals with liberal arts degrees are by far the sharpest, best-performing software developers and technology leaders”; and the example of Slack co-founder Stewart Butterfield’s crediting of his philosophy degree for his success. I’m sure you’ve seen more examples of this type, which I’d love to collect in the comments section below.
Quoting STEM and business types back to themselves is sometimes the most effective way to argue our worth. It’s one thing to say your work is important, it’s another to show that the people your audience respects most say your work is important. It may not be the case we want to make, but sometimes it’s the case we have to make.
With the semester having just ended, many of us are settling into new summertime routines and hoping those routines supports both some research productivity and some measure of relaxation. For me, in addition to the transition from semester to summer, I’m also transitioning into a more active period for our Greenhouse Studios initiative: our first projects are entering their intensive build sprints, we’re hiring our first full-time staff, and we’re preparing to move into a new, custom-built space on the first floor of the library.
Times of transition are times when we establish new habits—good ones or bad ones—and I’m trying to keep this passage from Kim Stanley Robinson’s 2312 in mind as I transition to summer and Greenhouse Studios embarks on a new phase in its development:
Habits begin to form at the very first repetition. After that there is a tropism toward repetition, for the patterns involved are defenses, bulwarks against time and despair. Wahram was very aware of this, having lived the process many times; so he paid attention to what he did when he traveled, on the lookout for those first repetitions that would create the pattern of that particular moment in his life. So often the first time one did things they were contingent, accidental, and not necessarily good things on which to base a set of habits. There was some searching to be done, in other words, some testing of different possibilities. That was the interregnum, in fact, the naked moment before the next exfoliation of habits, the time when one wandered doing things randomly. The time without skin, the raw data, the being-in-the-world. They came a bit too often for his taste. Most of the terraria offering passenger transport around the solar system were extremely fast, but even so, trips often took weeks. This was simply too much time to be banging around aimlessly; doing that one could easily slide into a funk or some other kind of mental hibernation. In the settlements around Saturn this sort of thing had sometimes been developed into entire sciences and art forms. But any such hebephrenia was dangerous for Wahram, as he had found out long before by painful experience. Too often in his past, meaninglessness had gnawed at the edges of things. He needed order, and a project; he needed habits. In the nakedness of the moments of exfoliation, the intensity of experience had in it a touch of terror— terror that no new eaning would blossom to replace the old ones now lost. Of course there was no such thing as a true repetition of anything; ever since the pre-Socratics that had been clear, Heraclitus and his un-twice-steppable river and so on. So habits were not truly iterative, but pseudoiterative. The pattern of the day might be the same, in other words, but the individual events fulfilling the pattern were always a little bit different. Thus there was both pattern and surprise, and this was Wahram’s desired state: to live in a pseudoiterative. But then also to live in a good pseudoiterative, an interesting one, the pattern constructed as a little work of art. No matter the brevity of a trip, the dullness of the terrarium or the people in it, it was important to invent a pattern and a project and pursue it with all his will and imagination. It came to this: shipboard life was still life. All days had to be seized.
Looking down the page, it seems I haven’t posted here on the ol’ blog in nearly three years. Not coincidentally, that’s about when I started work on the initiative I’m pleased to announce today. It was in the fall of 2014 that I first engaged in conversations with my UConn colleagues (especially Clarissa Ceglio, Greg Colati, and Sara Sikes, but lots of other brilliant folks as well) and program officers at the Andrew W. Mellon Foundation about the notion of a “scholarly communications design studio” that would bring humanist scholars into full, equal, and meaningful collaboration with artists, technologists, and librarians. Drawing on past experiences at RRCHNM, especially One Week | One Tool, this new style digital humanities center would put collaboration at the center of its work by moving collaboration upstream in the research and publication workflow. It would bring designers, developers, archivists, editors, students, and others together with humanist faculty members and at the very outset of a project, not simply to implement a work but to imagine it. In doing so, it would challenge and level persistent hierarchies in academic labor, challenge notions of authorship, decenter the faculty member as the source of intellectual work, and bring a divergence of thought and action to the design of scholarly communication.
A planning grant from Mellon in 2015 allowed us to explore these ideas in greater depth. We explored models of collaboration and project design in fields as disparate as industrial design, engineering, theater, and (of course) libraries and digital humanities. We solicited “mental models” of good project design from diverse categories of academic labor including students, faculty members, archivists, artists, designers, developers, and editors. We visited colleagues around the country both inside and outside the university to learn what made for successful and not-so-successful collaboration.
The result of this work was a second proposal to Mellon and, ultimately, the launch this week of Greenhouse Studios | Scholarly Communications Design at the University of Connecticut. Starting this year with our first cohort of projects, we will be pioneering a new, inquiry-driven, collaboration-first model of scholarly production that puts team members and questions at the center of research and publication rather than the interests of a particular faculty member or other individual. Teams will be brought together to develop answers to prompts generated and issued internally by Greenhouse Studios. Through a facilitated design process, whole teams will decide the audience, content, and form of Greenhouse Studios projects, not based on any external expectations or demands, but according to their available skills and resources, bounded by the constraints they identify, and in keeping with team member interests and career goals.
Stay tuned to see what these teams produce. In the meantime, after three long years of getting up and running, I plan to be posting more frequently in this space, from my new academic home base, Greenhouse Studios.
Last week I had the pleasure of serving as facilitator at the first Mellon-funded Triangle Scholarly Communication Institute (SCI) in Chapel Hill. For the better part of the week five diverse teams of scholars, librarians, developers, and publishers came together to advance work on projects addressing challenges ranging from data visualization and virtual worlds to providing computational research access to large newspaper collections to building curriculum resources for understanding Sikh religion and culture. It was a great week.
At the end of the event, the teams were each asked to deliver an “elevator pitch” for their project. Quite what this pitch should entail remained something of an open question going into the final day of the Institute, so the project organizers, me included, came up with the following structure, which we shared with the teams the evening before their presentations, on the spot:
It occurs to me that this is a formulation that I have used in many elevator pitches, planning documents, grant proposals, etc. over the years and that it may be useful to others. When you’re trying to convince people to do something, buy something, or support something, these are generally the things they will want to know — What am I buying? Why should I want it? How will you deliver it? Most RFPs, grant guidelines, and the like are variations on this theme. So, when you’re at the early stages of planning a new project, where ever it may end up, this structure may be a useful starting point.
Revised notes for remarks I delivered on the topic of “Tools: Encouraging Innovation” at the Institute of Museum and Library Services (IMLS) National Digital Platform summit last month at the New York Public Library.
What do we mean when we talk about innovation? To me innovation implies not just the “new” but the “useful.” And not just the “useful” but the “implemented” and the “used.” Used, that is, by others.
If a tool stays in house, in just the one place where it was developed, it may be new and it may be interesting—let’s say “inventive”—but it is not “innovative.” Other terms we use in this context—”ground breaking” and “cutting edge,” for example—share this meaning. Ground is broken for others to build upon. The cutting edge preceeds the rest of the blade.
The IMLS program that has been charged and most generously endowed with encouraging innovation in the digital realm is the National Leadership Grants: Advancing Digital Resources program. The idea that innovation is tied to use is implicit in the title of the program: the word “leadership” implies a “following.” It implies that the digital resources that the program advances will be examples to the field to be followed widely, that the people who receive the grants will become leaders and gain followers, that the projects supported by the program will be implemented and used.
This is going to be difficult to say in present company, because I am a huge admirer of the NLG program and its staff of program officers. I am also an extremely grateful recipeint of its funds. Nevertheless, in my estimation as an observer of the program, a panelist, and an adwardee, the program has too often fallen short in this regard: it has supported a multitude of new and incredibly inventive work, but that work has too rarely been taken up by colleagues outside of the originating institution. The projects the NLG program has spawned have been creative, exciting, and new, but they have too rarely been truly innovative. This is to say that the ratio of “leaders” to “followers” is out of whack. A model that’s not taken up by others is no model at all.
I would suggest two related remedies for the Leadership Grants’ lack of followers:
These are anecdotal impressions, but it is my belief that the NLG program could be usefully reformed by a more laser-like focus on these and other uptake and go-to-market strategies in the guidelines and evaluation criteria for proposals. In recent years, a higher and higher premium has been placed on sustainability in the guidelines. I believe the effort we require applicants to spend crafting sustainability plans and grantees to spend implementing them would be better spent on outreach—on sales. The greatest guarantor of sustainiability is use. When things are used they are sustained. When things become so widely implemented that the field can’t do without them, they are sustained. Like the banks, tools and platforms that become too big to fail are sustained. Sustainability is very simply a fuction of use, and we should recognize this in allocating scare energies and resources.
About six months ago, I was asked by the executive director of a prestigious but somewhat hidebound—I guess “venerable” would be the word—cultural heritage institution to join the next meeting of the board and provide an assessment of the organization’s digital programs. I was told not to pull any punches. This is what I said.
I’m happy to say that, aside from a few chilly looks (mainly from the staff members, rather than the board members, in the room), my no-holds-barred advice was graciously received. Time will tell if it was well received.
On December 21, 2012, Blake Ross—the boy genius behind Firefox and currently Facebook’s Director of Product—posted this to his Facebook page:
Some friends and I built this new iPhone app over the last 12 days. Check it out and let us know what you think!
The new iPhone app was Facebook Poke. One of the friends was Mark Zuckerberg, Facebook’s founder and CEO. The story behind the app’s speedy development and Zuckerberg’s personal involvement holds lessons for the practice of digital humanities in colleges and universities.
Late last year, Facebook apparently entered negotiations with the developers of Snapchat, an app that lets users share pictures and messages that “self-destruct” shortly after opening. Feeding on user worries about Facebook’s privacy policies and use and retention of personal data, in little more than a matter of weeks, Snapchat had taken off among young people. By offering something Facebook didn’t—confidence that your sexts wouldn’t resurface in your job search—Snapchat exploded.
It is often said that Facebook doesn’t understand privacy. I disagree. Facebook understands privacy all too well, and it is willing to manipulate its users’ privacy tolerances for maximum gain. Facebook knows that every privacy setting is its own niche market, and if its privacy settings are complicated, it’s because the tolerances of its users are so varied. Facebook recognized that Snapchat had filled an unmet need in the privacy marketplace, and tried first to buy it. When that failed, it moved to fill the niche itself.
Crucially for our story, Facebook’s negotiations with Snapchat seem to have broken down just weeks before a scheduled holiday moratorium for submissions to Apple’s iTunes App Store. If Facebook wanted to compete over the holiday break (prime time for hooking up, on social media and otherwise) in the niche opened up by Snapchat, it had to move quickly. If Facebook couldn’t buy Snapchat, it had to build it. Less than two weeks later, Facebook Poke hit the iTunes App Store.
Facebook Poke quickly rose to the top of the app rankings, but has since fallen off dramatically in popularity. Snapchat remains among iTunes’ top 25 free apps. Snapchat continues adding users and has recently closed a substantial round of venture capital funding. To me Snapchat’s success in the face of such firepower suggests that Facebook’s users are becoming savvier players in the privacy marketplace. Surely there are lessons in this for those of us involved in digital asset management.
Yet there is another lesson digital humanists and digital librarians should draw from the Poke story. It is a lesson that depends very little on the ultimate outcome of the Poke/Snapchat horse race. It is a lesson about digital labor.
Mark Zuckerberg is CEO of one of the largest and most successful companies in the world. It would not be illegitimate if he decided to spend his time delivering keynote speeches to shareholders and entertaining politicians in Davos. Instead, Zuckerberg spent the weeks between Thanksgiving and Christmas writing code. Zuckerberg identified the Poke app as a strategic necessity for the service he created, and he was not too proud to roll up his sleeves and help build it. Zuckerberg explained the management philosophy behind his “do it yourself” impulse in the letter he wrote to shareholders prior to Facebook’s IPO. In a section of the letter entitled “The Hacker Way,” Zuckerberg wrote:
The Hacker Way is an approach to building that involves continuous improvement and iteration. Hackers believe that something can always be better, and that nothing is ever complete. They just have to go fix it – often in the face of people who say it’s impossible or are content with the status quo….
Hacking is also an inherently hands-on and active discipline. Instead of debating for days whether a new idea is possible or what the best way to build something is, hackers would rather just prototype something and see what works. There’s a hacker mantra that you’ll hear a lot around Facebook offices: “Code wins arguments.”
Hacker culture is also extremely open and meritocratic. Hackers believe that the best idea and implementation should always win – not the person who is best at lobbying for an idea or the person who manages the most people….
To make sure all our engineers share this approach, we require all new engineers – even managers whose primary job will not be to write code – to go through a program called Bootcamp where they learn our codebase, our tools and our approach. There are a lot of folks in the industry who manage engineers and don’t want to code themselves, but the type of hands-on people we’re looking for are willing and able to go through Bootcamp.
Now, listeners to Digital Campus will know that I am no fan of Facebook, which I abandoned years ago, and I’m not so naive as to swallow corporate boilerplate hook, line, and sinker. Nevertheless, it seems to me that in this case Zuckerberg was speaking from the heart and the not the wallet. As Business Insider’s Henry Blodget pointed out in the days of Facebook’s share price freefall immediately following its IPO, investors should have read Zuckerberg’s letter as a warning: he really believes this stuff. In the end, however, whether it’s heartfelt or not, or whether it actually reflects the reality of how Facebook operates, I share my colleague Audrey Watters’ sentiment that “as someone who thinks a lot about the necessity for more fearlessness, openness, speed, flexibility and real social value in education (technology) — and wow, I can’t believe I’m typing this — I find this part of Zuckerberg’s letter quite a compelling vision for shaking up a number of institutions (and not just “old media” or Wall Street).”
There is a widely held belief in the academy that the labor of those who think and talk is more valuable than the labor of those who build and do. Professorial contributions to knowledge are considered original research while librarians and educational technologists’ contributions to these endeavors are called service. These are not merely imagined prejudices. They are manifest in human resource classifications and in the terms of contracts that provide tenure to one group and, often, at will employment to the other.
Digital humanities is increasingly in the public eye. The New York Times, the Los Angeles Times, and the Economist all have published feature articles on the subject recently. Some of this coverage has been positive, some of it modestly skeptical, but almost all of it has focused on the kinds of research questions digital humanities can (or maybe cannot) answer. How digital media and methods have changed humanities knowledge is an important question. But practicing digital humanists understand that an equally important aspect of the digital shift is the extent to which digital media and methods have changed humanities work and the traditional labor and power structures of the university. Perhaps most important has been the calling into question of the traditional hierarchy of academic labor which placed librarians “in service” to scholars. Time and again, digital humanities projects have succeeded by flattening distinctions and divisions between faculty, librarians, technicians, managers, and students. Time and again, they have failed by maintaining these divisions, by honoring traditional academic labor hierarchies rather than practicing something like the hacker way.
Blowing up the inherited management structures of the university isn’t an easy business. Even projects that understand and appreciate the tensions between these structures and the hacker way find it difficult to accommodate them. A good example of an attempt at such an accommodation has been the “community source” model of software development advanced by some in the academic technology field. Community source’s successes and failures, and the reasons for them, illustrate just how important it is to make room for the hacker way in digital humanities and academic technology projects.
As Brad Wheeler wrote in EDUCAUSE Review in 2007, a community source project is distinguished from more generic open source models by the fact that “many of the investments of developers’ time, design, and project governance come from institutional contributions by colleges, universities, and some commercial firms rather than from individuals.” Funders of open source software in the academic and cultural heritage fields have often preferred the community source model assuming that, because of high level institutional commitments, the projects it generates will be more sustainable than projects that rely mainly on volunteer developers. In these community source projects, foundations and government funding agencies put up major start-up funding on the condition that recipients commit regular staff time—”FTEs”—to work on the project alongside grant funded staff.
The community source model has proven effective in many cases. Among its success stories are Sakai, an open source learning management system, and Kuali, an open source platform for university administration. Just as often, however, community source projects have failed. As I argued in a grant proposal to the Library of Congress for CHNM’s Omeka + Neatline collaboration with UVa’s Scholars’ Lab, community source projects have usually failed in one of two ways: either they become mired in meetings and disagreements between partner institutions and never really get off the ground in the first place, or they stall after the original source of foundation or government funding runs out. In both cases, community source failures lie in the failure to win the “hearts and minds” of the developers working on the project, in the failure to flatten traditional hierarchies of academic labor, in the failure to do it “the hacker way.”
In the first case—projects that never really get off the ground—developers aren’t engaged early enough in the process. Because they rely on administrative commitments of human resources, conversations about community source projects must begin with administrators rather than developers. These collaborations are born out of meetings between administrators located at institutions that are often geographically distant and culturally very different. The conversations that result can frequently end in disagreement. But even where consensus is reached, it can be a fragile basis for collaboration. We often tend to think of collaboration as shared decision making. But as I have said in this space before, shared work and shared accomplishment are more important. As Zuckerberg has it, digital projects are “inherently hands-on and active”; that “instead of debating for days whether a new idea is possible or what the best way to build something is, hackers would rather just prototype something and see what works”; that “the best idea and implementation should always win—not the person who is best at lobbying for an idea or the person who manages the most people.” That is, the most successful digital work occurs at the level of work, not at the level of discussion, and for this reason hierarchies must be flattened. Everyone has to participate in the building.
In the second case—projects that stall after funding runs out—decisions are made for developers (about platforms, programming languages, communication channels, deadlines) early on in the planning process that may deeply affect their work at the level of code sometimes several months down the road. These decisions can stifle developer creativity or make their work unnecessarily difficult, both of which can lead to developer disinterest. Yet experience both inside and outside of the academy shows us that what sustains an open source project after funding runs out is the personal interest and commitment of developers. In the absence of additional funding, the only thing that will get bugs fixed and forum posts answered are committed developers. Developer interest is often a project’s best sustainability strategy. As Zuckerberg says, “hackers believe that something can always be better, and that nothing is ever complete.” But they have to want to do so.
When decisions are made for developers (and other “doers” on digital humanities and academic technology projects such as librarians, educational technologists, outreach coordinators, and project managers), they don’t. When they are put in a position of “service,” they don’t. When traditional hierarchies of academic labor are grafted onto digital humanities and academic technology projects that owe their success as much to the culture of the digital age as they do to the culture of the humanities, they don’t.
Facebook understands that the hacker way works best in the digital age. Successful digital humanists and academic technologists do too.
[This post is based on notes for a talk I was scheduled to deliver at a NERCOMP event in Amherst, Massachusetts on Monday, February 11, 2013. The title of that talk was intended to be “‘Not My Job’: Digital Humanities and the Unhelpful Hierarchies of Academic Labor.” Unfortunately, the great Blizzard of 2013 kept me away. Thankfully, I have this blog, so all is not lost.]
[Image credit: Thomas Hawk]
You’ve probably been there. A new job, a new project team, a new client. A great first meeting. Everyone is invited to talk, to listen, to contribute. Everyone is assured that their voices will be heard, their concerns addressed, their ideas taken seriously.
Fast forward a week, a month, a year. One by one, those voices have been silenced, those concerns dismissed, those ideas undermined. What remains are the ideas and concerns of the person who (it has now become clear) is in charge.
To do their jobs effectively, members of a project team need to know who the decision maker is. We all like democracy, those of us in education and cultural heritage especially so. If it’s truly a democracy, great. But if it’s a dictatorship, people would rather know from the outset than be led down a rhetorical primrose path of “democracy,” “consensus,” and “collaboration” only to have the rug pulled out from under them when the decision maker finally decides to assert his or her will.
If you are the decision maker, let us know. Anything less treats team members like children and wastes everybody’s time. What’s worse, it makes for shortsighted, haphazard, second-rate work product.
I got in a little bit of a friendly dust up yesterday on Twitter when I asked, “As I watch colleagues embark on the 2011 #jobmarket I have to wonder, why on earth does it take humanities departments 6+ months to hire?”
All of these reasons make sense to me. I’m just not sure they answer my question. They seem more like answers to the question of “how” it takes so long to hire rather than “why” it takes so long to hire.
(At this point, I should disclose that I have never formally participated in a tenure-track search process either as a candidate or a search committee member, so some of what follows may be totally naive and off base. If so, I apologize. But I have watched the process for years from a short distance as a friend of both candidates and committee members. I’m also a research faculty member and manager who does a fair bit of hiring himself, so if nothing else, I may have a valuable near outsider’s perspective to contribute. I hope so.)
Why, for example, does the hiring process have to follow the academic calendar? Couldn’t we shorten it to six weeks in December and January or schedule it around spring break or do it in the summer (paid, of course)? The answer comes back that we can’t shorten the process because the pool of applicants is so large. But there is a circularity to this line of thinking. If departments didn’t all hire on the same schedule, if there were multiple (necessarily shorter) hiring seasons, then some people would already know in September that they had a job and wouldn’t enter the November round at all. Still others could skip both the summer and winter seasons and wait until spring. Interview scheduling and campus visits would be made much easier as well. It seems obvious that if there wasn’t just *one* hiring season, there wouldn’t be so many candidates in any given season. This in turn would put paid—to some extent at least—to reasons and three and four. If the season was shorter and there weren’t so many candidates, it wouldn’t take up so much committee member time and energy either in meetings or in reading.
There are other questions one might ask; each of these reasons has problems when you dig a little deeper. For example, there are lots of busy people in lots of important jobs who juggle serving on hiring committees with normal work commitments. All small and medium sized businesses do their own hiring, and even at big companies with professional human resources departments, executives are heavily involved in making important hiring decisions. How do they manage the process so it doesn’t overwhelm their other work? Likewise, lots of hiring decisions in lots of fields have major, long term consequences—civil engineering comes to mind—but I’m guessing those fields usually manage to hire people in less than six months. At the very least they don’t stack the deck against a quick hire in advance, setting things up so that it can never take less than five or six months. What are they doing to insure they’re making safe, yet speedier hiring decisions?
Mainly, if we are going to accept any of these practices—including reading everyone’s scholarship and building consensus across departments—as valid answers to the “why” question rather than the “how” question, we first need to know whether they actually lead to better hiring decisions. I’m not sure we know with any certainty that they do. How many applicants’ scholarship do we really have to read to narrow it down to two or three? Is trying to get the bulk of the department membership on board an exercise in futility that causes more bad blood than it avoids?
Finding answers to these questions may lead us right back to where we started, but they’re worth asking on the chance that they could help us do a better job of placing the right people in the right jobs at lower cost and with fewer headaches. When every year I hear the same complaints from all sides about the academic hiring process, “the way we’ve always done it” just doesn’t satisfy as an answer.