Please Don’t Forget Work Life Balance

scale

 

Fingerpaint, an advertising agency here in Saratoga Springs recently published an article about the idea of work life balance on their company blog – here’s a link.

Given my obsession with The Work, this is something of real interest to me. I’m a huge Fingerpaint fan – their offices are beautiful, their work is lovely, and they are great members of the greater Saratoga Springs community. I can see their office from my perch at Sharatoga even!

I think that Jason and I fundamentally agree – life has to be about more than The Work, and the only way that you’re going to find meaning in your life outside of work alone is by pursuing some kind of balance. He says;

Work hard at work but be smart about it and then leave it there.

and

When you’re done you’re done. Go home. Turn it off.

These sound like the kind of things you’d hear from a man who was a strong proponent of finding a work life balance, right? Someone who really believes in keeping work at work. Interestingly, Jason tells us that we should look instead to abandon the idea of a work life balance;

Because no matter how hard you plan, you will never achieve “balance.” You will always regret not spending enough time with your significant other or your kids, or seeing friends or family members. I believe this is something called human nature.

I think this might be where we split in our thinking. I don’t think living without regret and having a job you love are mutually exclusive, and I think that finding some sort of balance between what you do for a living and what you do that really rings your bell is a huge piece of a fulfilling life. If you’re lucky enough to have a job that also helps fulfill you in non-bill-paying ways, even better.

If your work environment is causing you to miss things you’d rather not miss, important things like family events, things that you will regret? That’s either an unhealthy work environment or you have an unhealthy relationship with it. You should find a solution either way.

Leave work at work, definitely. Live in the moment, absolutely. But don’t think for a moment that you need to accept missing out on things that are important to you* – that’s not accepting a brave new world, that’s holding on to The Old Ways.

I’d recommend keeping an eye on this tenuous balance, and protecting it with vigilance and vigor. This is your only life, after all, and work is just work.

 

* – Kids recitals, not Warped Tour dates. Unless you’re playing in the Warped Tour, then that’s pretty cool actually.

 

Why the Aereo Decision Bites for Tech

Paul, General Counsel at Automattic, with some thoughts on the recent ruling against Aereo. As always, great stuff!

Paul Sieminski's avatarThe Old Fashioned

SCOTUS handed down its long awaited decision in Aereo yesterday, and the result, in favor of the traditional broadcasters, didn’t surprise me.

Still, the logic the majority used to reach its decision was troubling, especially if you’re a young, upstart technology that’s building a new, innovative service. The Court’s opinion completely glossed over Aero’s technology — which was pretty specifically designed to stay within existing copyright law.

“Viewed in terms of Congress’ regulatory objectives, why should any of these technological differences matter?”

This is a lazy line of reasoning, with unfortunate consequences. Especially in an era when the newest, most innovative technologies blur the lines between broacasting, phone calls, TV shows, computers, movies…and give consumers a multiplicity of new choices in the process. Contrary to the court’s opinion, technology matters a great deal. New technologies will always push the envelope of the law, and in some cases intentionally exploit…

View original post 249 more words

Tickets Non-Ownership: New Data!

I am lucky in that I have some seriously smart coworkers – working at Automattic is a constant gut-check; the level of drive, creativity and ability are at a very high level. It would be exhausting if it weren’t so inspiring. We’re all lucky to work somewhere where we’re given time to work on side projects – in fact, some of these side projects take the form of project-based meetups, where a crew of Automatticians travel to a new city, and buckle down to work toward a goal.

I’m secondarily lucky that one of these project meetups came to a close at the end of last month, and some members of my squad came home with some very interesting insights. They had spent a week diving into the mountain of data that we have on feedback from our customers, looking for correlations. What was most closely associated with happy customers? How could we better calibrate ourselves to what makes our customers happy?

Data!
Data!

Admittedly, this is not the cleanest data set: the feedback mechanism leaves something to be desired, and that is certainly on our radar. But, this is the data that we have, and after some validation and cleaning up, they came to a surprising conclusion:

Reported User Happiness was most closely tied to the length of time between our first response, and resolution. 

Why is this surprising? Because it turns out that the amount of time between a customer submitting a support request and when they first hear back from us is does not appear to be not all that impactful: falling around .1 points per day (on a 10-point scale.) That’s only a 1% loss per day.

When a customer has heard back from us, time passing has a much greater negative impact, going from an average of 8.8 after 24 hours to 8.0 in our largest queue. That negative impact is eight times greater than the same amount of wait time between their submission and our first response.

This data indicates to me that the idea of leveling the wait time across all tickets is not the right approach: it assumes a roughly even wait time sensitivity regardless of the ticket’s state. This does not seem to be the case: our customers do not mind a bit of a wait to hear back from us, but once they’ve heard – they want our full attention.

The question remains: how do we move forward with the lessons from April and the implications of this new data?

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.