> Left unchecked, the need to handle support tickets can become a major distraction to the team, hurting efficiency, draining morale, and burning out your best people.
This reads like satire to me - "Supporting the customer who is ultimately paying our salaries can become a major distraction to the team". If the need to handle support tickets has become so overwhelming, maybe your "best people" should be right in the middle of it until they figure out a way to get the entire team out of hell.
Protecting the elite engineers from the consequences of their own designs is a death sentence for a technology startup. I watched this happen in real time myself. The moment you let the developers off the hook, nothing feels real anymore.
The CTO should be leading by example. Getting in front of the customer on the calls. Heading up the nastiest implementations of the product. Grabbing the issues that have been rotting for weeks. Generally, throwing themselves directly in front of the bus at every possible opportunity. If you are the most highly-paid technical person, you need to be the backstop. There is no one behind you to catch anything. The CEO doesn't have time for the bullshit you were supposed to be managing.
Everything else follows from putting yourself in harms way as often as possible. After being ran through the rotten issue wringer for 48 hours, how do we feel about playing with clever noSQL/graph databases or web frameworks with no discernable user base? Does AI make sense for our business or customers? Allow the technology choices and policies to be informed by your daily, real world experience with the business. The more deeply you involve yourself, the more accurate your decisions will likely be.
Exactly - not having empathy towards customer is something our entshittified big-tech platforms can afford, at least for a while. For a nimble startup, that is the path to death. I agree that engineers absolutely should not be shielded away from their design decisions. Not that they should sit on support calls all day long, but spending half a day per quarter in such calls can be very revealing. Some of the best understanding of my customer pains, and sometimes even issues I would have not even aware of, came out of talking to customers, or just listening in to the calls.
I agree the devs should not do full-on support - that's of course just waste of money. But, that's different from spending maybe two hours per quarter with the customer support agents, just listening in on the calls - it can be quite revealing and sometimes there are issues one is not even aware. Plus hearing it from an actual human, does something to your sense of priority about such issues.
One company I worked for had very cyclical sales spikes, culminating in Christmas week each year. During that week everyone did operations, we had developers out in delivery vans carrying parts of the extra large orders to customer's houses, and at least one back in the office mostly handling calls from customers and suppliers.
Without fail that week generated a stack of minor improvements that could be implemented in a matter of days in the new year, because we were out there using the software we wrote, and had the necessary knowledge of how it worked to spot places where we could save people cumulative days of work with a 30 minute patch.
If you have to constantly tell customers to RTFM, you have a poor product. Or at least poor documentation. But no amount of documentation can paper over fundamentally poor product design, because docs are also technical debt.
Even if devs aren't taking calls directly, there should be a product manager communicating this feedback to developers.
What you've said here is exactly why the CTO should be on the support calls with the most problematic customers. They need to be the ones who shield the rest of hte company from letting this happen, and the only way to do that is to experience it first hand to see just how disruptive some clients are.
Ideally there should be some first line who deals with BAU customer support but completely separating value delivery from support bakes moral hazard into the org design.
This reads like satire to me - "Supporting the customer who is ultimately paying our salaries can become a major distraction to the team". If the need to handle support tickets has become so overwhelming, maybe your "best people" should be right in the middle of it until they figure out a way to get the entire team out of hell.
Protecting the elite engineers from the consequences of their own designs is a death sentence for a technology startup. I watched this happen in real time myself. The moment you let the developers off the hook, nothing feels real anymore.
The CTO should be leading by example. Getting in front of the customer on the calls. Heading up the nastiest implementations of the product. Grabbing the issues that have been rotting for weeks. Generally, throwing themselves directly in front of the bus at every possible opportunity. If you are the most highly-paid technical person, you need to be the backstop. There is no one behind you to catch anything. The CEO doesn't have time for the bullshit you were supposed to be managing.
Everything else follows from putting yourself in harms way as often as possible. After being ran through the rotten issue wringer for 48 hours, how do we feel about playing with clever noSQL/graph databases or web frameworks with no discernable user base? Does AI make sense for our business or customers? Allow the technology choices and policies to be informed by your daily, real world experience with the business. The more deeply you involve yourself, the more accurate your decisions will likely be.