To Which Side of the Force Do You Belong?
If you ever worked as a tech support engineer you’d agree: it doesn’t feel like the dev team is really on your side, does it? They never seem to have the time to spare; you wait for ages for a bug to be fixed; not to mention, you have zero control over how and when the issue might be resolved. Your end users get frustrated, and so do you.
It’s not much fun on the other side either. More often than not, software engineers find themselves coding in a vacuum: they lack the context for the issues that got reported to them and that they are trying to solve. They have no connection with the end user who sounded the alarm and hence lack first-hand information.
According to studies, maintenance efforts range from 40% to 80% of the total engineering effort. No matter which side you are on, you must be feeling the pain. Daily.
So What’s Bugging You?
If you are on the tech support team you likely run into these obstacles regularly:
- Lack of visibility of what happens to an issue after you report it.
- It’s pain in the neck to get a developer to help with troubleshooting a user problem.
- You learn a new feature has been added only after it was released.
- The messy version control process is аn endless source of delays and embarrassment in front of customers.
- Your optimism is hitting all-time lows as the common issues you collected and escalated were not taken into account for future product improvements.
- You’re frustrated that you are not getting any updates from the dev team.
To be fair, things don’t look all too bright for the dev team either:
- Sometimes you feel like you're caught in a hamster wheel: a release is shipped, issues get reported back, you fix them, and then the whole thing repeats again. You never get any insight into what end users actually think about the product.
- You get zero context about the reported bug.
- Support seems to be choosing the ‘right’ moment to throw issues at you and annoy the hell out of you.
Bringing Tech Support and Dev Teams Together
The obstacles that prevent the dev team and tech support from collaborating on product and customer service are not trivial, but you don’t necessarily need a magic wand to eliminate them. Here’s a quick list of proven ways to align siloed dev/support teams. Far from exhausting the subject, it aims at providing an insight on how to positively impact feedback cycles and the ability to help end users.
A single knowledge base: setting up a common repository of KB articles is a powerful source of information for tech support. It allows them to constantly refer to previous problems to see whether or not they’re still relevant to solving the customer’s problem. While it might sound like a large upfront investment in time, it’s certainly worth the effort as it helps get everyone on the same page in terms of product knowledge; it also helps both teams save time and eliminate frustration down the road, including onboarding new team members. See some best practices on developing content for your knowledge base.
Have both teams contribute to documentation: while tech writers and support teams own the process of creating user-facing documentation articles, involving developers early on will help not only document faster but also allows both teams to learn from each other and spend less time on document iterations. Read more on why the entire team should care about documentation.
Have developers shadow support reps: most developers will cringe reading this but, if done well, it can help both teams work better together. Set up a time for devs (say 10% of their time) to try to walk in their support teammates’ shoes. A dev who’s never done support has never seen firsthand how his work affects the user. See more opinions and real-life advice on the subject.
Alternatively, identify a bug fix SWAT team: if you are of the opinion that charging your entire dev team with answering production issues can slow progress on new feature development, forming a special task force among devs to work closely with the support team might be the way to go. This will make it easier for both teams to join forces in identifying trending issues and quickly handling difficult users. Read more about the pros and cons of bug fix teams.
Use a common platform to link customer issues to development bugs: I bet you’re thinking “Thank you, captain Obvious” and I can’t blame you. In reality, however, most support teams are unable to view the progress of the reported issues in the development/QA bug tracking tool. Adopting a common solution across teams would be the first step. More importantly, you’ll need to install a streamlined and simple process both teams are happy with. See a few tips for effective defect tracking.
Employ proactive support techniques: in other words, empower the support team to catch problems, errors, and UX issues before your users do. This way you ease the stress level for support and dev teams alike and minimize the number of critical issues that are queueing up to be fixed ASAP. Not to mention that watching someone trying to use your app or site can be a big wake-up call for developers too. SessionStack is a tool that helps you see your app defects through the users’ eyes. It also couples user session recordings with a detailed app log. Find out more about SessionStack.
Adopting DevOps translates into more frequent product deployments, continuous bug fixing, and closing the dev team-tech support communication loop faster. The entire development organization will benefit from support’s visibility and involvement in the development process from beginning to end. See Puppet’s 2016 State of DevOps report.
Implement working change management process: an ineffective process can lead to delays, double work, higher risk of errors, and bugs slipping into production. Creating a formal implementation plan, bringing every stakeholder on the same page, identifying the dependencies and mapping out the steps to be taken is a good start towards a more transparent and simple engineering change management process. See tips on improving change management processes.
Step on what you already have: analyze tickets to identify trends. Listen to tech support to get a better idea of the severity and complexity of the problems. Support engineers can bring fully fleshed out problems to developers: number of users affected, type of systems, how critical it is from the business perspective, etc.
What are your tips on how support and development can work better together?