Category Archives: Blog

On certainty in support

People turn to customer support for help, expertise, and reassurance. However, in my experience customer support teams too often respond with uncertainty.

I find a core cause of this to be one particular way of phrasing written replies. It stems from how we try to make replies conversational and relatable. We throw around words like “should” or “looks like” without understanding what they convey to someone confused and frustrated with your product.

In certain cases users have to rely on Happiness Engineers to manually transfer their blog to another account. A couple years ago I found we frequently wrote back to those customers to say, “That blog should now be under your other account.” Should. If you are on the receiving end of that sentence your first question could rightly be, “Well is it?!”

It takes one step and one word change to improve that. First, trust that you did things correctly but verify to be sure. Second, rewrite the above example to, “That blog is now under your other account.” Simple, yes, but a much greater sense of certainty.

In support we are frequently the ones making a change behind the scenes. In some cases we manually fix something vexing the user. In others we let someone know we fixed an earlier bug. In all cases we should be certain in our language. Certainty and expertise is what builds trust.

If you write a support reply and find yourself unsure of something, do the work necessary to be sure everything is working properly. The extra time will build trust with the user by removing doubt. Removing doubt and illustrating that someone can trust you as an expert is one surefire way end up with happier users.

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.

Verizon Live Chat

I shared this on Twitter earlier but wanted to log visually here. Verizon’s live chat support has three shockingly poor things wrong with it.

The text is large, blue, and Comic Sans.
The text is large, blue, and Comic Sans.
The form is broken in Safari as you get this big bar over the text field.
The form is broken in Safari as you get this big bar over the text field.
The tab title is "Engagement Window." Eww.
The tab title is “Engagement Window.” Eww.

I reported each issue to them, of course. Unfortunately they said, “we do have issues with the Safari browser” and suggested I use Internet Explorer.

People will read

Last July Ryan Pitts and Sara Schnadt led a session at SRCCON about human-driven design. It wrapped up with a discussion of various maxims that guide design processes. Someone in the room said it was important to remember that, “users won’t read, ever.” That rubbed me the wrong way at the time and I went on a mini-rant in the session. I was thinking back to this recently and wanted to sketch the idea out into a longer post.

The perception that people don’t, and won’t, read documentation is not uncommon. There’s a reason we have the acronym RTFM after all. I think it’s a perception that’s horribly misguided and short-sighted for your product.

People will read. What they won’t do is unquestioningly read on your terms.

Treat docs as product

When you’re developing a product you don’t ship something and passively wait around for it to become popular. If what you shipped isn’t gaining traction you iterate. You tweak and adjust until your product fits its addressable market.

For some reason we don’t approach documentation with the same mindset. Our predominant expectation is that we can ship docs and expect every person to read them. If the docs have up-to-date screenshots, are detailed, and are searchable then that’s enough. If people don’t read, that’s their fault not yours. That’s a fundamentally broken expectation.

Most importantly, if you react to support requests by wondering why people can’t read the docs then you are missing a golden opportunity. You are directly blaming the person using your product instead of blaming your product for requiring documentation in the first place.

Exploratory & Prompt-Driven Users

Part of the RTFM-mindset stems from an assumption that everyone is an exploratory learner. That’s wrong. It’s arguably true for many tech folks. That doesn’t make it true for many people using our products.

Exploratory people will find their own way. They are comfortable with uncertainty. They’ll use a confusing product and feel confident relying upon documentation for answers. To them this is part of the appeal. Each awkward setting or obtuse workflow is an opportunity to master the intricacies of yet another product.

Prompt-driven people will read docs, but it’s not their default. They will first look to your support team for help. You could also think of them as human-reliant people. Interactions with your support team may prompt them to read and reference docs. So it’s not that they won’t read. It’s more that they prefer human interactions to help guide them.

Here’s the thing about prompt-driven people: they are a potential gold mine of qualitative feedback. There is no better source of information to help guide your product teams. Yes, this means your support team has more tickets to respond to in the short-term. That’s a great thing.

Every one of those interactions is an opportunity to learn more about how people use your product. If you choose not to take advantage of that and instead blame people for not reading your docs and leaving you alone in your cave, then that’s your loss. The next time you find yourself blaming a customer for overlooking the “obvious” answer in your docs, ask yourself whether you’re reading enough of what they’re telling you. More often than not I think it’s those building a product that don’t read, not our customers.

Thanks to Simon for helping clarify some of the wording in this post.

The software I use

While answering some “What do you use for…” questions the other night Daniel suggested I write up a recap of what tools I use. He wrote something similar a few days back and it was interesting to read through.

During the day I’m helping organize and lead our various support teams at Automattic so the bulk of my time is spent writing, talking with people, and helping out with projects that come up. All of that requires pretty simple and lightweight tools.

My day-to-day communication all happens through two tools. Much of it happens through various P2s which we have setup for every team, major project, and area of interest within the company. If you’re not familiar with P2s Matt wrote a bit about how we use them. Or, go pick up a copy of Scott’s book. All of our chat then happens through Slack, which we use for both 1-1 and group text chats. There are stats built-in so I know I’ve sent just over 35,000 messages since we started using it about 5 months ago.

The upside to P2 as a core tool for me is that I’m in control of how I follow and receive updates. I follow about 50 internal sites and use email to keep up with posts and comments. Everything is routed in to 3 separate folders that group posts and comments by relative priority. For all this email I use It’s the only mail client that’s ever felt “right” to me. I can’t stand Gmail on the web and get distracted by having email in my browser.

Safari is my primary browser. I had used Firefox for ages but with the release of Yosemite I’ve gone back to Safari. It’s really clean and performance-wise I don’t notice any difference. Plus, the only browser extension I rely upon is 1Password.

Like Daniel I’m a huge fan of Bartender. It keeps things so much more sane up in the menu bar. Up there I have a few things running:

I use Things to keep everything organized. For the last 6 months or so I was using Omnifocus. Along with the Yosemite upgrade I took a chance to re-evaluate my tools and decided Things just fit better for my usage. I’ve used it ever since the initial beta tests and have always found it fits my mental model of tasks pretty naturally.

Outside of tasks I use the native to stay scheduled. iCloud syncs everything over to my phone. For notes I use Simplenote for some things and FoldingText for others.

When I do need to code I use Coda. Any coding is just for personal projects and I find using Coda means I have just one tool to remember. It’s not for everyone but it works wonderfully for me.

Divvy is always running in the background, helping me keep windows organized and arranged. There’s something pleasing about having windows set to a grid.

I make sure to do some direct customer support once a week, too. I usually set aside one afternoon for that. It’s always done with our live chat team, which uses Olark. They’re good folks and the web-based chat client is pretty slick.

In terms of hardware I’m using a mid-2014 MacBook Pro, with the retina display of course. Spec-wise it’s got 16 GB of RAM and a 256 GB SSD. Performance-wise it’s more than I need most of the time, but I like using machines for quite a while. My last machine, an 11″ MacBook Air, lasted 3.5 years. I went with the 13″ model because the weight is pretty darn minimal. It’s the only screen I use, too. I stopped using my Cinema Display after upgrading to this laptop. The biggest benefit here is that my home setup is identical to my travel setup in every way. Consistency is nice.

This all makes me think I should do a mobile-specific version of this post, too. Perhaps later.

The Old Guard

The Old Guard is the cultural bellwether of the company. I believe that culture is a slippery thing to fully define, but I do believe it is the responsibility of the Old Guard to not only take the time to define the key values that are the pillars of that culture, to communicate the nuance of those values over and over again, and, lastly, when it becomes apparent they are no longer serving the company, they must be willing to let those values evolve.

Rands writing about The Old Guard.

A simpler Twitter

A long time ago I used Craig Mod’s Twitter for Minimalists. It was nice. Using that in a instance gave me the benefits of Twitter’s web application without the distraction of having it in my primary browser.

Craig’s recent tweet about modifying the notifications panel put it back in my mind.

I find the Twitter website to include some key pieces that third-party apps lack. I enjoy seeing favorites and other activity that’s only available through the web interface. The downside is that I dislike the habit of opening it in my primary browser; I prefer distractions that take more deliberate action to open. So I threw together some basic styles and now have this running:


It helps me build a small, digital habit field around using Twitter. If you want to set up something similar here’s a Gist of the CSS I’m using. Using that in will require the paid version, but it’s just $4.99. I also found this handy replacement icon that looks nice in my dock.

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.