Essays and rants on libraries, technology, webdev, etc. by Ruth Collings

Code4Lib 2017: Every Library is a Technology Organization: Bringing DevOps principles to libraries

Abstract: The DevOps Handbook is a guide to re-organizing your workplace for greater speed in producing new ideas, more stability in key systems, and increased satisfaction among employees and customers. If technology should be at the centre of libraries, here is one way to make that real. Development becomes Public Services, Operations becomes Systems, and Products become Services. Public Services, traditionally handled by librarians and library technicians, is merged with the system admins, web developers, and programmers usually in Library IT department. By combining forces, the process of turning ideas into reality becomes streamlined. When getting things done takes less time, assessment is that much more meaningful, allowing for continuous improvement of services. With IT and librarians working more on the same page, priorities become shared, trust between departments improves, and the patron’s experience becomes better. Can this magical world exist in real life?


Thanks to Aaron Collier & Whitni Watkins for making this remote presentation possible!

I’d like to start by acknowledging that this conference is taking place on the traditional unceded territories of the Tongva/Gabrielino people and that I live and work on the traditional unceded lands of the Mi’kmaq and Wolastoqey people in what is now Fredericton, New Brunswick, Canada.

Hi, my name is Ruth Collings and I work at the University of New Brunswick as a full-time science librarian, but I’ve also been a solo systems librarian and a web dev librarian. What I want to talk to you today are some ideas I have developed over a few years now. I owe partial credit for my lightbulb moment on this topic to Gillian Byrne at the Toronto Reference Library and everybody else on Twitter for talking over this problem with me.

In the abstract for this talk I reference The DevOps Handbook by Gene Kim, Jez Humble, and John Willis and that is the basis of this talk. However, I’ve made a serious effort to avoid tech jargon and requiring a lot of prior knowledge. On the last slide of this talk I will be sharing some links to other reading if you are interested, but if I don’t cite a quotation or idea you can assume it came from the Handbook.

I hope to talk to you in a somewhat abstract way about some ideas I’ve had about DevOps, libraries, and management.

Here is a quotation attributed to Christopher Little.

“Every company is a technology company, regardless of what business they think they’re in. A bank is just an IT company with a banking license.”

I’m not sure if this is a hard sell to this audience, but to some working in libraries it really would be. However, whether or not you agree, this attitude is definitely not reflected in our library organizations. I’m going to continue this talk along the premise that this quotation is true, but if you want to read more on this topic you should look up: Libraries are Software – Cody Hanson

Here’s a scenario:

  • Systems wants to keep things running smoothly and Public Services wants to make changes quickly (or vice versa!)
  • Large, important systems (like the ILS) rarely get updated because they are fragile
  • People become territorial about their areas of work
  • Even small decisions require permission from multiple people, or committees
  • Everything is high priority and everything is always on fire
  • Your org always seems to be lagging behind comparable orgs
  • Everyone starts wondering if what they’re doing has any point, and then people who can afford to, quit

Does this sound like your organization? It’s actually an extremely common spiral of death in organizations of all types and it takes a lot of work to get out of it. That’s the problem DevOps proposes to solve.

This slide is just an overview or summary of part of the Handbook, but I’m going to get into detail on how this relates to libraries shortly.

Doing DevOps Means…

  • Faster and more frequent implementation of ideas
  • Fewer “crunch-time” emergencies
  • Improved worker morale
  • More stability in key systems

Doing DevOps Requires…

  • Clear, consistent, & measurable goals
  • Group trust & empowerment of all workers
  • Dedication to improving work processes
  • Ongoing, constant self-assessment, feedback, & testing

If there is one key point I can emphasize it’s that it’s not about just doing things a certain way. Stand-ups, scrums, kanban boards, whatever. I would like for us to be motivated to focus on making the process of working better for us and our coworkers, whatever that looks like. Everything will follow from that.

The fundamental premise of DevOps is in the name: it’s a merging of two normally separate departments, Development and Operations. In libraries, more often than not, Public Services or Reference take the place of “Development” and a Systems or IT team are “Operations”. Ideas start at Public Services and are handed off to Systems - “make it happen!”. So instead of DevOps we have PubSys. (That’s the best I could come up with, please bear with me.)

Our ideal PubSys library is on Mars. It’s a university library because that’s what I have experience working in, not to look down on the Mars public libraries.
We start at the top of the org chart with a University Librarian who is probably reporting to someone else higher up, but overall is the lead decision-maker for this library.

Underneath this UL we have a team of administrators. To quote Gillian Byrne, “Administration is too important to be confused with – or run by – managers.” These people would be in charge of things like keeping track of vacation time, dealing with confidential interpersonal issues, legal issues, budgeting, that sort of thing.

Underneath the University Librarian is where it’s going to get messy.
The reason why I haven’t made this a traditional organizational chart here with boxes and lines is because I realized I would need to step out of the mixed hierarchical-committee based model. If you become really committed to merging public services and systems your UL and administrators are going to have to give up on the idea that they can or even need to have control over all other workers.

So instead of departments or units under managers we have Project Groups.
Each group has a Project Leader who takes ownership of the project and provides project management support. Note that they are a project “leader”, not an “administrator” in the sense that they have a specialty called Leading, but it is equal to other specialties within the organization.

Next, based on the needs of the project we have people who have relevant skill sets, or they’re involved in the daily work of the project, or people who want to learn more about the work. Groups should not exceed 5-7 people because if you go over that communication becomes inefficient and drags you down.

What’s the point of reorganizing your entire structure, Ruth? That’s going to be really hard!

I want you to think back to yesterday morning when we heard from Dre Orphanides about systems thinking.

Conway’s Law is an idea from the computer programmer Melvin Conway back in the late 1960s. He stated that “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations”

I think the most obvious example of this is the library website. Your average library website often replicates the org structure and silos exactly.

By changing our org chart, I hope we can change the systems we use to do our work and I hope changing how we work we can also change the structure of the systems we make. Making Systems and Public Services work closer together and be on the same team instead of in conflict will hopefully result in better services for our patrons and faster turnaround on projects.

This presentation is only the tip of the iceberg and I totally don’t have it all figured out. There is so much research and writing on this topic out there, here are some key terms you can use for searching just to start with.

Further Reading:

  • Toyota Production System (“The Toyota Way”)
  • Lean manufacturing
  • Organizational psychology
  • Conway’s Law
  • Agile Software Development with Scrum
  • Just culture
  • Continuous delivery
  • Servant leadership

There are organizations out there that are experimenting with how they’re run and managed. A lot of places, not just libraries, have been forced to look at themselves and ask “What do we need to do to flourish in the next 20 years?”.
I personally think that the answer is to, at least partially, to stop treating our website and systems like they are ancillary to our goals. Our systems and IT are the library. DevOps is one way to start making that happen.

Thank you.

Comment @collingsruth