My new outfit: Greenhouse Studios | Scholarly Communications Design at the University of Connecticut

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.

Greenhouse StudiosThe 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.

Elevator Pitch

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:

  • “The What” What is your project? What needs does it meet or problems does it solve? How does it meet those needs/solve those problems?
  • “The So What?” Why does this project matter? What are its implications for the field of scholarly communication? What are its broader impacts for the way scholarship is produced and disseminated?
  • “The What Next?” What is your plan for implementing your project? What will be the first thing/s you do to advance your project when you leave SCI? How will you maintain working communication between team members in the weeks and months ahead?

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.

Happy hunting.

Innovation, Use, and Sustainability

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:

  1. More emphasis on platforms. Surely the NLG program has produced some widely used digital library and museum platforms, including the ones I have worked on. But I think it bears emphasizing that the limited funds available for grants would generate better returns if they went to enabling technologies rather than end prodcuts, to platforms rather than projects. Funding platforms doesn’t just mean funding software—there are also be social and institutional platforms like standards and convening bodies—but IMLS should be funding tools that allow lots of people to do good work, not the good work itself of just a few.
  2. More emphasis on outreach. Big business doesn’t launch new products without a sale force. If we want people to use our products, we shouldn’t launch them without people on staff who are dedicated to encouraging their use. This should be refelected in our budgets, a much bigger chunk of which should go to outreach. That also means more flexibility in the guidelines and among panelists and program officers to support travel, advertizing, and other marketing costs.

Sustainability is a red herring

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.

No Holds Barred

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.

  1. You don’t have a mobile strategy. This is by far your most pressing need. According to the Pew Internet and American Life Project, already more than 45% of Americans own a smartphone. That number rises to 66% among 18-29 year olds and 68% among families with incomes of more than $75,000. These are people on the go. You are in the travel and tourism business. If you are only reaching these people when they’re at their desks at work—as opposed to in their cars, on their lunch breaks, while they’re chasing the kids around on Saturday morning—you aren’t reaching them in a way that will translate into visits. This isn’t something for the future. Unfortunately, it’s something for two years ago.
  2. You don’t have an integrated social strategy. I could critique your website, and of course it needs work. But a redesign is a relatively straightforward thing these days. The more important thing to realize is that you shouldn’t expect more than a fraction of your digital audience these to interact directly with your website. Rather, most potential audience members will want to interact with you and your content on their chosen turf, and these days that means Facebook, Twitter, Pinterest, Tumblr, and Wikipedia, depending on the demographic. You have to be ready to go all in with social media and dedicate at least as much thought and resources to your social media presence as to your web presence.
  3. Your current set of researcher tools and resources aren’t well-matched to what we know about researcher needs and expectations. Ithaka Research, a respected think tank that studies higher education and the humanities, recently released a report entitled “Supporting the Changing Research Practices of Historians” (I’d encourage everyone here to give it a good read; it has a ton of recommendations for organizations like this one grappling with the changing information landscape as it relates to history). One of its key findings is that Google is now firmly established as researchers’ first (and sometimes last) stop for research. Lament all you want, but it means that if you want to serve researchers better, your best bet isn’t to make your own online catalog better but instead to make sure your stuff shows up in Google. As the Library of Congress’s Trevor Owens puts it: “the next time someone tells you that they want to make a ‘gateway’ a ‘portal’ or a ‘registry’ of some set of historical materials you can probably stop reading. It already exists and it’s Google.” This speaks to a more general point, which is related closely to my previous point. Researchers come to your collection with a set of digital research practices and tools that they want to use, first and foremost among these being Google. Increasingly, researchers are looking to interact with your collections outside of your website. They are looking to pull collection items into personal reference management tools like Zotero. More sophisticated digital researchers are looking for ways to dump large data sets into an Excel spreadsheet for manipulation, analysis, and presentation. The most sophisticated digital historians are looking for direct connections to your database through open APIs. The lesson here is that whatever resources you have to dedicate to online research collections should go towards minimizing the time people spend on your website. We tend to evaluate the success of our web pages with metrics like numbers of page views, time spent per page, and bounce rate. But when it comes to search the metrics are reversed: We don’t want people looking at lots of pages or spending a lot of time on our websites. We want our research infrastructure to be essentially invisible, or at least to be visible for only a very short period of time. What we really want with search is to allow researchers to get in and get out as quickly as possible with just what they were looking for.
  4. You aren’t making good use of the organization’s most valuable—and I mean that in terms of its share of the annual budget—resource: its staff expertise. Few things are certain when it comes to Internet strategy. The Internet is an incredibly complex ecosystem, and it changes extremely quickly. What works for one project or organization may not work for another organization six months from now. However, one ironclad rule of the Internet is content drives traffic. Fresh, substantive content improves page rank, raises social media visibility, and brings people to the website. Your website should be changing and growing every day. The way to do that is to allow and encourage (even insist) that every staff member, down to the interns and docents, contribute something to the website. Everybody here should be blogging. Everyone should be experimenting. The web is the perfect platform for letting staff experiment: the web allows us to FAIL QUICKLY.
  5. You aren’t going to make any money. Digital is not a revenue center, it’s an operating cost like the reading room, or the permanent galleries, or the education department. You shouldn’t expect increased revenues from a website redesign any more than you should from a new coat of paint for the front door. But just like the reading room, the education programs, and the fresh coat of paint, digital media is vital to the organization’s mission in the 21st century. There are grants for special programs and possibly for initial capital expenditures (start-up costs), but on the whole, cultural organizations should consider digital as a cost of doing business. This means reconfiguring existing resources to meet the digital challenge. One important thing to remember about digital work is that its costs are almost entirely human (these days the necessary technology, software, equipment, bandwidth is cheap and getting cheaper). That means organizations should be able to afford a healthy digital strategy if they begin thinking about digital work as an integral part of the duties of existing staff in the ways I described earlier. You probably need a head of digital programs and possibly a technical assistant, but beyond that, you can achieve great success through rethinking/retraining existing human resources.

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.

The Hacker Way

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.

hackerMark 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]

Take me to your leader: The importance of knowing who's in charge

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.

The long haul: Why do academics take so long to hire?

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?”

Needless to say, I received a lot of answers. I won’t list all of them but I think the following distillation does them justice:

  1. Because the pool of applicants is large;
  2. Because the hiring process follows the academic calendar;
  3. Because faculty members are busy people and search committee activities must be scheduled around other commitments;
  4. Because we take time to read candidates’ scholarship as well as their resumes;
  5. Because tenure track decisions have long term consequences;
  6. Because hiring depends on building consensus across a department.

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.

Alt-Conference Venues

A discussion today on Twitter about the rising costs of conference space, even on campuses, which in many cases charge their own faculty and staff for use of facilities, got me thinking that we humanists should be thinking more creatively about where to hold our gatherings.

The Hilton is nice. But as THATCamp has shown, it’s not an essential (or maybe even desirable) ingredient for hosting a good conference or enabling productive scholarly communication. Just as urban artists find cheap, usable—even cool—studio space in warehouses and garages, we should find ourselves some alternatives to the traditional hotel ballrooms and campus auditoriums.

So, here’s the start of a list. On the one hand, there are some places in most cities that rent space at low cost. In this category, I’d put the YMCA, local churches and synagogues, local public schools, those big suburban wedding halls they advertise on late night cable, and KOA and other campgrounds (hat tip, Brian Croxall). On the other hand, there may be places that are willing donate space that is otherwise unused on weekends. What about asking a local business for use of its offices and providing them with documentation for tax purposes of the in-kind charitable donation? What about asking a local foundation for use of its offices in lieu of a monetary donation?

None of these places will make us feel as important as we do when checking in at the New York Hilton. But they’d all serve just as well for communicating ideas. Please add your ideas for alt-conference venues in comments. Let’s build a list.

Lessons from One Week | One Tool – Part 3, Serendipity

Over the past few months, several people—including several participants themselves—have asked me how we chose the One Week | One Tool crew. We had about 50 applicants. Nearly all of them were perfectly qualified to attend. This made the selection process exceedingly difficult. I have no doubt we could have ended up with another group of twelve and been equally successful. Indeed, I have often joked that with the applicant pool we got we could easily have done "Three Weeks | Three Tools."

In the end, the uniformly high quality of our applicant pool meant we had to make our choices on largely subjective criteria. Who showed the most enthusiasm? Who showed the most willingness to collaborate? Who seemed open minded? Whose writing style showed clarity of thought and energy? Who seemed like the hardest workers? Who seemed eager to learn? Whose seemed like a quick study?

One important thing to note is that we didn’t pick for particular technical skills. Of course we wanted a good mix: a team full of UI specialists or outreach experts wouldn’t have worked. But we didn’t select for PHP, Ruby, Java, TEI, or any other technology. We assumed that if we picked good people with a range of skills, even if those skills were all over the map, we’d end up with something interesting. I think we have.

As it turns out, we have ended up with something even more interesting because of that diversity of skills. Boone said something very telling at the bar on Thursday night: Anthologize probably couldn’t have been built without One Week | One Tool. A single shop wouldn’t have had the necessary range of skills to do it. I know CHNM couldn’t have done it alone. Sure, we have the PHP and JavaScript chops (although not the intimate knowledge of WordPress Boone brought to the table). But we certainly don’t have deep knowledge of TEI and XSLT the team needed to produce Anthologize’s rich, clean outputs. Nor, I suspect, would we even have hit upon TEI as a solution to that particular problem.

There are lessons here for hiring. Pick the smartest people. The best writers. The hardest workers. Pick people with proven track records of working well in teams. People with lots of energy. People who approach heavy workloads with clear thinking and good humor. People who’ve shown aptitude for picking up new technical skills on their own.

These people may not know what you need them to know on Day 1. But they will work hard to learn it. They’ll also bring a host of additional skills you didn’t think you needed, but will be happy to have once they’re there. Having these additional skills on tap may even let you take your work in directions you couldn’t have otherwise imagined.

#oneweek #buildsomething

Lessons from One Week | One Tool – Part 1, Project Management

Three days into One Week | One Tool, I’m beginning to see that one of the nice things about running an NEH Summer Institute as a practicum rather than a classroom is that the organizers learn as much as the participants. For me, this week has reinforced and clarified an important set of related lessons about decision making, leadership, and team building in digital humanities. (I’ve learned some other lessons as well, and I’ll talk about those in subsequent posts over the course of the week.) As you can imagine, things are a little busy around here, so here they are in short.

  1. Snap decisions are good. When faced with a choice between A and B, it often pays simply to pick one and move on. It’s tempting to think that hours of study and deliberation will yield the “right” answer. But the truth is most project management questions don’t have right answers. Furthermore, no amount of research will insure that everyone will be happy with your decision. At the end of the day, some of your stakeholders or team members are going to be disappointed with your decision, and time spent purely in hopes that you can satisfy everyone is time wasted. Finally, no matter how much prior study and deliberation, decisions are always and inevitably made in the moment. Put another way, the moment of decision always involves a snap judgment. You’ll never know if the decision you’ve made is a good one until after you’ve made it. Bottom line: when faced with tight deadlines, do just enough research to understand the consequences of A or B, pick one, and then deal with those consequences.
  2. Leadership is momentum-making. It may seem obvious, but the job of a leader is to move people forward. To keep people with you have to be constantly in motion. This is the importance of snap decisions. People will forgive a leader a bad decision. They can’t forgive indecision. Like a ship, leaders create a wake that pulls people along. If you stop, they will drift away.
  3. Collaboration is shared doing. We tend to think of collaboration as shared decision making. But more important is shared accomplishment. Consensus on a project is certainly important, but strong collaborations aren’t forged in talking, they’re forged in working. As noted above, one or more team members will always be unhappy with every decision that’s made on a project . Trying to understand and accommodate their concerns will help mend any hurt feelings or disappointments, but what’s really going to bring them back into the fold is getting down to work on the task they had previously opposed. Getting people to invest some time in a decision they opposed initially is the quickest way to help them see its merits and reengage their coworkers. Helping them contribute to the team is the best way to make them feel valuable and valued again.

More to come. #oneweek #buildsomething