I was recently flipping through the television channels and happened to land on the Discovery channel show about Nik Wallenda and his seemingly impossible high wire trip across the Grand Canyon . I was on the edge of my seat watching the "King of the High Wire" as he balanced precariously on a swaying, sagging wire across the vast expanse of the Grand Canyon. It was incredible to watch. I thought to myself I would never do be able to do that. The skill necessary and the years of experience to balance so perfectly on so thin an edge clearly is a talent I will never possess. I realized however as I watched him that I could make a comparison to something that I deal with on a very regular basis.
One of the areas of our business that I focus on is the management of both our new releases as well as the support ticket system and the responses people receive to their tickets. Obviously I don't compare the severity of crossing the Grand Canyon on a high wire with what I do, but there are some similarities that can be drawn. I must balance the time, talents and attentions of developers, support staff, and office time between creating the next release and quickly supporting any tickets that are submitted.
I know the goal is to have support staff to manage the support tickets and coders or developers creating the new software, however at this point in our company's growth we have to share developer power between the two. And that's a balancing act. Spend too much time on support tickets and new version release dates start to slip. But spend all your time focusing on the next release and you'll lose the reputation for outstanding customer service. It's important to be aware of this balance and to do your best to give both their share of time.
We've found the easiest way to manage these expectations was to follow a simple schedule. Every day the first 2 hours are spent with technical support, fixes, and attention to existing customers questions/tickets. This can be challenging because things are not always resolved in 2 hours, but this provides at least a soft deadline to strive to meet. If things have to continue beyond that time to fix the issue then the developer handling that issue will continue to work on resolving it while the others start on the new work.
We don't claim to follow this practice perfectly every day but it's at least a starting point. We've also experimented with setting aside a single day a week purely for new development but we found that for our particular situation this strategy didn't work as well. It's something you'll have to explore to determine what works best for your business. The important thing is balance.