There are times that you really have to search to understand whether it is better to stick with something or not. I’m experiencing a workflow break down – what was working well now isn’t – and it creates tension. At what point, in a project or an operational workflow, do you make changes to fix something that is broken?

This particular workflow was developed a few years ago and it has been working pretty well since then. The ideal may be where you can control all parts of the workflow or project scope. But most of our operational workflows involve others:

  • In the acquisitions workflow, a publisher is required to provide content before catalogers can catalog, and a service provider may be hosting the catalog, so you have potential problems at both ends of the workflow
  • Circulation involves someone committing to an obligation to return an item, which they may not (you may consider fines or other penalties as part of the workflow)
  • Reference service relies on publishers to ensure access to databases, as well as technology support to ensure internet access

Workflows With Partners Can Be Richer

One reason we don’t control all elements of every workflow is that we don’t always have the expertise (publisher, technology, researcher) for each step in the workflow. We could exert greater control by having only workflows entirely in our control but the limitations are obvious.

The goal of any workflow is to have something happen in an expected way. In a circulation approach, we lend so that people can research but on the expectation we get our book back. In general, we understand that the workflow may occasionally break down.

Library fines were often used as an incentive or punishment to encourage the return of materials. They may still make sense in a law library, although I doubt it. But I’m glad to see them going at public libraries. It pits collection maintenance against access, and the cost of loss then becomes a decision point.

The workflow I’m struggling with has now broken down. One step of it is handled by a third-party and it has become unreliable. In a normal workflow with a third-party vendor, you might have a service level agreement or other contractual set of expectations that would help. That can help a lot, not only to make sure each party knows what they are supposed to do, but also to give a bit of guidance about when to decide things are permanently broken.

You don’t have this same benefit in every partnership. You may be relying on a government entity to update you (acting like a publisher) or you may use open source software that has no dedicated community support. When you experience a breakdown in the workflow in any of these situations, you need to assess how to regain the ability to reach your workflow’s expected result.

I want to distinguish this from the sunk cost fallacy. In that instance, you may be deciding whether to continue to put resources into something that has not yet shown it can work. I’m mostly thinking about things that do work, until they don’t.

The Workaround

One behavior I’m seeing on this broken workflow is one I’ve seen in project management and other areas. When something breaks down, there is a desire to find a solution so that we can go back to what was working. This desire can manifest itself in a variety of ways but some of them can be unhelpful. In particular, it can be unhelpful if the desire for a solution manifests itself as workarounds to the workflow obstacle.

A workaround can be useful. They embody agency, allowing us to make decisions that perhaps we shouldn’t make or weren’t allowed to make, to reach a result. I often think of equity in the law as a collection of workarounds to achieve just results.

A workaround requires understanding, though. If you’ve ever read fantasy fiction, you know it can be dangerous to stray from the path. When you step off the path, you will encounter unexpected things.

Technology

In my case, the workflow does not require technology. It involves human decision-making and actions. I want to distinguish them because I think technology breakdowns are easier to make decisions about.

One organization I used to work at had very high expectations for their technology working. When it failed, it was usually mission critical, even when it was a user’s personal device. The goal in most cases was to get things repaired as quickly as possible.

But if you’ve ever worked with technology, you realize that it can be a costly endeavor to swap one piece of technology out for another. If your integrated library system stops working, replacing it with a new ILS is a huge endeavor. Even with simple devices, like a mobile device or laptop, you still have configuration and other challenges when you swap out one thing for another.

Each time someone on your IT help desk shows up, then, they’re having to make that call: do I figure out why it’s not working (which may or may not fix it) or do I replace or reinstall (which may or may not fix it). One help desk person I worked with would take hours and hours, because their default approach was always to figure out what wasn’t working.

Unfortunately, with technology, it can often be better to leave the path and not worry why it isn’t working so long as you can get it working again. This is particularly true in a production environment, where people are relying on that technology to work. Why becomes a luxury. You may be able to ascertain why later, but you may also just have hit an anomaly, or something that was unique to that user.

People

Since I come from a technology lens, my tendency was to try to fix things faster and not dwell on the why. But I have had to unlearn that somewhat, sometimes you need to fix what’s broken and understand why it happened. In my experience, these situations tend to involve people.

The most obvious is when you have a new hire, and they miss a step in a workflow because it’s poorly documented or has a step only one person knew and that person is gone. You figure out the why and move forward. You aren’t just going to terminate an employee when a workflow breaks down, or workaround them.

When the person isn’t on your staff or otherwise subject to your control, say, through a contractual requirement, it can be harder. The further they are from you, the more likely you may want to find a workaround and not worry about the why, since it may be unknowable.

Power People

None of this is happening in a vacuum, however. It may be the individual researcher or it may be your CEO, but someone else is probably also interested in you reaching a solution. And they may create an environment which, even when unhealthy or toxic for your staff, is focused on the quick fix. They may not have a shared perspective that the why is necessary.

One mistake people in positions of power make is to only focus on the why when it enables them to lay blame. I had a very difficult conversation with a C-suite leader once who was determined to have heads roll for a significant breakdown. I had not been involved but was brought in to clean up. The reality was that the why was extremely complicated and was the result of many people making (or not) many decisions.

One could have argued that the C-suite was to blame, in that they had created a risk-averse environment that became so complicated as to break down. Blame, at that point, would only assuage egos, not fundamentally improve the existing situation.

As the law library leader, then, your role is to provide a shield against this sort of approach. If your team needs time to figure out the why, take the time if you can. You may need temporary workarounds – people working extra hours, what have you – but sometimes a fast result isn’t better than an understanding.

In the current workflow, I have had to have some difficult discussions with people who want a fast result. They have identified workarounds even (often?) when they don’t have the subject matter expertise to understand how their straying from the path will end. Powerful armchair quarterbacks can be difficult to wrangle.

It has meant a lot of additional research, to essentially rapid test out whether any of these ideas are better or not, and, of course, whether we’d get the same expected result. Because once you adopt the workaround, you are making a commitment to that new process. It may require new training, license fees, additional documentation, and so on.

Fortunately, for the moment, I’ve got time to work out with the third-party what the issue is and how to resolve it. If we can figure out this single obstacle, we can return to the original workflow. A workflow that was working so well no-one noticed it until it broke down.