Category: General

Cheers to the FCC for Supporting Title II to Protect the Open Internet

Paul Sieminski's avatarTransparency Report

WordPress.com aims to democratize publishing – to build the tools that give writers, bloggers, and creators of all sizes a way to get their voices to the world. Today we see that our voices were heard, and that they had a big impact on the future of the internet.

This morning, FCC chairman Tom Wheeler announced his support for strong network neutrality rules, by proposing to reclassify internet service under Title II of the telecommunications act. We applaud Chairman Wheeler for today’s announcement. It’s a historic step, and one that would not have been possible without the support of the millions of internet users – from individual WordPress.com bloggers to the President of the United States – who voiced their support for the open internet for the past several months. At Automattic, we’re proud to have participated in this historic effort, and pledge to continue supporting this important cause…

View original post 18 more words

Ethnographic Fieldguide

From http://picography.co/

I’ve gushed before over Just Enough Research before, Erika Hall’s outstanding primer on UX research and thinking about research in a broader commercial sense, but this morning I came across a hidden gem.

In re-reading Chapter 5, I came across a link that I had missed before, to the Helsinki Design Lab – specifically their Ethnographic Fieldguide, a concise, delightfully Finnish document that outlines a manner of thinking and approaching research from an ethnographic perspective. What does that mean?

Ethnography aims to get under the skin of human behavior, to better understand the world and the specifics of the cultures we live in. The focus of the research can be anything from current cultural tendencies, to changing values, attitudes and norms, or concrete human behavior and its motivations within different situations and contexts.

You can find the Ethnographic Fieldguide, and learn more about the HDL, here.

The most radical, audacious thing to think is that there might be some point to working hard and thinking hard and reading hard and writing hard and trying to be of service.

Mark Vonnegut, Armageddon in Retrospect

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.