For the last year or so a big question within our team is
“Are we working as efficiently as we can?”.
The Castos team, pretty much every day
This means many things, including:
- Are we calm and happy at work?
- Are we able to focus on one thing until that thing is done, and done right?
- Do we feel that our priorities are clear each day, week, month, and quarter?
- Are we communicating internally as best as we can, so that everyone is on the same page as frequently as possible?
In examining this, one of the areas that we kept coming back to is how our team handles advanced support and troubleshooting scenarios.
Our platform has grown quite powerful in the last few years, with lots of moving parts, microservices, and integrations that all have to be maintained. And all the while we’re spending the majority of our development resources in the creation of new features and products for our customers.
But inevitably a situation arises when we need a developer, someone who actually built a feature or knows how the system works down to the 0’s and 1’s level to dive into a customer issue to help get it resolved.
But the question always remained:
How can we best involve developers in our support functions?
Previously it was an “all hands on deck” approach where each developer on our team was in Helpscout at least a bit every day.
Our support team would assign more advanced tickets to them that needed an engineer-level person to look into an issue.
This workload was typically anywhere from 20 to 60 minutes a day, per developer.
But as we’re a company born out of the ecosystem of WordPress, one of the companies we look to for inspiration is Automattic.
At Automattic it is standard that new engineer hires spend the first 2 weeks on the job in the support queue, working directly with customers on their WordPress.com ecosystem.
A developer spending 2 weeks in support?! You may say.
Yep, and if you think about it, what better way to get indoctrinated into a product and understand the customer base than to actually talk to customers and see how they’re using your product every day.
And so in borrowing a page from Automattic’s book we decided that instead of all of our developers spending some time in support every day we would rotate a dedicated support developer through every week.
So now, each week one of our developers is the primary developer in charge of advanced troubleshooting, and in the resulting bug fixes that come from those issues.
Early Results
So far we’re just about a month into this rotation but at this point, the feedback from all sides has been really positive.
The support team knows that if they have anything that needs developer attention there’s one person to send the ticket to.
The developer on support rotation knows that most of their week will be spent talking with customers, investigating questions that come in, and doing big fixes on those newly discovered issues.
And the rest of the development team is free to focus more of their time on creating new features and driving the future of the product.
And, most importantly, customers are getting undivided attention from someone who’s sole focus for that week is taking care of their needs. Not an “end of the day, if I get to it” kind of triage system.
While it’s still early on in the experiment, thus far it’s been a great improvement not only to our morale, workflow, and communication, but also the experience that our customers have in our products.
Curious to hear how other companies include their developers in the customer support experience. Drop a comment below and let us know what you’ve found works best.
