Support Engineer: Experiments & Learnings

Each year Panorama Education helps thousands of teachers, principals and school administrators across the country to gather feedback from their stakeholders in a several different ways. Our relatively small engineering team (we just hired our 10th engineer!) strives hard to make sure that it is not only a great experience for millions of students who take our surveys but also a delight for schools and districts to gather and analyze feedback. With ever-increasing engineering needs, teams in a growing startup like ours often have to balance product development with operational and support-related tasks. And one of the ways we address this at Panorama is by a weekly support engineer rotation process.

An overview

The support engineer rotation basically means that on any given week there is one engineer solely responsible for looking into requests from our users and address them in the best possible way. This may include just answering questions or working on small engineering tasks to help the users. This has proved to be a great opportunity for engineers to understand the changing needs of our users, both internal and external, and think about how best we can assist them. Additionally, it gives us a chance to talk directly to the end users of our applications and gain valuable insight about what is working for them and what is not. Often our users give us amazing ideas which help us enhance our products in ways we would never have thought about ourselves.


Given the usefulness of the support week, we keep trying new things to make it easy to address our users’ needs and for engineers to be as efficient as possible during support. In this post we will describe some of our experiments with this process:

#1 Dedicated chat room for support requests

We use HipChat as our primary messaging app in Panorama and we have a special chat room called “Engineering Support” where anyone from the company can post their questions for the support engineer. Of course, there are also in-person conversations about support tickets, but one great advantage of having a common chat room over one-to-one conversations is that when other engineers have time, they can pitch in and answer any pending questions. And once we launched the dedicated chat room, we started noticing that often several people had the same questions and they would start helping each other out without needing the support engineer!

#2 Deploy during support week

It is the support engineer’s responsibility to kick off the daily release for all of our applications each morning and to make sure that they are kept updated to the latest versions. This allows every engineer to know the ins-and-outs of our deployment process and be aware of the continuous improvements that we keep making to our infrastructure. So, instead of just a few people having the knowledge of our daily deploys, gradually the entire engineering team started learning about how we do continuous deployment and contributing to changes that we make to the process all the time.

#3 Categorize support requests

We use Asana to manage internal engineering requests from other teams at Panorama and one of our recent experiments has been to use Asana tags to categorize these requests. Our hope is that with time we might find that certain categories of tasks are more time consuming than the others, or if the number of tasks in a certain category is continuously increasing over time. Having all support requests in one place also gives visibility into recurring requests—so if certain types of engineering requests are coming in over and over again, we can start considering new features for our platform to address them instead of doing them as a one-off task each time.


The support week has become an integral part of engineering at Panorama. We’ve found that focussing only on our internal & external support requests and thinking solely about our users’ needs for a week helps us identify critical areas of improvement in our system. It also gives us the space to think about issues in our platform and come up with innovative ideas to address them. The support week has also proved to be a great learning experience for new and old engineers as we often have to dig in several places of the codebase to solve user problems and this gives us the opportunity to get acquainted with parts of the codebase on which we have not directly worked with.

Both the ‘dedicated chat room’ and ‘deploy during support week’ experiments have been very helpful to our team. They have remarkably reduced the turn-around time for user requests and enabled each of us to gain a good understanding of our infrastructure. Though we’re still gathering data from our last experiment of categorizing user requests, we’re already beginning to see some trends and categories of recurring requests – it might be too early to tell now but soon we’ll know for sure!

If you have more ideas about managing support related tasks in your startup, we would love to talk. And, if you find our experiments interesting, don’t forget that we’re hiring!

Thanks to Jacob, Radhika and Jason for reviewing drafts of this post.

Related Posts
A way to change a foreign key reference with zero downtime
Our Git Workflow
Eliminating Nondeterministic (“Flaky”) Tests in Ruby and RSpec