[This is a roughly-edited version of a keynote talk I gave last month at #code4lib, a fantastic annual conference for software developers and systems folks working in libraries. If you want to hear my bad jokes and attempts to pander to the crowd (or at least to let them know that I was conscious of the back-channel), or if you’d like to see what happens when I indulge my nerdiest tendencies in slide production, I recommend the archived livestream. I’m skipping a long pre-amble that included the Super Friends, hostile IRC bots, and a description of my own professional background – in which I slowly moved from literary and bibliographical scholarship to working with independent DH projects in scholarly think-tanks and projects that sat alongside libraries, to working in and for a library, and as a part of the blended digital humanities/library community that many of us inhabit now.]
The biggest surprise I had about my emigration to Libraryland will be of no surprise to those of you who have been here longer, or who came out of an I-school, or otherwise basically grew up in the culture. And that is that the shift radicalized me. Coming to the Library woke me up: on matters of privacy, on labor conditions and class issues in higher ed, on the sucky practice of training of humanities grad students for non-existent jobs, on free & open access to information, and (especially for those of us who work at publicly-funded institutions) on the rights of taxpayers to expect quality work for the public good out of what they help pay for.
So it may sound like I’m going to give an activist talk. That’s true to some degree, but I’m mostly going to give an impatient one — a talk that comes from where I am now. Although I used to be on the design and development side of things, I am now a soulless administrator, and therefore I thought the most useful function I could perform at code4lib would be to bring something back to you from that perspective. My title will therefore not immediately suggest an activist agenda.
Welcome to… “Lazy Consensus.”
Could anything sound less like “How impatient people can change the world?” This is a phrase that rings of nothing more than lying in a hammock, singing kumbaya. But my goal will be to introduce lazy consensus as a tactical approach for moving committees and organizations and institutions (and, hey, maybe even nation-states!) despite themselves. And I have another message today. “Lazy consensus: you oughta wield it — because it’s already being wielded against you.”
There’s not much chance that a code4lib attendee hasn’t heard this term before or even had some personal experience with lazy consensus as it is formalized in situations like committee voting. It works like this: when a decision needs to be made, someone steps up with a proposal about how to proceed, and the whole group gets a certain amount of time to speak up against it. People in favor might, lazily, give it a +1. (That’s three languid taps on the keyboard for approval, Lebowski.) And there’s no obligation even to do that much — because (here’s the important thing) the default answer is always yes.
This shift in perspective alone, for group that can agree on lazy consensus as a tactic for vote-based decision-making, can be major. Lazy consensus turns the very worldview of places that have a habit of issuing knee-jerk “noes” on its head. Yes becomes the default.
If yes is your lazy-consensus default and the clock runs out with no major objections to the original proposal being voiced, the group moves forward with it. If you have to go back to the drawing board because people do object, you go – but the comforting thing about this tactic is that at least you didn’t stay there, at the starting line, forever and ever amen. You’re always moving quickly to concrete, generally reasonably-implementable proposals that (in most cases, in my experience) only need some iteration and adjustment before they’re good to go. And the beautiful thing for large, slow-moving, and bureaucratic organizations (like libraries) is that, to stop you from rolling forward, somebody had to be paying enough attention to notice, and then had to care enough to craft and voice an opinion behind which others might see a plausible rationale. This lies in contrast to the situation in far too many organizations and groups, where, oftentimes, an untoward amount of institutional inertia or even disengagement must be overcome before anybody feels licensed to move.
You might be tempted to sum all this up as “Fortes fortuna adiuvat.” But the basic idea behind lazy consensus is a little less Gladiator and a little more Downton Abbey. It’s a social contract, which works like this. If we operate in by lazy consensus, we already agree on one thing: if you can’t be bothered to say yes or no to my proposal in a timely fashion, you probably don’t fundamentally care about what happens on this occasion – so we’re not waiting on you, and will assume (no harm, no foul!) that you are getting yourself out of the way while those of us who do care carry on.
As a principle, lazy consensus understands that inertia can work with you or against you. After all, an object in motion tends to stay in motion. An object at rest tends to stay at rest.
When you’re using it on the up-and-up — in social-contract mode — lazy consensus requires that everybody understand and agree to the rules. In fact it is probably written it into your by-laws. But we live in the messy, unwieldy, largely un-regulated real world. It’s no accident that I use a physics metaphor, Newton’s First Law of Motion, to describe how we might apply the concept of inertia to decision-making in organizations. This is because lazy consensus is not only a tactic to use under clinical conditions (such as opinion-polling of members of a committee). It may be a social contract — but in all frankness it’s also a practically a natural law.
You can no more effectively deny the power of lazy consensus than you can deny gravity or thermodynamics. It will act on you whether you acknowledge it or not.
And that brings me to something about which it is important for me to be crystal clear. My whole talk today is governed by a moral imperative. [Here I exercised the prerogative of the second keynote speaker in a conference, by inserting a slide that positioned my own chaotic-neutral talk against that of our very lawful-good opening speaker -- that paladin of code4lib, Dan Chudnov. ...You had to be there.] This a moral imperative I want to make sure you understand — because I’m about to give you my most reckless advice. You will shortly hear me advise you to do the very thing that (done poorly) regularly earns even the best library-based software development groups a reputation for being un-governed, disconnected. For being loose cannons.
My reckless advice is that your team — collectively, not individually, mind you — begin to operate by lazy consensus not only on special occasions (as, for instance, a refreshing change from Robert’s Rules of Order), but instead as your default mode: the way you function every day, in almost every corner of in your working lives.
In order to give you this advice in good conscience, I need to paste warning stickers all over it. And this is what they say: “You must only use lazy consensus to do what you know is right.” That’s the moral imperative. And yes, we have reached the schmaltzy portion of our program.
How do you know what’s right? How do you know what lazy-consensus action you (the collective you) might take for the collective good? The answer itself (just like this tactic’s desired outcomes) is not lazy at all. It requires some inward-directed energy on your part. If you operate in this way, lazy consensus will require a gut-check every day from here on out. (And I’ll talk in more specifics in a moment about how to make sure your gut is trustworthy.)
I’m here today to advocate what I’ll call an extreme bias toward action – but also to urge you to do your damnedest to make sure you’re one of the good guys. If you’re going to be somebody who acts – who acts as a matter of course, instead of feeling frustrated and thwarted by others’ inaction – then your actions need to be to the best of your conscience in service of the Right Thing.
This is an inherently dangerous position for me to take, and for you to act on. The danger we place ourselves in comes from beauty and from power. The beauty is that following this moral imperative within the laws of Lazy Consensus turns out not just to get things done, but to be a prime mover. It’s going to make you one with nature, my friends. Lazy consensus wielded wisely and justly is capable of galvanizing comatose organizations back into motion and even of reversing terrible inertial trends.
We find a recent example in the SOPA/PIPA blackouts. [More geekery and self-indulgence when I play the "Shut it down -- forever!" clip from the great film Dark City.] Here’s a case where legislative consensus seemed to be sliding almost inevitably in one direction, when suddenly it was tipped in the other by a group of infrastructure and content providers — who did not merely lobby and educate, but who acted, and acted in a way that provoked many, many people also to act, in this case, to call and write their representatives. It was a speaking-out that provoked others to speak up where they had been silent, where they had been the ones therefore assumed not to care. The result was a change in many legislators’ expressed opinions, but even more noticeable was the shift of the politicians – similar to the one we saw first among the citizenry — toward taking a position at all. The resulting abandonment of the proposed legislation reflected not only the will, but the engagement of the people. No more silent, assumed-to-be +1s.
Now, that was a pretty big gesture. It was disruptive — and not entirely signed-off-upon, and viral and in my opinion a force for good. It’s hardly ever this dramatic day to day. But lazy consensus also applies to our little, diurnal decisions – which, taken cumulatively, can have a huge impact on the people and concepts and institutions we care about. The cultural shift that comes about when you make lazy consensus your default mode is a fundamental permissioning. You’re giving yourselves (the collective you, that is, the technical team) permission to do what you know is right – and to assume that the answer to “can we move on this?” is unless directly countermanded, a resounding yes.
I think you can use lazy consensus on the side of Good anywhere, at all levels, without going entirely rogue. But what creates the ideal conditions for it?
I have five. Your mileage may vary. I offer them simply to get you thinking about your local conditions — about what would work for you.
- First on my list? Being in an organization that deliberately makes room for a skunkworks or a pure R&D operation. Benefits ripple outward, even if you are not a member of that group – with one big proviso: that you and others generally trust the skunks and know that they have a solid plan for getting the most worthwhile of their creations into stable production.
- If a healthy skunkworks or a dedicated R&D team is not in the cards for your organization, try negotiating something like 20% time, on the Google model, for R&D work done by developers across the board. This is a model we have used to excellent effect in the Scholars’ Lab, where, among other things, it resulted in Project Blacklight and work that evolved into the multi-institutional Hydra project.
- I strongly advise spontaneous, developer-driven, grassroots rabble-rousing that (here’s the important part!) looks enough like your local structures that you’re able to build on whatever cultural capital and normalized (preferably positive) expectations those structures have earned — whether they are committees or interest groups or task forces or even book clubs. Organize!
- Next up? Know your enemies. They are fewer than you may think. Middle-management sucks? They are probably well aware of that at the top. But what I find key, and often offer as advice, is that you do whatever level of work your own psyche will require such that you can extract personalities from the mix and realize that you are generally fighting bad trends, not bad people. Or at least try to make yourself think this, even if you have a feeling it’s not true. Frustrations stemming to personalities and egos will only distract and deter you as you fight the good fight.
- Finally, find your friends! Where are they? If you’re a software developer in the library, you will possibly find them in that department that needs you and annoys you the most — or maybe in the skunkworks org that lives among you and is getting a little disconnected. But I also guarantee you’ll find friends out among your institution’s digital humanities faculty and open-access or data-preservation-minded scientists. You also can’t do better than to seek out like-minded allies at whatever library your library looks up to and wishes it could to be.
On with the lists! What are your ethical obligations, if you adopt a standing, lazy-consensus tactic in Libraryland? Another five.
- Embrace the loyal, engaged opposition. They get the same info everybody else gets. If you withhold information from smart and willing people who disagree with you, even if you happen to make things move your way in the short term, you will fail at the ethical game of lazy consensus. The opposition does get its chance to object. It’s a courtesy you’d expect from them.
- Never ever ever shut out UX and Public Services. Depending on the climate in your institution, that could be a variety of the former bullet, but it’s important enough of a danger for library-based software development to stand on its own.
- Practice what you’d teach. By this I am advising you to act every day like you would if you were consciously mentoring a promising novice developer in your department. That might mean anything from employing test- & behavior-driven development, to producing impeccable documentation, to working hard toward healthy deployment practices for the betterment of vampires & werewolves everywhere.
- If you f*ck up, ‘fess up. That is (not to put too fine a point on it), if you try this approach and fundamentally screw up, be prepared to confess your sins and use the conversation as an opportunity to become more savvy about your place of work. The main point is not to hide your messes. Even though in a moment I will tell you something that may seem to run counter to this principle, lazy consensus works best within an open information economy.
- And try not to screw up in the first place. That sounds incredibly flip, but I mean something more specific by it than you might think. It’s a twinned notion that ties together some of the other items in this list. First, as library-based developers, to my mind, your “not screwing up” means trying your hardest to deliver the highest-quality conception of whatever end-user experience your organization is striving toward. It’s also a charge to accomplish that goal in a way that, on reflection, will not make you ashamed of yourselves.
You’ll have to address your own conscience on that last point, but I want to be clear that, from my own vantage-point, this does not need to mean, “deliver the code that a non-coder told you to write.” (We’re now verging into the excessively dangerous portion of my talk.) It also doesn’t mean “deliver something that uses every half-baked component imposed on you by somebody who wouldn’t know if you actually used it or not — or won’t even remember, three months from now, that they forced it down your throat.” [Notable frisson in the room, not least from the podium, where the speaker momentarily wonders if she’ll get fired.]
I bring these things up because I’m about to tell you two things I’ve observed about library administration. It’s also the reason I stressed that you have to wear your white hats when you take my advice.
If your leadership is imposing truly bad technical decisions on you (I’m not talking philosophical decisions, mind, but software engineering ones), there’s a secret you should know: they are probably not technically smart enough to understand whether you have implemented those directives to-the-absolute-letter or not. I find no shame in openly acknowledging that good-hearted administrators can sometimes seriously over-reach on the technical front, simply out of a desire to do the jobs we have been given, with the conceptual tools we have at hand. (The structure of our working lives can leave once-bright tools to rust. This may be the subject of another talk.) For you to be a successful lazy-conensus dev team, it’s important to know that, no matter what it seems to say to you, your administration cares more about the spirit of its law than about the letter of it. That is, they care more about the end than the means.
That said: try! Before you take a lazy-consensus approach that organizes a collective of smart people to route around bad directives, genuinely try to explain and to teach, at all levels of your organization. If you intend to wrest back a level of technical decision-making that belongs appropriately with the developers in your organization — don’t do it as an individual. Don’t go it alone. The word “consensus,” after all, is in there for a reason. Please make sure, when you take initiative on things you know that members of your leadership will not entirely grok, that there are enough of you who agree on the direction to take that you can implement it reasonably and with some assurance of sustainability. In other words: don’t be that guy or gal – the one whose renegade, unsupported crap we’re all cleaning up when we discover it five years later – or the one who has, out of ignorance about how the whole library works, imposed an un-workable workflow on other departments. Be talking with each other, and especially with the people you might not see everyday, but who depend on you.
You need to have some common sense in other ways, too. There’s a level at which people will notice that you acted counter to a half-baked directive. But the thing is – that level, of noticing? It’s generally a lot higher than you think. I am belaboring this point because I have been saddened to see good people in more than one slightly clueless organization assume that squishy, cloudy, misguided directives from middle management are the rule of law – when in fact the folks at higher levels are hungry for push-back and are actually expecting the degree of healthy friction that indicates all of their people are thinking hard. I might sum up my advice in this regard as follows: don’t fall on your sword every time you turn around.
This gets back to my other observation about administration. Admin wants momentum more than it wants to micro-manage. So, produce. If you are the team that produces highly usable and sustainable systems, somebody will have your back.
This does mean that you have an obligation to deliver a product that your non-lazy allies, your +1s, can get behind and be proud of. And even more than that: I’ll go so far as to say that if you’re wielding lazy consensus tactically, you are bound to make even the laziest slugs among you, the deadweights in your organization, the people who can’t be bothered, come out of the whole affair smelling like a rose. (My tendency is not to worry about them: they’ll get theirs.)
Okay, let’s zoom out from the library a little bit. I said you ought to wield lazy consensus, because it’s already being wielded against you. (And here’s where I’m going to get a tad political.)
Where is lazy consensus working against us? Most likely, at the policy level at your college or university, where labor issues intersect with intellectual property rights. Specifically, many universities have antiquated, outmoded policies governing IP and patents – which are designed to bring in money from Big Pharma, but which accidentally stomp all over digital library and digital humanities stuff, where you actually bring in more money and prestige by not trying to monetize anything. I suggest you go home and check out your school or institution’s IP policies. You’ll probably find that they limit the ability of non-faculty developers and researchers, who typically fall under the category of work-for-hire, to make fundamental decisions about their own code and content – specifically whether they can share their work as freely, in the form of open-source software, as most of us in this community know we should, and as other types of knowledge workers at the institution may already be allowed to do. It’s no wonder that lazy consensus has worked against us on this issue. How many developers that you know show up for Faculty Senate meetings, or weasel their way onto policy committees at the university level? Hey, how many of your managers do?
This kind of passive disenfranchisement extends to the public sphere, in issues like the corporatization of higher ed. Or the irrational political separation in our country of the humanities from the sciences. (For organizations like the NEH and the IMLS, being left out of policy conversations means being left out of funding decisions.) Or look at the shambling zombie of the No Child Left Behind Act, in which K12 education has become a game of teach-to-the-test.
And then we’ve got Fight Club Soap — the scholarly publishing situation we’re all so familiar with — in which universities pay for the research and writing of scholarly articles, and for the time of their faculty to peer review and edit them, only to turn right back around and purchase the products of that labor back from publishers at an exorbitant mark-up and in unbreakable bundles. (I’m heartened to say that the tide is beginning to turn on this, with researcher boycotts and a shift from librarians calling foul to faculty doing so. The emphasis on Elsevier alone at this point is probably unjust, even if hugely symbolic, but my feeling is that we see in the current grassroots boycott a case where the crucial constituency, who have previously been silent and therefore assumed to give lazy consent, are finally speaking up. And just in the nick of time, because the Research Works Act is on its way. [Note: at the time of the publication of this transcript – "Ding, dong, the witch is dead!" – at least temporarily.]
Now, my point with these examples has not been to push any one agenda at you, but to suggest that lazy consensus has already been working against us in every case where we don’t engage. You can easily see its negative side in the wider political arena. But on the very local level, it kicks in and becomes a factor in any set of decisions where we developers and systems folks and middle management get so busy that we go completely heads-down and become oblivious to larger trends and directions. When that happens, we end up not having a voice. We end up being the people who don’t speak up even though we’re nominally represented, and no matter what we may really think, we are therefore assumed to be a +1.
“Feeling shut out” from decisions in your library, by the way, is not a valid excuse. In a worst-case scenario, if you don’t have a trustworthy conduit in management or any reasonable forum for direct contact with leadership, it’s your job to make one. This gets us back to the notion of finding your friends: storm the barricades! (By which I mean: do your homework so that you are impressively well-informed and then knock on your AULs’ or deans’ or library director’s doors. Knock politely. After all, it’s a library.)
That should be your first step. But then try a lazy-consensus approach. If you and your group are really feeling fundamentally blocked and disconnected, try announcing that, unless you hear otherwise, you will plan to attend the next meeting of your library’s leadership group to discuss the issue. Not the subcommittee for blah-de-blah, mind you. I’m assuming you’ve tried them – tried in earnest. In true lazy consensus mode, you will not really be requesting, but rather stating that, for this one, you expect a seat at the grown-ups’ table. Make your leadership tell you that you can’t have it. (My prediction? They won’t.) In fact, it often surprises me how often decent, smart people on either side of the management/labor divide in organizations seem to be waiting, middle-school-dance-fashion, for the other to make the first move. If your team feels like it’s been ignored or stonewalled, it should put its own (audacious, if weirdly collective) ass on the agenda. I guarantee that your specific problem or your overall working conditions (whatever it is you needed to talk about) will be thoroughly discussed — both with you in the room and (this is the scary but needful part) after you leave.
I want to wind my talk up by making a straightforward assertion. In the public sector and in higher ed, libraries are collectively facing enough challenges to warrant a fundamental attitudinal shift in organizational thinking. The shift is to implement, at all levels in each organization, a bias toward action. But do not forget the primary mandate of this talk. When you’re taking advantage of a lazy-consensus technique, it should have the effect of keeping you in the best possible conscience. You should undertake this only in order to do what you know is right. I am offering you license to be an agent for positive change — not the biggest jerk your library has ever seen.
Please know that I had to think really hard about whether I wanted to advocate this kind of behavior to you today. It’s risky all around: personally and institutionally. Ultimately, I decided that, at this moment, for libraries, stagnation is a far, far greater evil than the taking of reasoned risks — and that, by and large, your library directors and deans would agree with me that fighting stagnation would be worth having to cleaning up the odd, renegade mess or two. You’ll have to make your own mind up about when and whether any personal risk is worth it to you.
In the sort of weird, hybrid job I have now, I work with a lot of different kinds of people: not just developers in the digital humanities and in libraries, but students and scholars (from undergrads to grad students to adjuncts to professors emerita). I work with university administrators, outside consultants and vendors, heads of professional organizations, book and journal publishers, librarians from across the metadata-to-public services spectrum, and probably more that I’ve forgotten to name.Of all those, I wholeheartedly believe that software developers and systems folks have the right mindset for the operational and philosophical method I’m advocating. You have the meticulousness, the deep practicality, the impulse to build and to maintain, and the utter lack of ability to suffer fools gladly that positions you uniquely to make needed contributions — not just to the code, but to the culture of libraries. And we’re working at a time when those institutions need to move, not to sit still.
[Our scene closes with a slide of my 8-year old boy, smiling at the tableau he’s created: two GI Joes from his father’s childhood closet, riding a plastic Taun-Taun. The caption? "Drive It Like You Stole It." Exeunt Nowviskie & Code4Lib 2012, pursued by a bear.]