Tag: work

Ticket Non-Ownership: Reflections

After doing some ruminating here as well as the discussion over on UserCentered, I decided to iterate a little on the idea of Ticket Ownership with my squad over at Automattic.

For the month of April, we eschewed  all ownership of our incoming support requests. What does this mean, exactly? Traditionally, our approach is this: the first Happiness Engineer to respond to a customer then replied to that customer each time they supplied more answers or information, until the issue was resolved. This past month, rather than seeing tickets as being owned by an individual, we owned our entire queue of tickets as a team – focusing not on ownership, but rather replying to the tickets strictly in terms of wait time – whichever customer waited the longest got the next reply, regardless of who had interacted with them in the past. Another way to look at this is this: we were evenly distributing the wait time across tickets, which is reminiscent of line balancing, a method of improving capacity use in production settings.

Wonderland_Walker_2
As April came to a close, I spent some time talking with the rest of my squad, seeing how they felt about the whole idea, if they wanted to continue, and what they saw as the upsides and downsides of this sort of non-ownership. Here are the two big advantages that non-ownership offered:

  1. It created an informal peer review: in reading through a support request’s history, you are able to see in very clear terms how other members of the squad approach different problems, as well as getting a first-hand look at their writing style, tone, and use of outside links (both to WordPress.com support documents and other tools).
  2. It allowed the Happiness Engineer team to much more quickly identify bugs when compared to full ticket ownership: this is because we were exposed to a much larger number of conversations per day, thus making patterns in customer reports much easier to spot than a traditional ticket ownership system, where it is much easier to write off a customer’s problem as misuse or misunderstanding rather than as a broader systemic bug. You can imagine if a Happiness Engineer replies to one customer 6 times regarding a potential bug, it will be cognitively less obvious as a problematic pattern than if the same Happiness Engineer replies to 6 customers a single time each.

And the negatives:

  1. Each particular support request felt less personally involved, and less personally invested, and at least from the Happiness side, thus felt less hospitable.
  2. Working on a request that someone else had already replied to felt more time consuming, as the Happiness Engineer had to re-do the legwork of researching the customer’s site, background information, etc.
  3. Highly time sensitive replies are answered at the same pace as other tickets, since the wait time load is evenly distributed.

Moving forward, we’re hoping to find a way to embrace the advantages while removing or reducing the negatives.

P.S. Does this sound fun to you? Does working on a small team providing hospitality to an enormous userbase seem like a worthwhile pursuit? Would you be able to restrain from strangling a Squad Lead who pulled this kind of experimentation on you? Good news – we’re hiring.

 

What We Can Learn From Ten Bullets

Today I filled out a survey for Automattic; it was about how I liked working here, and our company culture, and what I thought about leadership. I’m very curious to see what comes out of it, but after a day’s worth of perseverating on it, I keep returning to Ten Bullets, a sort-of training video by NYC based artist Tom Sachs. Here’s a little blast from the past, a piece I wrote about Ten Bullets and how it applied to working in hospitality – I think much of it still applies, since, after all, what is customer service but hospitality? I’ll put the video in the comments if you’d rather not click through.

My Path to Automattic

This is a story that I’ve told plenty of times, but it seems like there are always more opportunities to give it a fresh coat of paint. Here’s how I ended up working at Automattic, the company behind WordPress.com, as a Happiness Engineer.

(Note, this isn’t about the Trial process, which is also awfully interesting. If you’re curious about that, it’s covered a few places already.)

I was unhappy in my job. Lots of folks find themselves in this situation. I felt underappreciated, underpaid, overworked, the usual list of gripes. I don’t remember when I first started thinking about quitting – I was working in the coffee industry, and it was the only real experience I had to speak of. I had the kind of strange resume most philosophy graduates cobble together – I’d taught logic to community college students, been a community organizer for AmeriCorps, and at the time I was opening cafes and training staff for a small chain of coffee shops.

Sometimes I got to cut a ribbon!

I even cut a ribbon one time!

 At some point, the idea of remote work slipped onto my radar – at first just a blip on the outside edge. I met a few folks who worked remotely, and it was the kind of idea that just stuck in my mind. My wife is a professor, so it occurred to me that a remote job would offer me a more flexible lifestyle, and allow us to do the kind of traveling we’ve always talked about. It was a nice idea, and something that I might pursue someday – but not today, today I’m too busy for all that.

It wasn’t until I was walking to my hotel from a trade show, in Boston MA, that I had an epiphany. I was musing on the idea of working remotely – which should be telling, that at a progressive coffee trade show I was thinking about a whole different career path – when I said to myself, “Well, would I work remotely if it meant I had to kind of hate what I was doing?” and it came to me.

“I kind of hate what I’m doing now.”

There wasn’t anything particularly hateful about the job; it just was a bad fit for me at the time, and I was a bit disappointed to be losing touch with the coffee industry that I cared about so deeply, and it did not look like I had any future in it. The job itself was not the problem – I worked with some lovely folks, and I wish them all the best. It was simply clear to me that it was time for me to start my journey elsewhere.

So I dove in. I told my wife that I’d have a new job, a job working remotely, within two years. My first step was a blog post I’ve since directed many others to – Scott Berkun, “How many companies are 100% distributed?”. I opened every company’s site, found their employment or hiring pages, and started a spreadsheet. Company name, size, job types available. Even then, Automattic stuck out a bit – unorthodox web site, plus, after all, I’d been a WordPress user for years at that point. I added it to the spreadsheet and moved down the line.

9781118660638_cover.indd
Yep, that Scott Berkun

In performing this exercise, it became pretty clear that the vast majority of jobs available to remote hopefuls were tech jobs, specifically developer and designer positions. At that time, the one skill set that was head-and-shoulders above the rest in terms of frequency was Ruby on Rails. So, I picked up a Treehouse subscription and got to learning Ruby – I had no background in code, outside of enough HTML and CSS to style a WordPress theme.

While I was learning Ruby, I went back through the job sites for positions that I might be safe to apply for right away – some kind of project management maybe, or support positions. My reasoning was twofold; if I researched these companies and submitted applications for positions I was a fit for today, it would help me to get to know them a bit better, and refine my search down from “All Distributed Companies” to “Distributed Companies I Want To Work For.” The two companies I submitted applications for at this stage were Automattic and Articulate. Automattic because I fell in love with the fundamental driver of democratic publishing, and Articulate because I still thought of myself as an educator (and still do!).

Articulate did not interview me – but Automattic did. As soon as I received that first email invitation to an interview, everything else went out the window. I became 100% focused on Automattic, on WordPress, and on the upcoming experience. I read everything I could about Matt Mullenweg. I scoured the WordPress.com forums. I read every word of copy that exists on Automattic.com. And some part of it worked; I applied on April 10, 2013 (one year ago, tomorrow!) and started my Trial on June 4, 2013.

I’m still working on learning Ruby.