Everybody actually gets to lead. Everybody in the team has the ability to lead from within that group and put themselves into the best light possible and to help to guide what’s happening in an organization.
Selena Delesie — How to Be an Outstanding Leader
I recently talked with my coworkers about strategies for troubleshooting. We were focused on how to troubleshoot issues while chatting with our users, but I wanted to start with a basic workflow for troubleshooting bugs in any support medium. Here’s what I came up with:
- Understand the problem from the user’s perspective
- Determine if it is expected behavior or a bug
- Search for previous reports of the bug or discussion of the feature
- Test to see if the bug is reproducible
- Report the bug in the appropriate place
I feel pretty good about that workflow, in terms of describing how you can identify and report a bug. As soon as you start considering the rest of the support picture, though, it gets more complicated.
Here’s a rough flowchart I just sketched out that takes into account the larger context:
I like how that flowchart encompasses not only what to do while troubleshooting a bug, but also some ideas for how to handle non-bugs — and what to do about the user who’s still stuck even after you identify and report a bug. Because let’s be honest, some bugs aren’t going to get fixed, or the fixes might take a while, and we’d still like to help those users get to where they want to go. I guess that’s a more holistic view of troubleshooting, beyond being a bug collector. 🙂
The Happiness Lead at Automattic, Andrew Spittle, did a nice interview with Olark about how we approach engineering happiness for everyone who uses WordPress.com and other Automattic products:
Along with the larger overview of what we do, Andrew included this little tidbit describing what I think is one of the biggest challenges (but also biggest opportunities) in our work in the WordPress.com forums, where I spend the bulk of my time:
… a Happiness Engineer also does a little bit of qualitative customer feedback. We always get long public forum threads whenever we change something. It’s partly going back through those and picking out the highlights or the commonalities, and communicating those back to product teams.
As a Happiness Engineer at Automattic, I try to be generally aware of things that are happening across the company — or at least in the areas that touch WordPress.com, where I do most of my work. It’s impossible to keep up with every detail, but I need to be ready to reach out to a variety of teams if something comes up that’s related to what they’re doing.
Over time, I’ve noticed myself turning to GitHub more and more during my daily work at Automattic. Whether they are developing code, tracking bugs, or sharing resources, many teams are now using it. You can find public GitHub repos for projects as varied as Jetpack, _s (a starter theme), Babble (a plugin for multilingual WordPress sites), and Legalmattic (legal documents used for WordPress.com). (You can also browse all of the public Automattic repos if you’re curious!)
I was aware of the basic idea behind GitHub and how it worked, but up until about a month ago I only ever opened new issues or added to existing issues, to track reported bugs. Recently, though, I cloned a GitHub repo and learned how to switch between development branches to locally test out features that are under development. And yesterday, I finally committed and pushed new code to an Automattic repo for the first time!
In addition to Google searches and tests I did on my private repo, here are a few tutorials and references that helped ease my mind before I made that first commit: