Tag: Automattic

Nicereply Podcast Interview

Craig Stoss and the folks at Nicereply had me on their podcast to talk about how we hire in support at Automattic. The episode’s a nice, focused 20-minute conversation about our hiring approach and philosophy. I’m a big fan of these short, specific podcast conversations; not everything has to be 60+ minutes!

One of our quirkier (yet highly effective!) practices is text interviews, which I wrote about earlier this year. Craig and I talk about that and more. If you’re interested in distributed teams, hiring practices, or any mix of the two, give the episode a listen.

And, of course, Automattic’s actively hiring in all manner of roles.

Asia-Pacific Hiring

One of our big goals at Automattic is to cover support 24/7. Our customers span the globe and we want to always be there for them. Since we’re distributed that means we also seek to hire great people from around the world.

Hiring like that helps us be around 24/7 without necessitating graveyard hours. And right now we’re keen to hire more team members throughout Asia-Pacific.

As part of that Deborah and Pam from our hiring team will be in Australia and New Zealand next week. If you’re interested in Automattic or if you just want to chat about how we handle support you can find them in a few places.

They’ll be in Sydney March 8th and 9th, including at the local WordPress meetup. Then they’ll be in Auckland, NZ from March 10th through 12th, including at the local WordCamp. And finally they’ll be in Melbourne March 13th and 14th where they’re hosting a local event.

And if you’re in Asia-Pacific and reading this, we’re hiring.

Sunrise at Whistler

Berlin

I was in Berlin last week with all of our WooCommerce teams for their meetup. Beyond having a very productive work week I wandered around the city a little bit. View the full gallery →

Sails

Courtyard of our co-working space in Berlin, Germany.

A couple weeks ago I did an interview with Helpshift about customer support and how we wrangle a distributed team at Automattic. They wrote everything up into a nice blog post that was published earlier this week.

Working Remotely and the Virtue of Aggressive Transparency. Simon writes about the value of aggressive transparency in a distributed team. Great structure for thinking about expertise and performance at work.

Status

My co-workers reminded me that yesterday marked 5 years of working at Automattic. It’s a neat milestone as it means I’ve now been at Automattic longer than any school I attended or any previous job I held. Looking forward to the next 5 years.

Scaling support teams

A couple weeks ago I was talking with other customer support folks about pain points in quickly growing a customer support team. Our team at Automattic has grown quickly since 2012, when we had around 16 Happiness Engineers. We hired close to 40 support people in 2013 and over 25 in 2014. Our job posting is always up and our only constraint on hiring is the pace at which we can find the best Happiness Engineers.

In talking through that experience with other customer support people I shared a few lessons from Automattic’s growth. These are just things I’ve found to be true about a high growth support team so your mileage may vary.

Maintain your hiring standards

As you grow you desperately need to maintain the hiring standards which formed your team. This is particularly the case if the impetus for growing your team is exploding support volume, management pressure, or a growing user base. With that pressure you become inclined to compromise on hiring standards in order to achieve faster growth. Those borderline candidates who you’d reject 6 months ago you’ll now think of as, “But we could train them…” While that may be the case every borderline candidate you hire ultimately slows down the team while they wait to catch up. Our hiring motto at Automattic is that a “Maybe” is a “No.”

The 6-month speed bump

When you hire a lot of people over a short span of time you also create a lurking iceberg of expectations. New jobs come with a honeymoon-like period. A new hire clearly wanted to join your company, else why would they have applied, and now that they’ve been hired everything smells like roses…for a while. If you hired 6 people in April that also means you’ll have 6 people coming out of that honeymoon period come the fall. Compound that by hiring 6 people a month for 6 months and, boy, is that iceberg massive! Be aware of this. It’s not to discount valid critiques from those team members, but it does need to be taken in to account. Sometimes this week’s fire is merely 6 people simultaneously hitting a given point in learning what works, over the long run, for their productivity.

Here’s one way that collective 6-month speed bump plays out. When people join their first distributed company they love the seemingly boundless freedom. They love their work, love working from home, love the schedule flexibility and dive in whole hog. Pretty soon, though, they realize that they’ve lost all discipline in setting work aside. They find they let pings interrupt them at all hours. They find themselves working 60-hour weeks. They find that they have no quiet time. When you have many people simultaneously hitting this inflection point it can be expressed as an issue with company expectations or with the team itself. You have to take a step back, though, and realize that this is a growth process everyone goes through. You have to help each person realize that, in part, the problem is one of individual expectations, workflows, and discipline. If instead you restructure the entire team in response to this pain point you ultimately withhold from people a learning experience that helps them build sustainable and healthy individual remote work habits.

Teach systems, not information

If your training focuses on simply teaching the information necessary to do the role then you’re creating a burden of technical support debt you’ll eventually need to repay. The most common way I’ve seen this come up in support teams is new hires consistently asking for a list of who owns what features across product teams. If you’re a small, agile, or continual deployment-driven company this type of list is a wild goose chase of sunk costs. The effort required in maintaining that list is crazy, particularly if your product is fairly involved. Instead, focus on teaching new hires the systems they need to learn in order to discover for themselves who owns what feature. How can they leverage the source code repository? How can they lean on the bug tracker? Do they simply need reassurance that it’s ok to ask? When that systemic knowledge becomes second nature then it frankly doesn’t matter how fast the development side of your company is moving. Your support team will be able to keep up and keep pace with where to report bugs, suggest improvements, and ask for help.

Be wary of past experience

This is similar to being mindful of the honeymoon period. Part of why you’ve hired this team is the strength of their past experiences. However, when people start out they see pain points at your company which were solved problems at their past job. While a fresh perspective is valuable, be wary of someone’s desire to solve an issue using the same process their past job did. Your company is your company. It’s not the same marketplace, culture, tools, people, systems, users, or challenges as any other company. Ultimately you want to be wary of new hire-driven solutions which seek to merely transpose past solutions on to new problems.

Thanks to Erica and Simon for helping me edit and compose these ideas.

A day in the life

Some co-workers at Automattic are taking this week to blog about what a typical day at work looks like. Everyone’s using a shared tag so you can read through all the posts over here.

So far Marcus, Ben, Andrea, Wendy, Erica, and Bryan have all written posts. At the end of her post, Erica sums it up nicely:

It seems surreal, still, and I never imagined myself here, but I’m grateful. All the perks of travel are cool, but what Automattic has really given me is confidence. Here, I’ve done things that I never thought I could do. For my first few months, I was convinced someone made a mistake and would fire me. Three years later, I realize there are no mistakes, my opinion is valuable, and as this company has grown, so has my admiration for my colleagues.

That really mirrors my own experience of the last 4.5 years. If you read through those posts and want a work day like what’s described, we’re hiring.