Tag: automattic

I Gained 55 Colleagues Today

automattic-and-woocommerce

From ma.tt

For years, we’ve been working on democratizing publishing, and today more people have independent sites built on open source software than ever before in the history of the web. Now, we want to make it easy for anyone to sell online independently, without being locked into closed, centralized services — to enable freedom of livelihood along with freedom of expression.

It’s not a new idea: at a WordCamp a few years ago, someone stood up and asked me when we were going to make it as easy to create an online store as we’d made it to create a blog. Everyone applauded; there’s long been demand for better ecommerce functionality, but it’s been outside the scope of what Automattic could do well.

That changes today — drum roll — as WooCommerce joins the Automattic team to make it easier for people to sell online.

I’m excited to meet you, Woofolk! Welcome aboard!

Holacracy, Flat Hierarchy, and You

subtitled; Knowledge Workers are still Workers

14503571405_66490482af_k

I will start by warning you that this is a fairly long piece for this blog, and earnest. You’ll find no animated GIFs beyond.

What I Read to Get Here
I recently read a pair of articles, one about Medium’s internal structure, and one about the new internal structure at Zappos. This is interesting because both of these companies are signing on for a new idea; Holacracy.

I’ll be referring to both of those articles and the Holacracy site and wiki. I’ll try to use quotations liberally so that you don’t have to read those pieces if you don’t want to – I’ll keep them in context, and I won’t try to make the quotes say or mean things that they don’t. Even so, for the full picture, you should read at least the two articles yourself.

Continue reading “Holacracy, Flat Hierarchy, and You”

Five Things I Learned About Live Chat

Computer_keyboard

This last weekend I made the move from our Akismet support team over to Team Hermes, a group of Happiness Engineers who cover live chat (that is, text-based chat support) for our regular paid users (That is, neither VIP nor Business), as well as covering in-app mobile support.

So, I spent my full work day yesterday deep in the live chat mines. Over a work day, I did 45 chats – not terrible for a first day! With only a single day of experience under my belt, here are a few early-stage insights on live chat as a medium of hospitality:

    1. Live Chat is very good at what it is very good at. Live Chat is, so far, good at two things: behaving like a human-powered search bar, answering questions with documentation or blog post recommendations, and debugging complicated problems with multi-step questioning. The trouble is when an operator has multiple chats that cover both flavors.

 

    1. Live Chat requires a different sort of focus than email or forum replies. Replying to an email allows a Happiness Engineer some space to explore and investigate and ensure that the reply is 100% correct as-is, a neatly-tied package that is ready to go. In Chat, there is a lot of uncertainty, and the need to balance multiple chat customers at once means you must be able to not only laser-focus on a single customer, you have to be able to switch between cases quickly with little time for recall.

 

    1. Live Chat requires a different mindset than email replies. Given the short time span between responses, there is no wall of authority in place: if an HE doesn’t know an answer, they have to admit it and then move forward with collaboration, a back-and-forth between the HE and the customer. In an email response, the HE would have time to research and be certain of their authority before replying. I like this ejection of ego from the equation; Live Chat feels much more “Let’s figure this out!” to email’s “Here is a solution.”

 

    1. Live Chat is not ideal for every problem: there were a few cases where I had to ask folks to seek support through other channels. These cases were big browser problems, where we needed full traceroutes to determine the underlying issue, and broad CSS customization, which, while something I _can_ do, would not be to the benefit of the rest of the folks waiting in the Live Chat line. Plus, our CSS Support Forum folks are so darn helpful!

 

    1. Live Chat would be a great tool for proactive, rather than reactive, support. I know that some companies use Chat on their sites as a sales lead generation tool – I think that in the pursuit of hospitality, offering Live Chat in an educational format would be a really outstanding application. Identify members of your team who are especially patient and tend to excel with new customers, and then create a Chat property specifically for the educational area of your site. Having a live human to work with might really change the onboarding process, and would at the very least help to illustrate where folks are getting caught up. In that way, educational Live Chat would serve both our user-facing hospitality needs as well as our hospitality-driven UX improvements by acting as chat-based user testing.

 

Today’s my second day – we’ll see how long the above remains true!

Automattic Lexicon: +t +d

Automattic is a fully distributed company; we all work from where ever we are, any flat surface with access to the internet. This comes with many benefits, as well as some curious downsides, but one of the most interesting things is the way that a fully global, exclusively-online working community interacts socially.

Like any group who spends time on the internet (ie in 2014, most groups) we are exposed to different memes and cultural references, and like any group, we create our own sort of tropes and references and inside jokes. One of these is “+t +d.”

20141102_144227

“+t +d” on the most superficial level is an abbreviation of an abbreviation – you begin with “Totally, Definitely,” which is reduced to save time and increase it’s cool factor, to “Totes Def,” which of course is naturally shortened even further to “+t +d.”

Yes, there are those who see this as an affront against the English language, a further breakdown of the same sort as emoji and text message shorthand. There’s something to that – I can see it both ways. However, I think that looking at this piece of the Automattic Lexicon and seeing it only as a shorthand is missing a bigger piece of the message here.

“+t +d” represents to me not just a quick affirmation, but rather an aspirational view of the way that Automatticians (and I would suggest all remote workers) have to approach The Work. “+t +d” is our version of “Yes, and…” the cornerstone to all great improvisational comedy. It represents a necessary positivity that absolutely needs to be injected into all of our work, and all of our interactions.

Working with people almost exclusively through text means that you have to be generous; you have to read only what’s on the page, and make assumptions only when they are justified and work toward a goal. It’s very easy to slip into negativity and read a message into a sentence that simply isn’t there – but if you maintain a sense of positivity, an ingrained automatic response of “Totally, definitely,” things work. Things flow. Great stuff is created.

Working with distributed teams on cohesive products means that you have to make space for error, and for oversight, and for outright missteps. Your response to these things cannot be defensive or accusatory, but rather “+t +d, what can I do to help?” – “+t +d, how can we fix this?” – pushing for the positive, for the tide that lifts us all rather than the torpedo that sinks.

Rick Steves, reknowned travel author and someone I consider a role model, talks about the need for militant optimism in travel – this resonates with me when I think about The Work. I think that “+t +d” is our militant optimism. It’s not always easy, and I’ve certainly fallen victim to defensiveness and pointing of fingers – but I try to stay positive. We all do. And from that trying, we’re able to work together, from all around the world, to make things that simply did not exist before.

+t +d everybody.

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.