Reading Time: 4 minutes
I’m a satisficer, an embracer of the good-enough-for-now. I do not know when that started but it’s certainly a perspective I feel that I’ve had for most of my career. It may stem from being someone who works with technology which often breaks without an obvious cause. You can spend time trying to understand the root issue but as often as not you are chasing a one-time event. I do remember distinctly that this approach crystallized when I worked at the ABA and had temporary responsibility for its IT systems and teams. It was clear that we could spend time wondering about blame or we could focus on repairing and moving forward.
Anyone who has seen my home-cut hair will know, I’m not a perfectionist. I believe in the “good enough” (especially when it comes to research). I guess I don’t really believe perfection exists, even when I find music or nature or other creations to be beautiful or awe-creating. I think it’s because that suggests an endpoint, a destination beyond which nothing can be improved. For me, that sort of endpoint begs the question: then what?
I was reflecting on this approach as I was repairing a computer recently. It had stopped accessing certain websites. Other computers on the same network could reach those sites and even the impacted computer could reach most sites. So what had happened?
A couple of hours of patching later and no change. Then I tried a couple of other ideas. None of them were certain and, with the advent of AI-infused search, I didn’t find much in the way of strong StackExchange or other posts that seemed to have the same experience. I was really just going on hunches and expertise borne of past experience.
As a rule, patching and updates are a great place to start when you’re not sure why a hardware or software technology is failing. For one thing, you at least know you’re dealing with the latest version of an operating system or software application; if something was broken and has been fixed, you get the benefit of that. For another, updating often requires a clearing of cached information or a clean restart. People joke about restarting one’s device to fix a problem but, so often, that really is all it takes: a clean slate.
In the end, I was able to diagnose the problem and fix it. For whatever reason, the websites were unresponsive across the internet; I couldn’t reach them in the web browser or at the network level (ping). When I turned off IPv6 support on the device—a step I took only because I hadn’t tried it yet—so that the device could only connect using IPv4, both sites became accessible.
Problem solved. As with so many small technology projects, you make a mental note and you move on. It is most important, usually, to return the device to operation as rapidly as possible and so success is measured by that, and not by knowing why. If and when this occurs again, I can call on my memory to try this option first rather than last. Over time, you accumulate bits of information and can slowly aggregate them, as needed, into a whole. Also, I will now need to remember that this device is configured a bit differently and that that difference could itself cause problems.
At this point, one might ask why it happened. I don’t really know. With technology, the solution usually comes without enough information to know. Frankly, it can take more time to answer the question of “why” than to just solve. More importantly, how does knowing why help?
The Lure of an Answer
I don’t think you can be a successful librarian without being curious so I want to be clear: I am not suggesting that you dampen your curiosity. I do want to know why things happen. I just don’t think that searching for the why each time a problem arises is always a good use of resources. This may be borne of being someone who does a lot of technology-related tinkering and exploring. So often, the issue repeats but the context is unique. The problem, perhaps caused by a user’s actions on a specific system with a specific configuration, is a one-time challenge. That user may be on a remote server, doing things out of sight. If the problem presents itself a second time, it may not be caused by the same set of parameters.
When I was at the American Bar Association, we had had a huge spending overrun and a bit of a blood-letting at the top of the organization: the CIO, the CFO, and others were separated. I spent about 6 months there as an acting CIO (that wasn’t the title but that was the job) in addition to my primary job and some of that period was, unsurprisingly, bumpy. At one point, some technology failed and I ended up investigating it and having to sit down with the COO at the time to give a report.
This article popped up as I was writing this post and discusses how artificial intelligence inhibits curiosity. I think most successful librarians are already curious but I liked how this identified ways to regain that curiosity to the extent it has been dulled or submerged. It seems like a good list to use if you end up managing someone who isn’t naturally curious.
The thing I remember most distinctly was my sense that the meeting seemed focused on finding out who was to blame. By this time, the repercussions had been experienced and the team was moving forward; to the extent we could determine how to avoid a repetition, we had already done so.
I deflected a bit because I didn’t think responsibility was clear. It had involved servers and outages and sometimes thing happen. It might have been a performance issue. It could also have been a process issue. I have never understood the point in punishing staff for doing what they were asked to do. In this case, it was at best someone making an implementation mistake or a poorly designed process or, most likely, an overly complicated set of connected systems that were begging to fail. If anything, it suggested that the complexity had outstripped the ability of the team to manage it.
It’s funny how some experiences can have outsized impact. That short period at the ABA was one of them. It has been really useful because it made me hyper aware of over-engineered processes, especially when they involve technology. I frequently prod at processes to see if they can be simplified or made more resilient.
More importantly, though, I didn’t see the point. What was ascribing blame going to do to mitigate the impact of what had happened? As a manager, you can anticipate some of the possible outcomes. It would make staff worried about their jobs. It would create anxiety and stress. It would diminish learning and engagement.
If there is a performance issue, you work with the person involved and you fix it for the future. In that particular case, I felt like the responsibility and accountability weren’t aligned. Someone was made responsible for an environment for which they weren’t also given autonomy and ownership. We could fix that in the future; dwelling on the past wasn’t going to help.
If something has gone wrong, you should absolutely try to understand what broke so that you can fix it in the future. Post mortems are great for that on larger projects and even an informal debrief is good for smaller ones. But avoiding breakage is different from trying to always understand why the breakage occurred.
As it so often does, it is a question of resources. I managed someone many years ago who really struggled with this. They would worry at a problem to try to understand it. In the ideal world, that’s possible. When you are delivering a service, you need to prioritize getting the service right. Sometimes the best you can do is accumulate knowledge as you go, putting the pieces together as you come upon them. You could spend hours trying to understand what happened but that’s often a cost that you can defer.