Aaron's Blog

Tech, tinkering, and occasionally, a banjo tune

support-driven

Thinking Spaces (A Support Driven Challenge Post)

It's week 3 in the Support Driven Writing Challenge, and this week I'm posting about my thinking space. Let's start out by establishing that I'm an introvert. I may be a bit of an extroverted introvert, but an introvert nonetheless. So naturally, being around people, or in social situations does not allow me to think easily. I'll confess that the larger the group of people I'm around, the more taxing it is for me to sort through my thoughts. It's like people are a mental jamming signal for me. Now, this excludes people that I'm very comfortable around. For example, a small group of friends can make sorting out my thoughts easier, as they know me, know how I think, and can assist in the sorting.

For me, there are a couple of situations where thoughts get sorted out. I'll start with the most...unconventional one: the shower.

There's something about a shower that allows me to sort out my thoughts better than any other space. And I guess that there's a bit of proof that a shower certainly lends itself to that sort of thing. It's in the shower that I've realized what I've been doing incorrectly when writing a script or program, had revelations about why some personal relationships work the way they do, and have come up with designs for some shave brushes.

The second space for me to work things out is on the porch. A great example of this is the recent post/video I made of me playing around on the banjo. Porch time usually requires a good pipe, and some bourbon (Basil Hayden is my go to, if you're wondering). There's something magical about using music to work out my thoughts, and the pipe/bourbon certainly don't hurt either.

The last thinking space for me is at a good coffee shop, usually with a friend to talk things out. There's something about having someone else to bounce ideas off of over a cup of coffee that I find refreshing. I remember that I used to do this weekly with my friend and mentor, Mike. We'd meet every Tuesday at Old City Java in Knoxville, Tennessee for mentoring sessions. We'd also bounce ideas off of each other, and I found those times to be the most rewarding when I needed to sort things out, whether it be about family, work, or life in general.

I do want to add an observation here--the importance of being disconnected. I've found that being constantly on a device seems to add to my mental pile of work. There's also some research that lends some validity to this observation. Whenever I'm in any of those thinking spaces (and especially in the shower), I've found that it's crucial to be disconnected...even if I don't do a great job of disconnecting. I've also found that the lack of disconnecting and allowing myself to be bored is a major contributor to getting burnt out. If I'm letting that mental pile of work continue to grow, then I'm not doing anything to get out from under it. There's also a bit of a rant here on being present, learning to switch off, and the value of actually engaging with real live humans here too, but I think I'll save that for another post.

How I Work

A long time ago, in a galaxy far away, I thought I was productive. I used a whiteboard (still do, by the way) for my todo lists, was running a Windows laptop for work, and that worked. When I moved to Texas and started working at Rackspace, things changed...drastically. First, my workload changed, and it changed how I had to approach my workload. I went from a workload that was so full of technical snowflakes (read 'Unique and one-off issues') and remote support (me logging into customers' laptops and desktops), that any sort of automation was useless.

When I started at Rackspace, I found that my workload was largely repeat issues (low disk on a server, same Apache misconfigurations, same user creation specifications). This led to me using quite a few tools that were focused on 1.) accurately and quickly diagnosing, or solving those issues, and 2.) using tools that allowed me to make templated responses (a la TextExpander and/or aText). While I tend to shy away from response templates, a consistent queue of 80-100 tickets and a focus on response times necessitated working quickly, and utilizing tools that allowed me to do so.

That said, I still carry that need and drive to work quickly and efficiently, and my work setup and the software I use (I feel), reflect that need. My setup also enables me to be mobile and pack light (sans the desktop setup), since working remotely is definitely contributing to my former coffee shop rat habits.

So let's get to the good stuff:

Gear and Software

My Gear

  • MacBook Air (early 2015)
  • Custom desktop dual booting Fedora and Windows
  • 2x Dell 2715Q monitors
  • Logitech Z533 desktop sound system

When I'm On the Move

Mac OSX Tools/Sofware

Other Apps

My Workspace

  • Hand-built iron pipe desk (I'll show it off in the week 5 post for the Support Driven writing challenge)
  • ...Starbucks*

Other Tools

So now that those are out of the way, let me get to my favorite tools. The ones that are indispensable.

My Favorite Tools

Favorite OSX Tool Software:

BetterTouchTool: It was either this, or Atom. I know, who knew a text editor could be awesome. Well, it is, and you should totally use it (or SublimeText), if you're not already. But anywho, the real star: BetterTouchTool. I'm a sucker for window snapping. You know, having a split screen? I use this DAILY. Not only does it do window snapping, but it also creates hotkeys/macros for doing snapping, other window positioning preferences, and various and sundry other functions. To be honest, I'm likely underutilizing it, but it's awesome. Go snag it.

Favorite Non-Digital Tool:

Gridit XL Organizer: Let me say, it's not easy having a favorite out of the tools/gear that I have. The Code & Quill notebook almost won out here. But here's why the Gridit wins: It took the chaos that was my backpack, and brought it all into order. It holds all the cables I have (and let's face it, good cable management is next to godliness) and keeps them tangle-free and organized. It's without a doubt the best $15 (at the time) I've spent on gear.

Favorite WebApp:

Brain.fm: Hands down, Brain.fm is worth the subscription for me to stay sane and focus. I don't do music with lyrics when I need to focus--I end up jamming out in the middle of coffee shops and get weird looks. I'm stuck on this one song in the "Intense Focus Mode" that I just end up on a roll every single time I listen to the track. I've used it when I'm relaxing too (e.g., reading a book, or writing this post, for example). I can't get enough of Brain.fm. Not only is the app great, but their support is fantastic, and responsive. Definitely worth the subscription.

As a note, there are some tools that I've tried like Todoist, Evernote, Magpie, and Wunderlist, just to name some of the ones I formerly used. I've found that fore me, they just haven't stuck. Instead, I stick to my Code & Quill notebook for notetaking, and have started using Slack's native 'remind' function for task management (they start off on the whiteboard so i remember them first, and then make their way to Slack). This seems to have streamlined a lot of my task management and has done away with the task/notetaking tool overload that I've found myself in lately.

Well, there you have it! This, ladies and gents, is how I work.

* So Starbucks requires a bit of explanation and defense (as most people who know me well find it a bit appalling that even a mild coffee snob like myself would spend his/her time at a Starbucks). Let me start by saying, I've found that most local coffee shops in SA do one of two things well: amenities or coffee. There's really not a place here that does both well. Most of the local coffee shops focus on the latter, and rightfully so. However, there's a bit of a knock-on effect: there's a ton of people (most of them students, or remote workers like myself) all pounding the poor little consumer-grade wireless network to death. So I have a choice: Great coffee and crap internet, which as most workers know, it's kind of needed to do our jobs, or mediocre coffee and internet comparable to what I have at my house. I opt for the latter, since I tend to do the coffee pretty decently as a former barista.

My Workspace

This post is the last in the Support Driven Writing Challenge series that I've been participating in lately, albeit a bit late. This post is about my workspace.

As a fellow support driven community member and remote worker Chelsea noted, being remote means that I can work from anywhere. In my case, it's mostly true (given that I work third shift). My space has been a place that I intentionally crafted to be a place that would make going from a first shift job to a third shift one tolerable, if not at least somewhat enjoyable.

desk

That's the hoss of a desk that I hand-built. It's iron pipe and stained pine, and all of 300 lbs (trust me, I attempted to lift it myself). I had previously used a Standesk 2200 while I was at Rackspace, but found the prospects of standing all night to be a bit...unpleasant.

I wanted my desk to be something solid, rugged, and something that would hold up to not only normal work, but something that would also function as sort of a work bench when I tinker with electronics. I also wanted it to be something that I could work at all night and not grow too terribly bored at, which is why I added the little terrarium you see in the picture.

The other elements of the desk are as follows:

Overall, I feel that the setup has worked well for working on third shift when I'm not doing work at Starbucks/other coffee shops. The only downside will be when the occassion next strikes us to move...I think I'll use movers for the desk.

It Came From the Night Shift

Whew, I'm catching up on posting for the Support Driven Writing Challenge, and I'm fairly caught up at this point. So this week's post is a 'Day In the Life' of whatever it is you do. Since I'm in my first ever third shift position, this should be interesting!

The Schedule

Before coming to DigitalOcean, I was in a 'normal' 9-5 position. Then, I flipped completely over to 3rd shift when I joined DO. Now I'm working 11pm CDT to 7am CDT. I'll walk you through what my typical day looks like:

  • 14:30-15:00: Wake Up, get ready
  • 15:00-17:00: Head to Starbucks to write, learn, catch up on stuff while people are in the office, maybe run some errands
  • 17:00-17:30: Head home
  • 17:30-20:00: Start cooking dinner, run other errands
  • 20:00-22:00: Take a nap and get ready for my shift
  • 23:00-07:00: Do all the work

That's a quick breakdown of the schedule. But what, you ask, does a Customer Success Engineer actually do?

What it is I say I do at DO

Let me start by explaining my team's mission: [To] forge and foster close relationships with key customers by ensuring their success on our platform. What does that mean practically? Well, there are really three 'hats' that our duties fall into:

  • Account Management
  • Tier 2 Support
  • Solutions engineering/consulting

So on any given night, I can have a mix of tasks that is a random collection of those duties. Right now, there is a pretty heavy leaning to support and account management requests since I work primarily with our APAC customers. Let me give you an idea of how these sorts of things fall into a normal night.

I'll usually come in and give a nod to my colleagues Huck and Jon (depending on the night) on Slack as they're headed out for the evening. I'll also ping our Support team and Cloud Operations team to let them know that I'm in, and to ping me if they need anything. From there, I'll catch up on what's gone on during the day. This usually consists of reviewing what's happened in our Slack channels (we have a general channel, as well as a 'standup' channel for any notable issues that occurred, or that need follow up) and perusing my email. A quick note here: I get TONS of email. I've got everything filtered so that anything that doesn't come in through HelpScout, and isn't a general notification gets pushed to the top of my inbox.

After I've caught up on the day and email, I'll check and see if there's been any movement on any Jira tickets I've opened previously, or if anything is needed from me on them. Nine times out of ten, one of my DayWalker colleagues have addressed the Jira if it's a customer-facing/impacting issue.

From there, the rest of my time is spent responding to support requests and Hatch(our initiative to support startups as they launch) applications. The requests that we get are pretty varied. Most of the time, the requests that come in are that a droplet (our term for a VPS) has become unresponsive, or that the customer can't log into the droplet and need us to boot it into a recovery mode. However, we do get some interesting issues during the night. For example, a customer's MongoDB cluster had an issue that resulted in their metadata getting corrupted, and we had to troubleshoot that. Keep in mind that DigitalOcean is a self-managed platform, which means we don't log into customer droplets. This can make troubleshooting a challenge. It's forced me to get better at thinking through an issue, how I would address it/troubleshoot it, and explaining that process to a customer. We also see issues end up being symptomatic of something larger, and may require the customer to re-architect their infrastructure.

In addition to the customer-initiated support requests, there are also the inevitable issues that arise when dealing with technical gremlins. These tend to manifest themselves in us having to reboot hypervisors (underlying infrastructure that runs customer droplets), and can be for any number of reasons.

Our solution engineering/consulting process is in the process of changing. When I started, each of the Customer Success Engineers at DO were responsible for consulting/engineering requests and calls that came in to our team. Now, our Customer Success team does more of a qualification process to see if a customer would need to have a chat with our Solutions team, who are the ones who take on more of the engineering/architecting sort of work. When I have those sorts of calls scheduled at night, they now tend to fall into the pre-qualification sort of vein where I chat with the customer to see what problem they are currently experiencing, how they have their infrastructure set up, and what their end goal of the re-architecture process is.

When I don't have any requests, or issues to address, it can be a bit lonely/quiet, especially working from home. So I'll fill my time learning what I can via Linux Academy, Udemy, and my ever-growing stack of Oreilly ebooks. When that fails, I'll get up and try and give myself a change of scenery. At 3-4am, this is a bit difficult. I'm not too keen on wandering around in my Cthulu slippers and having our local law enforcement called due to the 'creeper in octopus shoes walking around the neighborhood' (note: this has NOT happened yet, and I aim to keep it that way). So sometimes, I'll go outside and smoke my pipe, or at the kitchen table, or in front of the TV with some anime playing in the background. In the case of last night, a fire at 2am sounded grand, so I made one and worked outside last night.

workFire

I wrap up my shift by doing a brief handoff with our first shift CSE's, greet the wife as she wakes up and heads out to work, and then promptly conk out for the 'night'. I'll be writing a follow up post to this about surviving 3rd shift, since I feel like I could write a small book on it. Stay tuned for more!

Cheers,

Aaron

The Support Stack At Digital Ocean

It's week four of the Support Driven Writing Challenge, and sadly, I'm a bit behind what with the US holiday and the customary food coma. That said, let's get cracking.

The Ubiquitous Ticket Queue

I'll start off by saying that the most common way of supporting our customers at DigitalOcean (from a Customer Success Team standpoint), is via support ticket through our home-grown system. That's where most of our work comes from, be it customer-initiated tickets, or automated tickets. A majority of the time, tickets work decently. But there are some pitfalls, especially when working for a self-managed platform like DigitalOcean. Namely, that the ticket approach can seem impersonal

Email Support

We also use email to support customers working directly with our Customer Success team. This is done via Helpscout, and works fairly well. Emails, while they don't have an SLA attached to them, typically get responded to quite quickly. Emails also tend to not deal so much with in-depth technical issues, and when they do, we usually push that sort of thing to a ticket, so that everything is documented and auditable.

The Not-So-Common Phone Call

At my previous two positions, phone calls were the bread an butter of what I did, especially at Rackspace. I typically was on the phone with a customer walking them through and issue, and troubleshooting an issue on their server while they watched. It was a bit nerve-wracking at times. However, since DigitalOcean doesn't have a support line, the phone support that we typically do tends to be on the more consultative side. For example, my team works with quite a lot of startups who come through our "Hatch" program. Many of the calls that we do are introductory, and I like to think of them as a first date. You know, the "Hi, who are you? What do you do? Here's what I do" sorts of calls. On the rare occasion, we'll hop on the phone with a customer and troubleshoot over the phone.

A View of the Other Side of the House

Just to give an idea of what our front lines teams do, they typically operate off of tickets, but also include social support via Twitter or Facebook. Our support team definitely sees a higher volume of tickets than our Success team, so our ticketing system shines when they're able to address quite a few tickets in a relatively short amount of time.

Some Thoughts

I wasn't around for the choosing of any of the components of our support stack, and it's been interesting to read up from other members of the Support Driven community who have had that opportunity to build theirs out. That said, I've got no opinions really on the platform that's being used to provide support (a la Zendesk, Kayako, Intercom, etc.).

I will say that I have a bit of a love/hate relationship with ticketing systems. For all the benefits they provide, I find ticketing systems to be the least personal out of any support tool. That may be the communication researcher in me speaking, but I think the loss of verbal/nonverbal queues can exacerbate situations in which those sorts of things are necessary. I can tell a customer in a reply that I empathize with them, and that yeah, it's terrible that X happened, but they don't get to see that. Instead, they're forced to infer my tone/meaning in my reply. And no matter how much I try to instill empathy into a response, there will always be a case where that falls short.

Phone support, if done well, can eliminate some of that--namely, the lack of verbal queues. This all goes back to training, though. If a support agent isn't empathetic, and doesn't take the time to put themselves in their customers' shoes, all the phone support in the world won't do any good (I'm looking at you, Comcast & Time Warner). So I think (and perhaps I'll do a post on this in the future) that while a support stack is important, and should be chosen carefully, it's really a collection of tools to accomplish one purpose: supporting a customer. If the tools don't do it well, then they're not worth choosing. Likewise, it's important to have people on your team who know how to use those tools effectively. If you choose a tool that doesn't allow for being able to pick up on verbal/nonverbal queues, the person behind that tool has to know that weakness, and compensate for it.

Well, I've rambled on long enough, and I've got to get cracking on the next post! Stay tuned for a Day in the Life Of a 3rd shift Customer Success Engineer at DigitalOcean.