The evolving nature of the Engineering-Support relationship
The evolving nature of the Engineering-Support relationship
The Engineering-Support relationship is one of the earliest points of cross group collaboration between the Engineering organization and another one. It is also a relationship that evolves as the startup matures and acquires more - and diverse - customers.
In this post, I will be covering the evolution of this relationship from the earliest customer acquisitions through later growth stages. I’ll focus primarily on the manners in which to structure this relationship especially from the engineering team’s perspective.
First principles, first
I have found that coming up with first principles for this relationship is essential. These first principles should endure regardless of how the relationship evolves - and it will. They also serve as the guiding points for how and what to optimize for. Below are 3 principles I have found to be hugely important for the engineering and support relationship
Always optimize for an ideal customer experience. There are many models for structuring a support-to-engineering relationship. Some optimize on cost, whilst others optimize on the customer experience. I default for the latter, which doesn’t mean that cost isn’t a factor. It is, but it isn’t the focal point. The customer is.
Support incidents are always a product concern. A customer that goes out of their way to call upon your support team is doing so because they are struggling to use your product. Defaulting to “it’s the product stupid” enables two outcomes. First, you build the product with usability, ease of use and correctness in mind. Second, you view support incidents as an opportunity to further improve your product. The improvements span UX, bug fixes, technical documentation and more.
Multiplexing and context switching are wasteful. Because you really can’t ask your engineering team to work on both feature development and also pick up random support tickets. They need to focus on one, not both. This principle will come in play when thinking of how to structure the relationship between both organizations.
With that out of the way, let’s take a look at how this relationship evolves as the startup grows.
The early halcyon days
It has been my experience that a support organization will not exist when you start acquiring your very first customers. In addition to that, some of the more popular support tools like a 1-800 number, an online ticketing system and so on also do not exist. This implies that the onus of supporting those very early adopters will fall entirely on the engineering team. The question is: how do you do that? That’s where the first principles come into play.
First, you should set up a frontline support team that is composed of the founders and VPE. Every one of your early costumes has direct access to these individuals. They can call them day and night with questions and to report product problems. Direct access to these individuals will optimize for the customer experience.
While giving the CEO’s number to customers offers a very strong signal on how important the customer experience is, it won’t necessarily solve the customer’s problem. Your CEO probably doesn’t (shouldn’t by now) code. They should be focused on running the company. Therefore, you're going to have to rely on your engineers to resolve all support incidents.
The model I applied in how to handle support incidents during the early adopters phase is by replicating the on-call process. That process stipulates running the on-call process anytime one of these very early adopter customers has an identified (meaning triaged) problem with the product. Yes, this can be cumbersome and can violate the third first principle of not multiplexing your engineering team, but given the stakes with these very early customers it is worth it. It also helps align the entire engineering team with what the customers are experiencing, especially poor experiences with your products. Don’t worry you should move out of this phase quickly.
The middle kingdom
You will - hopefully - continue to acquire more customers and will soon have a dedicated Support organization. When that happens, you will need to revisit your operating mode of these early halcyon days. Triggering an on-call process across the entire, or a subset of, the engineering team whenever a customer faces a problem is not scalable. During this phase your customer count should be 50+ up to a few hundred customers.
This period also sees the introduction of more formal support processes. By now you should have a support portal, perhaps a 1-800 number and might be using Slack and other tools for support. Your CEO and founders should no longer be taking support calls on behalf of all customers.
The introduction of a support organization, additional customers and a more formalized manner of support will also witness more formal manners on communicating with customers. Customers will want to know when their problems will be resolved, they might also be interested in SLAs and to receive updates on their support tickets. This further formalizes the relationship between support and engineering.
I have found it very useful to move away from the simplistic on-call like process of the early days and to instead, move to staffing an engineering team that works on support escalations. There are some additional constraints I apply on this team, all of which are meant to support the first principles shared earlier.
First, this team should be somewhat long lasting. I have had engineers working on this team spend up to 3 months on support escalations. This allows the team to truly focus on customer escalations, without having to go back and forth between features (roadmap work) and escalations. When that team is idle, they can work on improving the supportability of the product by building tools, addressing testing gaps (because hey, why should your customers find your bugs before you do?) improving the product’s telemetry or any other avenues that make it easier for an engineer to root cause, or prevent, a customer problem.
Second, I strongly encourage all members of the engineering team to spend cycles on the escalations team. This helps develop customer empathy and enables the engineers to see how the product they work on is being used by customers. It also gives them visibility into the product’s warts. The empathy that your engineering team develops from this experience, combined with the data you collect on sources of support tickets will allow you to improve your product. It’s an invaluable experience for all.
The late kingdom
This is a late stage phase. Your customer count should be 500+ up to many thousands. You might have introduced different support tiers along the way. The main difference, at least from an engineering team’s perspective, will be the staffing model. The onus to resolve customer escalations will still fall onto the engineering team. The question is how to best staff a team to service these customers.
The model I applied is a derivative of the “Middle Kingdom” one. Rather than rotate teams and individuals on the escalations team, you should staff a team that is 100% dedicated to handle customer escalations. It is not unusual for engineering teams to undergo the shift from a dynamic working model to a more static one. Individuals and hence teams, shift from working on different features to working on the same feature-set for a long time (many quarters to years). This shift to specialization will also apply to your escalations team.
The downside to this specialization approach is it limits the members of this team alone to customer escalations. This can reduce the overall customer empathy within the engineering team. The teams that work on feature development might never witness some of the escalations that their features create, which is an anti-pattern. I try to delay making this change for as long as possible.
Building a dedicated customer escalations team will also offer your support team dedicated bandwidth to service some of their needs. It is not unusual for the support team to request tools, or small features that can simplify the support process with a customer. Common tools includes one that can collect logs or any forensics from a customer’s environment to facilitate reproducing a customer problem. The Support team becomes an internal customer for engineering customer escalations team.
Staffing a dedicated - and permanent - customer escalations team will simplify book-keeping and accounting. Things like capitalizing R&D expenses are easier under this model versus applying a changing and dynamic model. Additionally, having a fixed set of resources facilitates how you account for COGS. Your Support organization will be classified under COGS and so might (more like will) this dedicated customer escalations team. Having a fixed resource makes accounting for COGS easier and more predictable, which are traits that your CFO will highly appreciate. That and low COGS!