Hi Reader,

So I was considering those two charts from last week's newsletter (I shrunk 'em a bit since they aren't important right now, just reminders):

...and I realized they answered a question I pointed to back in the first newsletter in this series: "what do we do when we don't know what to do?"

(I also implied this knowledge/skill is an essential part of tech support's job.)

The short answer is, "go deeper."

The middlingly longer answer requires that we take a closer look at that stacked graphic. Here it is again with a tweak:

So I've been in my current gig over seven years now. When an issue gets escalated to me it's already had a bunch of eyes looking at it. Still, having been around longer, I have more platform knowledge than anyone except the most senior engineers.

So the first few questions I ask myself always fit squarely in the topmost box: have I seen this before? Is this how I'd expect the platform to behave? Is there some feature or quirk of the platform I can easily imagine might be causing this behavior? This is where I might search existing documentation or past conversations for clues.

When that line of questioning doesn't get my any results, I've reached an inflection point—an I don't know what to do. So what do I do? Go deeper.

I start asking questions from the next box down: what am I noticing about the issue? Anything unexpected or different from what I've seen before? What possible causes can I imagine? How can I test to see if those are, in fact, contributing? Which of those tests is easiest to do?

If that still doesn't get me anything concrete to give back to the customer, it's another case of me not knowing what to do. Time to go deeper.

The arrow in the graphic above points to "Other-awareness," but it's not just awareness; it's engagement. So at this point I might say something like, "welp, we've run into a new and tricky issue here. I'm going to take this up with engineering to see what we can find out. Here's what we can do in the meantime to mitigate or work around the problem. Thanks for your patience!" Or I might need to do another couple cycles of gathering more information from their end. Whatever the case, it's not strictly troubleshooting anymore—it's also relationship management. I'm gauging how they're feeling and incorporating that information into my responses. Maybe they're cool as a cucumber and I don't need to address the emotions at all. Or maybe I feel the need to say something: "I got that you're frustrated. I promise I'm not going anywhere until we have this resolved."

This almost always works, but there's one more box at the bottom. The last I don't know what to do is when the customer is being that working with you, Michael, doesn't work for me anymore. This pretty much only happens when I've really messed up and lost trust or the customer can't or won't listen. So, go deeper.

I'm not really supposed to escalate things beyond my desk. Having engineering fix a malfunction is one thing. Talking to a VP of the company and saying, "there's a customer I need you to handle" is a completely different thing. It should never happen. AND, when it does, I need to handle that, too, in myself. To realize that I can't control everything, and I make mistakes, and fail, and that's just part of the job. I beat myself up sometimes—at least some light beatings—but for the most part I've gotten pretty good at admitting my fumbles, letting them go, and moving on to whatever's next. This is the work of the bottom box. It's subtle.

One of my teachers says, "subtle means 'you don't get it,'" so I do wonder what I'm still missing here. There must be something. I have a creative theory about what's at the next level below self-awareness. Call it a projection of what's at the bottom of being. But this isn't the newsletter to go into that. I'll include it in one of the newsletters that follows this tech support series.

Ok! So. Next week we'll get into how we teach this. As a teaser, I'll tell you there's bad news and good news, and the good news can also be seen as bad news.

But also, I'm curious: has this explanation opened anything up for you? Maybe there's value in simply describing this to anyone in tech support I aim to teach or coach.