I mentioned in my last post that part of what practical experience allows for is doing holistic support. I'd like to discuss a bit what "holistic support" means and what that really looks like, and talk a bit more about why it's important.

I studied English language and literature in college, which included a fair bit of rhetoric and philosophy. One of the things that really stuck with me was The Dialogue, a concept introduced by Russian philosopher and Rhetorician Mikhail Bakhtin. The central tenet of the Dialogue is that all literature (indeed all language) is connected, and every word informs and is informed by other words, just as a work of literature informs and is informed by other works of literature.

I have found this holds true for most things that happen in technology as well. To give a support-centric example: A user says their email isn't working. Let's think of why that might be: the computer has no network connectivity; they mistyped a password; etc. These are the sort of immediate, more obvious ones. But it could also be that their local system clock is somehow very out of sync with reality, and certificate checking fails as a result. That last one is pretty esoteric, and there are a lot of steps to get there (But one that I and many others have also experienced in real life!). But troubleshooting something like this takes a holistic view of the systems involved. You have to think about each of the very many moving parts, and how those parts influence each other to effectively troubleshoot it.

But I think this is a beautiful example of the technical dialogue all software systems are in. Software is connected, it influences and is influenced by the other software around it. In the case of this weird email issue, let's look at what all is in dialogue with each other: Since time in the universe is (more or less) fixed, systems must generally agree on what time it is. One way to do that is: NTP servers tell NTP clients what time it is, which set the system time accordingly. The decryption libraries in your email client use this time as part of the algorithms they use to calculate the correct hashes that let your email client know it's connected to a safe server. When these don't agree, the hashes on the server side and the client side don't align. Each of the individual parts has its own meaning and gives you its own piece of information; however, the meaning changes when taken holistically, and you pay attention to the way they influence each other. These are complex, dynamic systems. And to solve problems in these systems effectively, you've got to listen to that dialogue.

In my case, I attribute my history and experience doing literary criticism and analysis across many works of literature to helping build these kinds of holistic thinking skills. And to be very clear: recognizing that things are more than the sum of their parts and tuning into those problems more holistically is a learned skill. You don't have to have gotten an English degree to acquire it. That skill is, though, imperative to thriving as a good support engineer because there's another voice in the dialogue here: the user.

User issues are, of course, sometimes fairly simple and straightforward: I did X, and it resulted in error Y. In the most ideal case, action X repeatedly results in error Y. These, then, follow a pretty direct and simple pattern. But what if the user request is more, well, human? "I did X, and it was slow."

This is a pretty common kind of request and illustrates exactly why a holistic approach is the only way to answer such a question well. To start with, the question is immediately subjective: what is slow? And what is acceptable? Next, there's a whole host of connected information to gather. How did you do X? What does the architecture look like? There's also log information, available system metrics, data definitions, and the list goes on.

All of these individual parts of the system, and the connection points between them, are all in dialogue with each other. And they're also in dialogue with the user, their requirements, and even their feelings.

A good support experience considers all of these things and synthesizes just enough of them to help the user get what they're after. Even, and especially, when they may not know for sure what they're actually after. "Slow" leaves a lot of room for interpretation! So what you have to do is listen to all the voices. Really understand the user's position, gather the technical data, and help them make sense of the noise. Sometimes that means giving them a very clear-cut answer (e.g. You are on dial-up, downloading a photo is going to take a while.). Sometimes that means asking some pertinent questions that lead them in the right direction and they discover the answer on their own (e.g. Q: How does Server A usually communicate with Server B? A: Oh! We recently updated our firewall rules, and that's why they couldn't connect). But in nearly all cases, the difference between good support and bad support is synthesizing all of that information and tackling the problem as a function of the whole system.

Doing that synthesis is an investment. It's time-consuming and difficult. Sometimes it's even frustrating, in the beginning, because it can seem slow, and it's not always clear how some of the data a support engineer may request is relevant. But the end result is a consistently exceptional support experience, which solves the real problems users are having, and gives both sides an opportunity to learn something. Taking our email example again: When the user says "My email is broken," and your answer is "Let's fix your system clock," that can be something of a shock. Certainly fixing their clock isn't what they asked, but it's the right answer to their problem, even if they didn't know to ask.

This is the natural next step of practicing the go and see method I discussed in my last post. First, you observe and learn and practice to pick up on the parts, then you explore them with your users. Granted, it's a big step. In fact, it's a never-ending process of refinement, learning, and getting more and more in tune with the Dialogue as you learn. But it is the goal, and simply striving for that goal will set support engineers and support organizations on the path to giving truly exceptional service.