Rob La Gatta Interview

Interviews

Meet Rob La Gatta, who leads the Quality team at Modern Tribe, where he is responsible for support and the quality assurance process. He has been earning a living using WordPress since 2010 and currently resides in Oakland, California. He can be found on Twitter as @roblagatta.

How did you get involved with WordPress, and what brought you to it?

Funny you ask that… I fell into WordPress by accident and would not be here today but for a spur-of-the-moment decision to quit my old job. 

I’d been working for LexBlog, a Seattle-based company that built Movable Type blogs for law firms, since college and by mid-2010 I was their lead project manager. It was cool and a great learning environment, but I also eventually realized I wanted out of the web and to find myself work that had me building tangible things, using my hands, and interacting with people on a face-to-face basis.

That mindset lasted all of about three months. I spent a summer living like a beach bum on the Jersey Shore (no MTV jokes please), and by the end I was out of money and out of a home. A friend I’d gone to college with in Seattle was now living in New York. He invited me to a World Cup party at his boss’ house; the boss and I hit it off; and I was brought on as a contractor to help build a network of radio station websites…all built on WordPress, a platform that up until this point I’d never even looked at. It sounded fun and I was excited about getting involved in radio again, since it had always been a passion of mine.

I started the job on a Monday and by Wednesday had become familiar enough with WordPress that I felt comfortable explaining the basics to others. By the following week I was training employees at radio stations around the country on how to use it…and I’ve been working in the industry ever since. I joined Modern Tribe as a freelancer in 2011 and became a full-time employee — their first ever — starting May 1.

As Head of Quality & Support at Modern Tribe, what does the average day look like for you, and how do the pieces fit together?

The average day involves a lot of managing. When I started on the team, I was pretty much the entire support/QA crew. But as we’ve grown I’ve been able to build out a team under me, which means there’s less “in the weeds” work and a lot more answering questions from the support & QA teams; checking on whether we’re collectively on track to hit due dates; and generally making sure the community is “at peace.” By which I mean, none of our users are visibly agitated or risk turning against us because of some failure on our end. There’s a fair degree of marketing too: blog posts, user profiling and the like.

Ultimately I’m accountable for making sure we’re keeping people happy and keeping the development cycle going, releasing products that are as close to bug-free and under-budget as humanly possible.

Would you advocate for combining QA and support, and if so, where are other folks going wrong by keeping them distinct?

I don’t see any reason to keep QA and support separate. This could warrant an article in and of itself, but ultimately there is just too much that can go wrong by keeping what I call “pre-launch quality” (QA) and “post-launch quality” (support) in separate silos. Your support crew has the best feel for the pulse of the community: What users want, what they don’t care about, where their pain points are and where they’re struggling. An independent quality team might come to the table with a better understanding of what makes good QA, but really, with the right people that can be trained with  ease.

“But what if I’ve got enough budget that I can afford them both,” you might be asking? It doesn’t matter, I would say to you, and this is not a budgeting concern. It’s a matter of making sure the people who are dealing with the users on a daily basis have both an understanding of how the code works and a fluid knowledge of what’s changed or been fixed from release to release.

Let’s say I’m a support technician and I’ve got a forum post from a user complaining about a broken widget. If I’m not doing QA, I’d simply log that as a ticket and wait for word to come down from the devs/QA team that it was ready for release in an upcoming version. But I wouldn’t be able to answer questions on how specifically the new code works, or what it’s going to look like, or anything beyond “it’s fixed and should be released soon.” That’s a fail.

Imagine that same situation if the support technician were also responsible for seeing that ticket through to completion: Testing the finished code in a number of scenarios and themselves deciding that it was ready for release. Not only would they feel they had a stake in the matter, and knew they were the face of accountability to the user…they’d also be able to paint a comprehensive picture of the fix-in-question and how it played into the broader roadmap. 

Whether you believe it or not, users can pick up on when you’re bullshitting. They are far less likely to come away feeling positive about the experience or likely to recommend your solution to others, if they felt they just got played or treated like a fool.

You have a lot of experience in project management. What’s the most important factor of all in keeping a project on track?

It’ll sound like a cliché, but clear communication is hands down the big one. Everyone involved can be awesome at what they do, but if you aren’t communicating early & often, then at the very least you’re going to make life harder on yourselves until the project is done (and at worst could kill the project and cost you thousands of dollars along the way). That’s why I place such a high value on strong communication skills whenever I’m interviewing anyone for a project.

By clearly communicating deliverables so people know who is accountable and when, and meeting at least once a week for most projects to answer a few basic questions (What roadblocks are you facing? Who do you need a meeting with before you can proceed?), you can do wonders for your project.

From a communication point of view, how is managing the needs and problems of developers and the needs and problems of users most different, and most the same?

It can be a challenge at times. I’ve found — and this is obviously a broad generalization — that most “regular” users can be appeased easier than developers, only because there is usually a code snippet or workaround we can provide that more or less accomplishes their end goal. Developers usually want to get deep into the plugin and extend its use…usually in really awesome ways, but not always in ways that we can support.

That said, this too can be avoided by  strategically picking your team. I can say with certainty that I’m not a developer or even dev-minded; so there’s a limit to how much I can help a developer who comes through with a technical question. But I’ve offset that — and have given the developers in our user base a “friend” they can rely on in doing so — by keeping one or two “light devs” working the forums on a daily basis as well. These guys can hack at code and modify templates and generally know what they’re doing, enough that they can head off about two thirds of the dev-minded support threads that cross our plate. For the last third, we do make our core developers available to help as-needed on an ongoing basis.

What separates run-of-the-mill support from tell-all-your-friends support?

The enthusiasm with which it’s given. 🙂 Look, the goal with support isn’t to solve every problem 100% of the time. That’s an unreasonable goal and you’re setting yourself up for failure if you approach support from this perspective. You’d bankrupt yourself, you’d take too long to respond to new threads and you wouldn’t get anything else done.

What’s important instead is understanding how you can let people down in a way that still leaves them feeling good and thanking you. Support is about showing people you care about them, and that you want them to succeed. You can show evidence of both without necessarily fixing their specific problem.

At the end of the day, it’s a matter of treating others as you want to be treated. Put yourself in the position of this user. I reread every single reply I write to a user before I post it, thinking with the mindset of, “How would I feel if I got this response?”. It may tack a bit of extra time onto your forum rounds, but man does it help leave a lasting impression.

If you’re already providing awesome support, how do you justify or “up-sell” hardcore users to premium support?

We actually don’t provide purely premium support. I know there are shops that do that, and it works for them, but to me that’s a slippery slope. I don’t believe one customer is worth more than another just because they’ve paid you some extra money…a CEO or CTO might think this way, but it’s dangerous for a support team to get in that mindset because it keeps you from providing the same level of awesome support to everyone.

Instead, in our case, we justify the upsell by including additional features in the premium build of our events calendar. Yes, the level of support we provide is generally deeper for these paying users than for non-paying users, but they’ve also got a bigger code base with more features and more considerations to work with. 

If you’re running a small or even one-man outfit, are there any hacks or preemptive strikes you can make to lessen the load in terms of time consuming one-on-one support? And more importantly, should you?

Great question. When I started doing support for Modern Tribe, I was pretty much a one-man outfit as you’ve described here. And as use of the plugin grew I found more and more of my time each day dominated by support. And I love support, naturally, but I’ll also be the first to tell you that if you spend all day focused on it, you’re going to get burned out quickly and that’s going to lower the quality of any help you provide going forward. 

There are both technologies and organizational systems that can help you here. On a more practical level, we recently started using HelpScout for our email support and as a time-saving tool it’s amazing. A small outfit can benefit from an organized email tool like this and the fact that it saves customer records and “stock” emails that still come across as extremely personalized. We’re now looking for a similar solution to use at our forums.

From a higher level, be strategic with what docs/tutorials/FAQs you prepare. If an issue comes up more than twice, it probably warrants documentation of some kind so that when it comes up again, you’ve got a link handy rather than having to reinvent the wheel. The amount of time this saves cannot be understated, and it actually kills two birds with one stone by showing prospective customers what an impressive, ever-growing body of resources you’ve made available.

What happens when support melts down and you have an irate user on your hands?

If you don’t look at each and every support meltdown as a learning experience that will help your team grow, you’re doing it wrong. In some ways irate users are a great problem to have: they force you to address a problem on-the-spot, rather than punt it down the road to a later date that never comes, and more importantly they give you an opportunity to see where you’re failing your users.

There are of course varying degrees of legitimacy to user meltdowns. Sometimes I’ll see one that I find laughably overdramatic or talking trash about a problem that doesn’t exist. But it’s still important to treat each of these people with the same level of respect you’d show your grandmother. Always remain polite. Even if the user is being rude…”kill them with kindness.” If nothing else they’ll feel bad about it once they’ve calmed down. 

Beyond that, a couple tricks I’ve employed that help with this:

• Don’t be afraid to escalate problems. Users get stoked when they see a support request that they perceived as being handled poorly escalated to the next level within the organization, and it usually calms them down just to have a new person to engage with.
• Offer refunds. Even if you have an official policy against it, consider the amount of time and money you’ve spent supporting this person already. Would it be easier to just give them a refund and recommend a competitor? If so, do it with a smile and move on.

One thing we won’t tolerate, though, is people being mean to the support staff. My skin is as thick as the next guy’s, but there’s a difference between getting angry about a problem and just being a jerk. This rarely happens…but when it does I have no problem firing a customer if they don’t treat my crew right. Nobody deserves to be treated unprofessionally when they’re just trying to do their job. And this is WordPress, not rocket science or planning a drone strike, so the stakes aren’t as high as some customers might have you believe.

As well as being Head of Quality and Support at Modern Tribe, you’re also a self-described “Burger Stooge.” Talk to us about the difference between working in digital space and *pun alert* meatspace, and how the two complement one another.

The reason I started working on the burger truck was because I needed that exact balance you describe here, between the digital space and “real life.” But there’s no question that the support experience for one complemented the other, and in each case I’ve learned a bunch of stuff I could take back and apply across the board.

A lot of those we’ve actually covered in this interview…service with a smile, the “golden rule” of treating others as you’d like to be treated, not being afraid to give a refund or remake that burger if the customer isn’t happy. All these things are equally important both offline and online, and it’s one of the reasons I get frustrated with businesses that feel they’re absolved of providing good support because they’re online providing a digital product.

Good service is good service. Period. Just because you aren’t taking to a customer face-to-face doesn’t mean they’re any less present. Online or offline, you’re an ambassador of the company you represent. Both your reputation and the company’s are at stake, so why not go that extra mile to do it right?