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?

How did you first get involved with WordPress, and what brought it into your life?

So I had been dabbling with open source platforms in high school around 2006. Mostly WordPress, and a few others I can’t bear to mention. Although I didn’t really get involved with WordPress until early 2009, while studying Computer Science at Rutgers University, when I had taken an entry level programming job for an ad I found on Craigslist.

The job description wasn’t WordPress specific but mentioned open source solutions which was something I was interested in. Within a week of applying, I interviewed with Brad Williams, CEO and Co-Founder of WebDevStudios, and got the job as their first developer hire.

From that moment on my WordPress career was kicked into overdrive. At WebDevStudios, not only was I involved with building really cool things for clients with WordPress, I was releasing plugins on the WP.org plugin respository and heavily involved with the WP community both helping out with meetups in the area and attending various WordCamps. I actually attended seven WordCamps across the country from 2009 and 2010: Mid Atlantic ’09, Chicago ’09, New York ’09, Boston ’10, Miami ’10, San Francisco ’10, and New York ’10.

These first two years have definitely shaped who I am today. I learned a lot in a short period of time and made a lot of really good friends along the way.

You’ve worked as a developer with WebDevStudios and more recently (up to the present) as a Support Ninja at WooThemes. What did the one bring to the other, and how are they most different?

I actually wrote a blog post around this over at WP Realm titled What Makes a Great WordPress Support Specialist.

In the article I write about my previous experience as a developer and involvement in the WordPress community was a huge benefit to my transition into the support world:

“…having a technical background and general knowledge of WordPress coding standards and best practices is a HUGE win. This has really helped me. With a stronger background in WordPress development and involvement in the community, I’m able to not only provide knowledgeable answers but am confident that they are up to par with WordPress coding standards. In other words, done the right way.”

With that said, being strictly support I feel that I’ve fallen out of the loop a bit and am looking for ways to stay involved and keep my WordPress and coding skills fresh and up to date. That’s something I’d never want to let go and am currently involved with developing a few plugins and projects on the side.

At WooThemes you’re a Support Ninja. What interested you most about taking on the job, how have you made it your own, and what’s surprised you most about what it entails?

Short answer is that I’m passionate about helping people and love WordPress so it’s a perfect fit.

While working at WebDevStudios we had Support & Maintenance packages for clients which I also managed alongside client development. It wasn’t really the same thing as what I’m currently doing at WooThemes but I learned that I enjoyed helping users with WordPress and when I saw the opening at WooThemes I knew it was the job for me.

As of April 1, I’ve been at WooThemes officially for a year supporting our customers. I think that’s what surprises me the most. Not because I’d expect to be somewhere else but because I still love what I do.

Most people may view support as a boring, tedious, repetitive task but I’ve learned to really enjoy it. Each and every day has it’s new challenges and obstacles for me to take on. Not only am I solving problems and pointing people in the right direction, I’m also learning things on the way so it’s really a win win. Most of all, I strive to deliver happiness. Who doesn’t love that?

I actually gave a talk about this earlier this year at WordCamp Norway titled Help Yourself by Helping Others, which you can find on WordPress tv. If you can deliver happiness in every aspect of your support you’ll only benefit and this is something we try to do at WooThemes.

You work remotely for WooThemes from Norway. What tips would you give newbs to the whole work-from-home thing, and what do you wish you’d known when you first started working remotely?

My biggest advice to those who are new to working remotely would be to make a work schedule and try stick to it. If you aren’t strict to this you’ll easily find yourself working all the time so try to have a healthy work-life balance. This also ties into what I would have liked to have known when I first started working remotely. I’ve just started to find a nice balance.

Also, I definitely miss the social aspect of working in an office but yearly trips where you can meet your colleagues, like our annual WooTrip. Also, meetups and WordCamps in the WP community definitely make up for it. It’s definitely not for everyone but I wouldn’t trade it for anything. Not everyone can work from home, the local coffee shop, or even from an airplane which I’ve now done a few times. Incredible!

At what point does a WP outfit need a dedicated support person (or people), and what can bootstrappers just getting started do to make their support at least as good as it can be in the meantime?

Right away. Support is easily the most important aspect of your business, even if you are just starting out. You obviously need to have a product or service, but definitely don’t overlook support or throw it under the bus.

Again, don’t just do customer service or support, focus on serving happiness to your users/customers and you’ll be doing things right.

Conversely, where do you see people going wrong with customer service, and what are the consequences of that?

The biggest issue I see is people have a wrong view around support. I bet most people even cringe when they hear the word. Will you have horrible experiences and miserable clients? Of course, but let it go and focus on the users and customers who actually appreciate your help.

Here’s a quote from Mark Forrester, WooThemes co-founder, that really hits the nail on the head: “Customer support is the opportunity to convert a disgruntled customer into a loyal product evangelist by over-delivering and creating a memorable human connection with a digital brand.”

Remember, support isn’t a bad thing or a headache for your company. It should always be viewed as an opportunity to benefit.

You’re also the author of some awesome plugins. Which are you proudest of, and what itch were you trying to scratch with it?

I’m definitely most proud of CollabPress. A plugin I released in January of 2010 which, at the time, was BaseCamp on WordPress. There was a need for a project management plugin in the WP community and I decided to make something. We used it at WebDevStudios internally and a few others were as well. I think most successful plugins are those you can both use and benefit from yourself and release to the public as well. Open source, it’s a beautiful thing.

Although I can’t take all the credit. CollabPress 1.0 was a complete rewrite, once custom post types were introduced in WordPress, and Brad Williams, Boone, Eric Andrew Lewis and Christopher Cochran have put a lot of hard work into it as well.

Eric is actually the lead for v1.3, which released last week, and it’s a complete UI overhaul. I love the project and look forward to it’s bright future. You should definitely check it out.

Which three essential plugins would you recommend to WordPress designers and developers up against deadlines, but trying to ensure that their client’s site doesn’t get borked within a few weeks of installing them?

Tough question!

With WordPress being used for so many different types of sites even picking three plugins is difficult these days. Here’s three, you’ve definitely heard of and are most likely already using, I’d use on almost every setup:

1. Jetpack — While I usually turn most of the features I don’t need off, Jetpack has a few great tools out of the box like stats, short URLs, easy embed, etc. I love it.
2. W3 Total Cache — Site speed and performance optimization is a must these days. W3 Total Cache is a great caching tool for your WordPress site. Speed up those load times!
3. WordPress SEO — I’m not an SEO guy, never have been and probably never will be, but it’s important for the success of your site and WordPress SEO does a great job optimizing your site to best SEO practices with WordPress.

What would you say are the three most important skills or characteristics of a kick-ass world-level support person?

A kick-ass world-level WordPress support specialist needs to:

1. Not only passionate about WordPress but also involved in the community and loves to give back wherever he/she can.
2. Be a “people person”, i.e., friendly and easy to communicate with and who can help even the most un-grateful person with a smile.
3. Have some sort of technical background & skills whether it be HTML/CSS, JS, and/or PHP. Knowledge of WordPress coding standards and best practices is a HUGE win.

from http://wprealm.com/blog/what-makes-a-great-wordpress-support-specialist/.

Last up, how important has your involvement in the WordPress community been to you and your career so far? How would you convince someone up against deadlines that giving something back to the community is worth their time?

It’s been everything and still is. WordPress is truly an amazing platform, it’s the best. But, I don’t believe the success of WordPress is directly related to the product itself. It’s the community that separates it from the rest.

Just last week I had the privilege of organizing an online WordPress event called WordSesh. WordSesh was 24 hours of live WordPress presentations. It was fully free and it’s one and only purpose was to teach people about WordPress. It had over 34 speakers, from all over the world, and with events like WordSesh, meetups and WordCamps I’m really proud to be a part of a community that always comes together to better WordPress.

If you aren’t involved in the community already you are missing so much. For starters, you could regularly attend a local WordPress Meetup, go to a WordCamp. And if there aren’t any near you, you could even look into starting your own like I did here in Norway. The connections you’ll make and knowledge you’ll learn are priceless and well worth your time.

I would also make sure to check out make.wordpress.org to see how you can give back to WordPress. It’s not always easy to find time in our busy schedules to give back. I wish I had more time to, but every little bit helps and let’s continue to make WordPress the most popular tool on the internet.

Quick Overview

Whether you totally missed the free 24-hour-streamathon of WordSesh, or just want to catch up on the infinite payload of WordPress wisdom shared by its participants, you’ll be pleased to know that the whole thing has been captured on YouTube for your viewing pleasure.

Image based on Words by Alby Headrick, CC-BY-2.0.

Customer service is more than just solving problems and making people happy they decided to use your product. Support is a form of art. How you shape customer service is up to you. Like Thomas Kinkade and Pablo Picasso before him, success in art is defined by crafting an approach that best connects with your patrons. The most beautiful thing about art, though? When you start with a blank slate, you can take it in any direction you want. And the same goes for support.

Some say "good artists are born, not made." But the masters in the Louvre didn't emerge from the womb with paintbrush in hand. They developed interests and pursued those, learning from their experiences to better themselves — and more importantly, their processes — over time. If support really is an art…why treat it any differently? Shouldn't you be able to come to the table with little more than passion for the cause, and carve your own style that spreads throughout the community based on how well it speaks to them?

Running support with a non-technical background

Just over two years ago, I joined Modern Tribe to help handle support for Events Calendar PRO.

The premium plugin was still relatively new at the time. Shane — our CEO — and I did a daily divide-and-conquer on the CodeCanyon forum. The only strategy we had was "make sure to respond before people get pissed off."

That much I understood. But beyond that, things were hazy. Coming into this role I had no experience doing dedicated customer service, barely knew a thing about Events Calendar PRO, and had only a working knowledge of WordPress itself. I could find a line of code in a PHP file but wouldn't feel comfortable making changes myself. I could fake my way through a conversation on Javascript or CSS but would freeze up if asked to hack at core files.

And guess what? It didn't matter…and still doesn't.

If anything, a non-technical support lead can approach customer service without the constraints of a developer's mind. A non-technical support person views things as the customer does, and can convey community wants/needs to the dev team in plain English. They force devs to consider and plan for the fact that not all users are developers.

There is a line that you need to walk: give the devs too much control, and they may build what they want without considering the community. Let the customers drive the carriage, and you're sure to veer from the project's core scope. You're probably going to run over budget, too.

At Modern Tribe, we call the support lead a "community advocate." Remember that it's hard to advocate for the community if you can't put yourself in their shoes.

Since taking that first pass at CodeCanyon, we've grown. Support has become a five-person team and is likely to get bigger in 2013. Shane's removed himself from daily support entirely, and I've stepped back to a management role so I'm not as involved in the day-to-day exchanges either.

My technical skill is not much more advanced than it was two years ago. Likewise as I build the team, technical accomplishments are one of my lowest priorities. I want people who care and empathize; if that means they need to bring in dev help for the more complex support tickets, that's a tradeoff I'm more than willing to make.

Why all good support teams also do Quality Assurance (QA)

If a support team isn't at least partially involved in the QA process, they're doing it wrong. With proper testing instructions even the least technical support staff can effectively run quality assurance testing to verify that something works.

Consider five premium plugins, each with a dedicated support forum that one team member manages. This person effectively "owns" that forum: they address all threads, report feature requests and log bugs to the core dev team. As those come in, the dev team works off this feedback to produce the next release. When it’s time to verify that the new code accomplishes what the community wants to see, does it really make sense to have an isolated QA team verifying that? Ultimately, who'd be the most sensible person to conduct testing here? Answer: the support team member who initially reported the problem. They know the problem, have a rapport with the user and won't have to waste time researching how to replicate the issue. What better way to expose your staff to the code they'll be required to support in the near future?

This is why it's always surprising to hear from teams who handle QA differently. Normally they fall into one of these categories:

• QA exists independent from the support team.
• The devs who did the work do QA. (You'd better be damn confident in your dev team if this is the route you take!)
• There's no real formal QA process whatsoever.

The merits of each could be debated…except maybe the last. (That's just foolish.) But all three create silos — independent, isolated teams working among themselves, which makes for a fragmented experience for the end user. By exposing support to QA, and having support teams increasingly involved in pre-release testing so that everyone knows what’s shipping, we've been able to do a much better job of accurately communicating to users…and setting their expectations on the scope or timetable for a given fix.

As an added bonus, we've found as we get the team more actively involved in the entire project cycle, everyone becomes more excited and willing to share their ideas. The situational awareness such testing offers helps the support team to work more effectively with devs just as much as it helps in their customer encounters. This works well with co-located teams. But what happens with remote employees?

Avoiding the pitfalls of a remote, freeelance support team

Whether QA is a factor or not, support momentum becomes more complex when everyone works remotely. Consider the fact that the whole team is part time and everyone freelances — meaning they've got other clients, too — and things can get messy, quickly. We've only got so much overlapping time in a given day and so we have a strategy for handling support.

No system — no matter how awesome — is going to keep a bad team from failing. If you've got support staff who are genuinely disinterested, view this as "just a job" or who don't share the customer's sense of urgency, then you've got bigger problems.

As a general rule of thumb: if a support member doesn't approach every new support exchange with, "How would I feel if I were in this person's situation?" then they probably aren’t well-suited for a remote support position. The amount of uncertainty — the sleepless nights you'll have wondering how much babysitting this person requires to get the job done — you don't want that. As with anything freelance, you want self-starters: good people who you can count on to get things done. And you'll be able to tell pretty quickly which side of that coin they fall on.

You will find good people — they're out there. Here are few things I've found effective at maintaining momentum with my distributed team:

• A shared commitment to 24-hour response times. This is pretty standard, and I question the dedication of any team who doesn't guarantee customers a response of some kind within 24 hours of the original post. We openly publicize this 24-hour window. It forces the team to stay accountable, because they know there is no gray area: if your forum has threads outside that timeframe, you've failed and so have our systems. And it's going to warrant a discussion you'd probably rather not have.
• Twice-weekly scrums. We meet for 30 minutes, twice a week, to review the support obstacles we're facing. Everyone brings up exactly what stands in their way and we figure out how to work through it on the spot. Everyone normally comes away with one to two action items outside of their regular support duties, to report back on at the next scrum.
• An active Skype chatroom. We've got our broader "Products" chat with the whole crew, but we also started a support-only chat a few months back. What a change this has made! It's like a never-ending scrum meeting where we can ask each other questions and pass off threads or support emails to someone better qualified. Plus, there's just enough goofiness and off-kilter banter that it feels as close to a watercooler as you're going to find in the digital world.

Despite the fact that I have never met three of the four support members on my team, we've developed working systems that are as effective as any established by comparable groups working in physical offices.

Turn support into a flexible creature

Different systems are going to work for different teams, and that's OK. This piece is meant to be an overview of what worked for Modern Tribe in case it might work for you too…and you're welcome to take a page from our book if it does.

But if I could leave support teams out there with one bit of advice, it's to try new things. Buck conventional wisdom. Go with your gut and accept that your idea might not work.

What I touched on here and — for that matter — virtually every aspect of Modern Tribe's support system does not come from a book or from reading articles like this one. It comes from trial and error: seeing what works, what doesn't and adjusting to make sure it doesn't happen again. If you're willing to do the same, you'll learn a lot.

Image based on Billetes y sombreros by Germán Póo-Caamaño, CC-BY-2.0.

How did you get started with web development, and when did WordPress enter the picture?

I got caught in the web before the first bubble in 1999 as a teenager in Montréal. My first exposure to code was Flash Actionscript 4.

That was soon forgotten and I started teaching myself C#. I built a simple CMS out of it, only to move to PHP thereafter. By mid 2000, I put the project manager’s hat. I gradually dropped coding and concentrated on organizing teams.

WordPress first came to me while I was in the Congo in 2005. I entertained my first blog on a platform built by a friend.

The “5 minute install” promise of WordPress piqued my curiosity. I was quickly sold and I knew that WordPress would be a game changer.

Tell us about Wysija and the problem you’re trying to solve with it.

Wysija is a newsletter plugin for WordPress that was first released in early 2012. It’s a freemium solution.

Me and my 3 partners in crime wanted to fill a gap: what newsletter solution can be more flexible than Subscribe2 or Feedburner’s email alerts and yet, not force users to leave WordPress.

There were 3 challenges:

• build an easy to use drag and drop editor
• make the installation easy
• keep it essentially free

What made you decide to build a product on top of WordPress, rather than as standalone software?

There are dozens of great standalones. Great, but users want an integrated solution within WordPress.

Once you’ve trained your friends, family or clients to use WordPress, you don’t want to teach them yet another third party application.

How did you arrive at the business model for Wysija, and what was the thinking behind it?

For some reason, I can’t imagine another model than freemium. Here’s why:

• I’m personally averse to buying Premium plugins myself, believe it or not.
• We need a lot of users to quickly to build a better product.
• The “competition” already use freemium models.

How do the challenges of supporting a product compare to those of dealing directly with clients, as a service provider?

I grew tired of answering phone calls from clients. Consider me relieved at having a product instead of a service.

Supporting a product is very intense nonetheless. Yet, it’s quintessential to our success and I regard it as our number one marketing tool. When you have a product, it’s OK to make some mistakes, but it’s fatal not to respond to your users.

What pitfalls do you think entrepreneurs and designer/developers might face when making the leap from service to product?

Good question. I get it all the time at WordCamps. Many developers are tempted, and yet afraid to make the leap.

Here’s my own unordered list:

• Committing to your product is a full time affair.
• Underestimating support, or disliking it.
• Working alone, because having a partner is tricky, will get you nowhere.
• It’s about the experience, not the features.
• Your users know what they want, they don’t always know what they need.
• Yes, you’ll be poor for a while. But you’ll be exhilarated and happy.
• Sell from day one, don’t wait.

What’s been your approach to branding, telling your story, and setting Wysija apart from the pack?

Your product needs to speak for itself. Build an experience and user interface that is easy and fun. Your users should feel they’re using something special.

As an author, you need to be reachable and transparent. Humans love to hear about other humans. When people write to you, or ask for help, they are friendlier when they’ve seen your photo. Go to WordCamps, and meet your users — it’s gratifying.

Then, it’s all about service. Provide fast and friendly support.

Your website has to look professional so your visitors know you’re serious about it.

Acquiring users is difficult. Try to make every single one of them loyal ambassadors of your product.

What do you look for in a plugin or WP-powered product you’re considering using, and what makes you run a mile?

I look for plugins that have, in this order:

• Regular updates.
• High number of downloads.
• Support reputation.
• Best compromise between features and user experience.

What part, if any, has the WordPress community played in your work and the success of your business?

The WordPress plugin repository is how people find us. More than Google, word of mouth, and sponsoring WordCamps combined.

I consider the repository as the most important community tool because it offers the support forums, the reviews and star ratings. More importantly, it’s not commercial.

Sponsoring WordCamps hasn’t given us a lot of traction, but we do it nonetheless.

Talking at WordCamps has a definite impact. Then again, the crowd is composed of enthusiasts and hardcores. An infinite group.

WordPress is used by the masses. They’re actually everywhere around you, in your daily life. They are unknowingly part of the movement. I’m thrilled when I stumble on someone who uses Wysija, yet knows absolutely nothing about it or WordPress. This is when I feel we’ve reached the core of the community.

What are the three most important things to keep in mind when supporting a premium product or service?

Premium or free, you should always support your users with this in mind:

• Answer within 48 hours, possibly 24 hours.
• Be courteous and friendly.
• Get to the bottom of the problem and fix it.
• Ask for a review when finished. See our reviews, as example.

Additional tip: ever noticed how girls always say they’re sorry when you tell them something bad happened?

They’re right! Say you’re sorry, even if you have nothing to do with the problem itself.

What are you proudest about Wysija, in terms of really distinguishing it from the other options available for creating and maintaining mailing lists?

Its simplicity. This said, you still need to be a geek to configure it. This is part of our ongoing battle to add features while keeping it simple.

I’ll leave the last words for a Matt Mullenweg quote:

“The goal is to reach simplicity and not to be simplistic.”

Today we talk about how WordPress has changed over time, the merits and challenges of Open Source software, WordPress security, digging into the guts of WP, and more development goodness than you could shake a bundle of sticks at.

What was your background before coming to WordPress development, and how did WordPress first come into your life?

My first experiences with the web were at the very beginning of everything. In the early-/mid-1990s, I was the Systems Manager for one of the first ISPs in Huntsville, Alabama. Early on, we just offered dial-up access to a Major BBS system, which was connected to a Linux box, which provided gateway access for things like email, usenet newsgroups, file transfers, and a gopher interface. This was in the 0.99.x days of the Linux kernel, and the question of whether to pronounce ‘Linux’ with a long or short ‘I’ sound were just starting. And the World Wide Web was still an academic experiment that nobody had heard of yet.

But it wasn’t long before this cool new program called ‘NCSA Mosaic‘ started making the rounds, and the GUI interface for hypertext documents was much cooler than the text-based menus offered by gopher. Mosaic was followed by Netscape Navigator (and later, Microsoft’s Internet Explorer), we upgraded our systems, offering direct SLIP and PPP connections, ISDN service, shell accounts, and customers could create their own homepages.

It was in these early days that I first heard of this CGI script called PHP/FI. At this time, “PHP” stood for “Personal Home Pages” — it was only later that it was renamed to mean “PHP Hypertext Processor”. One of my first experiments was to use PHP and MySQL to create a database-driven news site for our customers, which I loosely modeled after Slashdot. It was my first blog-like system, pulling articles from the database newest-first, and displaying them ten-per-page. I didn’t even bother to make an article editing system, I just used PHPMyAdmin to add new entries to the database.

A few years later, we were starting to see open source blogging software. There were things like Movable Type, PHPNuke, Drupal, and even Slashcode which were fairly well known, and a lot of smaller projects. When I decided to set up a blog of my own, the first system I tried out was one of these lesser-knowns, named MyPHPBlog. I even became a code contributor to that project. But the lead developer was slow to integrate changes and push out new releases, and I became frustrated with it. For a while, I considered creating my own blogware from scratch, but I didn’t really have enough free time for that, so I was also keeping my eye out for other promising projects. I had started looking at b2, and it looked really interesting, but it seemed that its developer had more-or-less disappeared, and other people were forking the code already, or talking about switching to something else. I was already aware of this kid called Photomatt, and he was talking about forking b2 into a new system, with the blessing of b2′s creator.

So I think in March 2003, Matt asked me if I was interested in joining in on this WordPress thing he was kicking off. At the time, I was super busy at work, and replied that I just didn’t have time for it. But in April, things were a little more calm, and we were still exchanging emails about it, and I said that I could try to join in and at least contribute some ideas, if not code. Soon after, I was doing things like adding HTTP 304 browser caching support to the RSS feeds and expanding the XML-RPC API with support for the Movable Type and metaWeblog APIs. I remained an active core contributor for at least the next year or so. And I’ve tried to stay active in the community up to the present day.

As a “Developer Emeritus” of the WordPress platform, and a former Core Developer you added elements to WordPress, such as XML-RPC API support and Post Custom Fields, that are still fundamental today. Which are you proudest of?

I think I ‘d have to say Post Custom Fields. At the time, I was very interested in metadata systems, and I had been experimenting with things like FOAF (the Friend of a Friend data format) and other RDF vocabularies. When I first mentioned the idea of postmeta for WordPress, the other developers seemed to think it was a mildly interesting idea, but were not as excited about it as myself. I knew that it would open the doors for some really fun and interesting possibilities for plugins, though. But even then, I didn’t imagine just how many different ways people would end up using it. Eventually, we also got metadata for users and comments, too.

I’m proudest of that because I love seeing how many different plugins and themes rely on it now, and for all the creative ways people have put it to use!

What are you most and least enthusiastic about the way that WordPress has changed since you first got involved?

I am most enthusiastic about the massive uptake of WordPress. At last count, it’s powering something like 18% of the top 1 million sites? I think *anyone* would have to be impressed by that. And anybody who has ever contributed the least little bit of code or idea to WordPress can say, “I’m a part of that!”

I am least enthusiastic about some of the recent dogmatism we’ve seen over the “100% GPL” guideline for WordCamp contributors. I think the idea of barring someone from organizing or speaking at a WordCamp simply because all of their code is not available in a “100% GPL” fashion (e.g. in a split-license situation where the PHP code is GPL, and the CSS/images are under a different license — which *is* allowed under the GPL interpretations we’ve seen), is just too harsh, and only serves to divide the community.

It would be one thing to ask speakers to only promote “100% GPL” projects at a WordCamp. It’s quite another to bar them from speaking about *anything*.

You’ve developed and contributed several plugins to the WordPress ecosystem. Is that something you’d recommend doing, and are there any caveats to go with that recommendation if so?

I highly recommend it. Sometimes the simplest of ideas can take a life of their own and become popular. If you think of an idea for how to add a feature to your site, and can create a plugin to implement it, you might find that you weren’t the only person to want that feature. Declare it GPL, submit it to the plugin repository, and then have fun obsessing over the download counts!

The caveat is, on the internet, there are plenty of people with lots of time on their hands who like to point out faults in others. If you are not an expert coder, someone is likely to point out flaws in your code, and sometimes they might do so in a very unkind fashion. If your skin isn’t thick enough to put up with that, and you tend to take criticism of your work personally, it can be very depressing when somebody tears your code apart and tells you that You’re Doing It Wrong! If this happens, try to use it as a learning experience. Find out how to Do It Right, improve your code, and update. Life is all about constantly learning new things. When I first started learning to play trumpet in 7th grade, I sounded pretty terrible. But I practiced, and got better, and in high school I was in the symphonic band and marching band, and had solo parts. It’s the same with coding, and putting your code out for the public to see is like playing a concert in front of an audience.

As your career has developed are there certain types of projects or clients you’ve gravitated toward more, and if so how are those different to the type of projects or clients you were interested in a few years back?

That’s a hard question. I’d *like* to be doing full-time work involving WordPress. But unfortunately, the job market hasn’t been able to lead me in that direction. As a result, lately I’ve been gravitating more towards front-end work (JavaScript and CSS) than back-end coding. With the semi-exception that I’m also interested in the node.js server, though I don’t use that in my work, and I don’t have much time to play with it on the side.

In the past, I have stayed almost exclusively in the back-end of web development, dealing mostly with overall business logic, database interactions, integrating other data systems and sources, etc. But more recently, the browser has become a much more interesting platform in its own right. The power of modern HTML5, JavaScript, WebGL, and other associated bits makes for a very fun playground to explore.

You’ve presented (and will be presenting, at WordCamp Atlanta 2013) on WordPress security more than once. What would your top three tips be for locking down a WordPress installation, and more generally, what are the most overlooked security issues you see developers make?

Fortunately, WordPress itself tends to be pretty secure. Even when we do see point-releases for security problems, most of them have been ‘privilege escalation’ types of things, where you’d already have to be a validated user in order to take advantage of them. Random, anonymous internet users wouldn’t be able to get into anything.

Tips?

1. If your site doesn’t need the ability for new users to register an account, don’t turn that feature on. And don’t create user accounts for anyone that you do not *absolutely* trust. And when you do, only give them the access role they *need* (‘Contributor’, ‘Editor’, etc). If your site *does* need registered users, make absolutely sure that you have a backup system in place. Back up your database, and also any theme or plugin customizations, and maybe your media uploads if those are important. BACKUP, BACKUP, BACKUP!
2. If your web host makes you use FTP to transfer changes to your site, don’t do that (“You’re Doing It Wrong!”). Use a secure file transfer method like FTPS, SFTP, or SCP. If your host doesn’t support a secure file transfer method, it’s time to figure out how to move your site to a service that does. The FTP protocol transmits your password in cleartext, and while you might think the chances of somebody intercepting that information are small, I can assure you that it happens all the time, often to people who do know better.
3. If your web site is mission critical (whether for a business or just because it’s important to you), try to evaluate the reputation of any themes and plugins you add to your site. *For the most part* plugins and themes you download from wordpress.org should be pretty safe. Especially if there are a lot of downloads and good ratings. If there seem to be some bad ratings, read the forums and see if there are valid complaints that you should be concerned about. For third-party sources, if you aren’t sure of the reputation, ask around the community (on Twitter, in the wordpress.org forums, etc.).

Programmers don’t like to re-invent the wheel. Instead, we like to take an existing wheel, share it, improve it, re-share it, improve it some more, and so forth. This is how WordPress came to be. And because of that nature, WordPress contains within it a toolbox full of utility functions that solve common problems, ready for developers to use. This includes many functions to help you code more securely. One of the main things to learn about is the ‘esc_*()‘ family of functions.

Also, for plugin or theme option pages, learn about the Settings API.

Security is such a broad subject, it’s nearly impossible to convey the complexity to someone who doesn’t already have some technical background. You have to consider every piece of a system — not just the WordPress source code, or even just the themes and plugins you add. Because that all sits on top of PHP and MySQL, which have their own security concerns. And PHP is running alongside a web server, which might be Apache, Nginx, IIS, or something else. And those are running on a server, which might be one of several different flavors of Linux, or FreeBSD, or Windows, or who knows what else. And those servers might also be running other services, like SSH, FTP, email, IRC, etc. And if there are other users on the server, they might have installed other software that you don’t even know about. And there are the network routers, and load balancers, and the DNS system, and…! The internet is a vast system, and while individual pieces of it can be somewhat simple, they are woven into a whole that is extremely complex.

You continue to be active in the WordPress community, including presenting at WordCamps. What keeps you involved, and why would you recommend getting involved with the wider WordPress community to someone just starting out?

I suppose my continued involvement largely comes from the fact that I was fortunate enough to be so deeply involved in the early days of WordPress. I enjoy looking back and seeing how far WP has come over the years — how the features and interface have evolved. And even though I can’t always spend as much time working with WP as I might like, I also enjoy guiding newer community members to an “aha!” moment when they understand how to make WP do something they need.

The vast majority of the WordPress community are some of the most helpful and friendly people you could hope to meet. If you ever have a question about how to do something, all you really have to do is ask — on the support forums, on Twitter, the WordPress Stack Exchange, etc. You will generally get answers to your questions by someone who really knows what they’re talking about pretty quickly. And by using that opportunity to learn, and then later pass along some of your own knowledge to somebody newer than yourself, you have a chance to pay it forward.

What are the biggest benefits and challenges you’ve faced working with Open Source software? Does one outweigh the other for you?

The biggest benefit to working with Open Source, especially as a developer, is that I can modify the code however I see fit. There are very few closed source applications that let you do that at all, and if they do, it’s only if you pay a hefty licensing fee and sign strict contracts. As a user, you generally get the benefit that bug fixes and new features are released at a much higher rate than with closed source products. Since the source is available to all, many developers are able to investigate bugs and determine the best way to fix them.

The main challenge, though it’s lessened these days, has been getting companies to utilize Open Source alternatives to closed source commercial products. Most corporations are strongly attuned to Risk Management. With Open Source, you often (but not always) are not dealing with a centralized entity with contracts to hold them accountable should something go wrong with the product. Many companies consider this a very high-risk problem. You find it much less with the kinds of products associated with web development (web servers, database servers, browsers, etc).

You’ve previously advocated getting stuck into the guts of WordPress. What do you think are the least understood or most under-utilized aspects of WordPress as a platform, and how should designer-developers be making better use of them?

I’m not sure I have a good answer for that. I can say that some of the features that *I* am not as familar with as I’d like to be are the WP_Rewrite class, Custom Post Types, and Custom Taxonomies. I’d really like to find time to dig into those more, and find some interesting ways to use them for my own projects.

Maybe I can side-step the question a little bit here, and suggest that if you’re just getting started with learning to write plugins or themes for WordPress, you obviously have to start with the action/filter hook system. Find some simple examples to work from, experiment, learn the basics of those. Poke around in the WordPress source, and find places where it calls do_action() or apply_filters(). As you dig around, you’re very likely to see an action or filter that you never knew about, that might spark ideas for how you can use it for your own needs.

Once you understand the hooks well, start looking at the various files in the wp-includes directory. See how WP uses the walker classes, how the XML-RPC server class can be extended to add new API calls, how the image editor classes are used. Or you can start with your theme files, see how each piece of content is put into place, and what filters it goes through along the way. When you start looking at the code on your own to figure out how it all fits together, you are bound to learn something new and surprising. I can’t tell you how many times I’ve gone through the WordPress source, trying to figure something out, and said, “I didn’t know we had a function to do *that*!”

What’s the biggest difference between web development as a job and web development as a hobby? Can one feed into the other, or should they remain distinct?

Generally speaking, web development as a job will often limit which technologies and platforms you get to work with. On the one hand, by focusing on those core pieces, you will become very proficient with them. But on the other hand, web development as a hobby lets you explore wherever your interests take you. In my current gig, I’m dealing with Drupal, PHP, MySQL, JavaScript, and some of the more common parts of CSS. But what I’d *like* to be playing with node.js, websockets, WebGL, HTML5 canvas, CSS animation, and Arduino systems. And of course, WordPress.

I think for most people, the two do feed into each other. Obviously, the things you work on as a hobby outside of your job let you explore new areas. This can lead you to have new perspectives, new ways of thinking about and approaching problems, and this will almost always improve your overall skills and ability to do your job. And likewise, the focus you get through your work lets you gain a deeper understanding of your core tools. You get a similar benefit here because that strong reinforcement of knowledge keeps your skills honed and ensures that you are able to solve problems quickly. You can often extrapolate that knowledge and apply it to the new things you are trying to learn in your hobby life.

It’s not every day that we find ourselves interviewing a philosophy major who went on to become a pro-football player before taking on WordPress and building a successful business around theme design. Tell us about your journey into WordPress.

WordPress started as a hobby for me. While I was playing football, we had a lot of free time in the offseason. I’d often find myself tinkering on the web. I stumbled across WordPress while looking for a better tool to build websites. After my football career was over I kept an active interest in WordPress and eventually started designing themes. If you want to read the whole backstory, check out “The last 3 years” over on The Theme Foundry blog.

Are there any similarities to or things you’ve learned from professional football that apply to your entirely different role as founder and head honcho of Theme Foundry?

I learned a lot about hard work and the importance of being a dependable teammate. Football is the quintessential team game. It requires you to do your job while trusting the other 10 players on the field with you to do the same. When everybody does their job well, the team is usually successful. I think this spills over into business as well, and it certainly has helped me while building The Theme Foundry team.

The theme Vigilance was a huge breakthrough for you. How did it come about, and what did you learn from the changes that followed in its wake?

Vigilance was my first foray into theme design and it was way back in 2008. The WordPress theme market was in the very early stages, and I think we just hit the right spot with Vigilance. It was minimal and clean, and had some pretty cool options for a free theme at that time.

The biggest lesson I learned from Vigilance was that customers are willing to pay real money when you provide them with value. Until that point it was more of a concept than a reality for me.

What commonalities do you see in your customers, in terms of their needs, frustrations, or objectives?

Most of our customers need a website and they’ve usually already decided to use WordPress. At the core everyone’s objectives are very similar — stake out my spot on the internet, easily manage my content, and make sure my website looks great and functions well. WordPress handles the first two and we focus on that last part.

You tell the story behind Theme Foundry, as well as those of your clients, on your site. How important do you think it is to have a story in a competitive marketplace, and where would you place that in the mix of other factors that set a WordPress business apart from the pack?

I think it’s extremely important to have a story. A story resonates with your audience in a way that a simple set of facts cannot. Human beings love stories, and for good reason. Stories have defined and embodied the human experience across all cultures for centuries. We’re at an exciting time in history as we now have the chance to bring those stories alive on the web as a shared experience using amazing tools like WordPress.

How important is documenting and supporting your work if you’re in the WordPress products and services industry, and where do some people go wrong with this? What have you learned over time about this process?

Extremely important. As a customer, knowing that the product I purchase is supported and will continue to be supported is a deciding factor in whether or not I buy that product.

Tell us about your design process. Has that changed a lot over the last few years or have you settled on a tried-and-true approach that works for you?

Design is about constantly evolving —- new tools, new methods, new ideas. There are so many talented and smart folks working hard on design problems and it’s great that many of them are happy to share those ideas with everyone.

My design process follows this pattern: sketch, rough mockups in Adobe Illustrator, design, and build in the browser. The first two steps only take about 5% of the total time I spend working on a theme or a design. This is also how we design themes at The Theme Foundry. This isn’t the traditional approach, because most folks either come from an agency background or are working in an agency. Therefore, they usually end up following a more rigid waterfall process that works well in that agency environment. They spend quite a bit of time on the mockup stage and then pass Photoshop files over to a front-end developer and say “code this.” Unfortunately, it’s never that easy. When you make the browser your canvas you can truly design around the medium itself and build a better website.

As a self-taught designer what do you think you were able to bring to the table that those trained specifically in one form of design or other might have overlooked?

I think my weakness as a designer can serve as a strength on the web. I don’t have great artistic abilities, but on the web artistic abilities aren’t valued in quite the same way as they are in the physical world. I think the web at its core is about publishing, so we should take inspiration from the centuries of work in that field. I think some of the best designers on the web have a background in print. Ultimately, I think being a great web designer requires a multidisciplinary skillset, which naturally lends itself to self-teaching.

You’ve created a range of beautiful and innovative themes that have often pushed the envelope. Which are you proudest of, and where do you see theme design evolving next?

I’m most proud of some of our latest themes — Avid, Portfolio, Watson. I think they represent the type of high quality work we want to continue to add to our collection at The Theme Foundry. I should also note, I didn’t personally design or build those themes. But, I’ve been lucky enough to collaborate with the really talented folks that did design and build them.

When it comes to deciding on your next product, do you approach your decisions from a particular angle, such as serving new verticals or putting new WordPress core affordances into practice, or do you just let inspiration strike?

We have an internal process for deciding what theme to build next. Much of this revolves around gaps and areas we need to improve in our current collection. I still don’t think we’ve nailed down those core areas and filled out our collection completely.

Once we’ve focused on a scope it’s the designer’s job to come up with some sketches and inspiration for the direction of the theme.

What’s the one thing you wish you had known when you were first getting started with Theme Foundry?

Push the limits and don’t obsess over small problems. I have a somewhat obsessive personality, and I like things to be organized, scalable, and structured. While this has helped us in many ways it has also slowed us down in others. I’m just now starting to understand the importance of moving faster when the wind is at your back.

Quick Overview
Who’s the best hosting provider? Where can I find courses on WordPress? As a beginner, what’s the best way to get started? What’s the best plugin for SEO? Head on over to the WordPress LinkedIn Group to learn the answers to these questions, or ask your own. Last week alone, there were over 48 discussions, 430 comments, 22 promotions, and six jobs posted. With over 24,000 members, the answer to your question is out there, all you need do is ask.

Image credit: “Chain by Pratanti, CC-BY-2.0

Quick Overview
One of the most beautiful things about WordPress is the community: ever-present, experienced, and always willing to help. Chances are, someone in the world has experienced the WordPress problem that’s troubling you and they’re happy to share how to fix it. Search the forums, and if you draw a blank, post your problem. You’ll find comfort, solace, and a solution. Allow the community to wrap you up like a warm blanket, and send your WordPress woe packing.

Image credit: Remington_Noiseless_Bedienungsanweisung_ 6 by Georg Sommeregger (CC-BY)