This is a ruminative post, and I won’t be using bullet points.
I also learnt the difference between ruminative and ruminating while writing this.
Recently, I got one of my early customers for my SaaS IncidentHub. In our back and forth during the trial period, they happened to mention that one of the deciding factors for them in choosing to go with IncidentHub against a similar product was our “excellent support”.
But what exactly is support? For a software product, or any other product?
For me personally, the key element of support is being meaningfully responsive.
Being responsive is to let the customer know that I am aware of whatever it is that they need help with. Once that initial assertion is made, it is completely up to me - and not the customer - to let the customer know about progress with their problems, or any further roadblocks, until they are satisfied. Even if the end result is that I cannot solve their problem, I have to let them know.
I want to go back a bit since I’m musing anyway. Who is a customer? Are all users - paying and non-paying - also customers?
A customer is somebody to whom I am providing someting - a product, a service, an assurance that something will be done in a specific time period. By this definition, if I’m in a team, all my team members are my customers. If I have a product that users are using, they are my customers.
My thoughts on customer service have been shaped by various people throughout my career, and I wanted to capture these thoughts in one place for two reasons. One - to provide clarity to myself. Two - to express gratefulness to those people even though I won’t be naming names.
My first job out of college was in a middleware company called Pramati. The product team I joined was building a J2EE appserver - which incidentally was also the first to be J2EE 1.3 certified in the world. Someday I would love to talk about that in another post. I don’t know what piece of luck landed me in that team after several failed interviews in other companies. I joined an experienced engineering team along with a few other fresh-out-of-college folks. It was a new, exciting experience for all of us. Perhaps what set the tone for the rest of my career was the way we used to work. A focus on technical excellence founded on depth of understanding, a friendly, easy-going atmosphere, and a company led by a visionary CEO and a co-founder who were far ahead of their time.
It was a small team. Engineering would often work closely with customer support. Every customer was valuable. We got to see firsthand how the support team interacted with customers, and we sometimes got on calls ourselves. Now that I look back at it, this experience - so early on in my career - created an awareness that many engineers seem to lack. It’s an eye-opening moment when you see the impact - bad or good - that your code has in an actual customer deployment.
It would still take me many years before I understood the full value of what I had learnt then.
Years later, in a different team, a boss taught me that the commonly understood definition of customer as somebody who pays you for your product or service is severely restrictive.
A customer is actually anybody who depends on you for something, and thus includes your team members. My boss was trying to make us work better as a team - and I think he succeeded to some extent.
The importance of engineering folks working with the support team - or even as part of the support team for a few weeks - cannot be understated. I think it should be part of every junior engineer’s training.