I told Doc we had arrived at the Holy Moment in debugging — reproducibility. I told him “reproducible” is the programmer’s favorite word. If you can tell me the steps to reproduce the problem, then I can find it and fix it. Until it’s reproducible all I can do is share your frustration.
Dave Winer – Reproducible.
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.
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.”
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.
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.
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.
But the greatest wild card of all in all the data, and the most precious piece of information for any happiness engineer hoping to solve any ticket, is the customer’s own perception of what is wrong. And the gap between what people think is wrong and what is actually wrong can be quite far indeed.
Scott Berkun – The Year Without Pants.
How to Collect Customer Feedback That’s Actually Valuable. A look inside how the team at Intercom collects and synthesizes customer feedback.
If you think of onboarding not as pointing out the weak parts in your interface, but instead as the holistic approach to delivering more value to more signups, then it becomes extremely clear that your onboarding experience must keep pace with the evolution of your product and the evolution of the market it serves.
2014 was a good year for Basecamp support. Noah Lorang recaps what last year looked like for the Basecamp support time. Their median response time astounds me. Pretty impressive work from a relatively small team.
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 form is broken in Safari as you get this big bar over the text field.
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.
Documentation, Support, and Customer Success. Simon writes about how documentation is a psychological band-aid in how it calcifies habits and shifts responsibility.
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.
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.
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.
When in doubt, be human.
Seth Godin – Two purposes of user feedback.