[lbotos]

Hi, Support Engineering Manager here, who has forgone Dev for a career in Support.

In a small company (<10), yes, do this, everyone will level up, and you'll get extreme customer focus.

As companies grow 2 things that I think are really more valuable:

- Support Engineers, These are folks that have commit access and can write fixes, who are focused directly on customers. Don't distract product from new features, Support Engineers can fix low hanging bugs, (button states weird/form is weird, error messages wrong, etc, etc), and then funnel harder or product-changing bugs to product. For every 10 devs, I think you should have 1 Support Engineer.

- LISTENING to your support team. I always see companies and people doing the "uhm, oh yeah, we should totally all jump in and do support to better understand it" but really, it's like, trust and LISTEN to your support team, ask them what the most important thing to them is, and actually prioritize it.

It was extremely demoralizing when "holier than thou" devs came to do support and kicked and screamed for their week rotation. Sure, thats indicative of bad culture, but I promise you there are at least a few devs on your team who are this way right now. Let them be devs, instill a culture of trust and teamwork in different areas, and your company can scale and move fast.

[trynewideas]

Some caveats and related advice, having been on the product side and two different customer-facing sides:

Integrate support engineers at least part-time into the product engineering teams. Support engineers who don't know what product is doing can duplicate or complicate product work.

Invest in paying and training the support engineers. Don't pay them well and they'll either transfer to product engineering once they get competent or jump ship to someone else. Poorly trained support engineers who "have commit access and can write fixes" will invariably introduce new bugs that will block product work.

"Don't distract product from new features" is a great goal, but recognize that it's a goal, not a law. There will be fires that product engineering will have to walk into and put out alongside support engineering, especially if your product is more than an small-team app, exponentially if the problem comes about due to systemic design problems on the product side.

It will be tempting to outsource support engineering to save money for in-housing product. Don't. If anything, outsource low-hanging product work before any support work. In-region support engineers make everything about firefighting smoother and customers in every geo will appreciate it.

Incorporate support pain into your dev process. That's not bug metrics—measure the _pain_ your product causes customers. Feature requests are pain. Insufficient docs are pain. Licensing issues are pain. You can insulate product from customers, but don't insulate them from the pain the product causes customers. Use it to help guide the roadmap and you'll find low-hanging fruit that product never considers because, chances are, they aren't interacting with painful parts of the product (otherwise they'd already be addressing it).

[lbotos]

I love this extra perspective to my comment!

The only thing I'd add:

> who "have commit access and can write fixes" will invariably introduce new bugs that will block product work.

All fixes by Support Engineers should go through the normal CI pipeline and Code Review process. This is designed to exactly stave off this kind of effect. But yes, I still agree with your points! I love HN <3

[jwr]

This is excellent advice. I will add to it:

If in a small company you are spending a certain percentage of time/money/effort on support (probably 10-15%), there is no reason for that percentage to be different in a large company.

Go through that again with me, please. You've been spending 10-15% of your time listening to customers and providing good service. When you grow, why would you want to provide worse service?

And yet, this seems to be the established thinking (oh, we can't possibly provide direct E-mail support at this scale, let's hide our contact information and make customers jump through hoops just to contact us, and let's keep our support team small so that we can make more money).

Your customers will report lots of issues, and yes, some will be bogus. But most will point to real problems, either with your software, your hardware, your usability, your processes/procedures, or the limitations of any of the above. If people write to you, it means they took efforts to contact you: do not just discard their reports as "bogus".

Another way to look at this is that every bug report is worth its weight in gold, because for every customer who reports a bug, there are 10 others who do not, and just stop using your app/service/whatever.

Also, if you ever extend/automate/scale your support, make really really sure that there is ALWAYS a way for at least some user reports to make their way to developers, designers and architects. Otherwise many valid bug reports will get stonewalled and lost. See the recent Apple FaceTime ("facepalm") fiasco for a good example of this.

[SpicyLemonZest]

An organization with 5 customers can babysit each one to make sure they’re happy in 10-15% of their time. An organization with 1000 customers couldn’t do that even with 100% of their time. The only way to maintain a fixed allocation of customer support funding is to make it less high-touch as you grow.

[jwr]

I respectfully disagree. Note that 10-15% of resources of a 5-customer organization is very different from 10-15% of resources of a 1000-customer organization, assuming your customers actually pay you money (generally recommended).

This means that even assuming you get no benefits of scale (and you should be, your software/product should improve as you learn and support load should fall), there is no reason why you can't provide the same level of support as your organization grows.

The problem is that people assume for some reason that a larger organization can't dedicate 10-15% of their resources to support. This is why whe get crappy support or no way to contact the organization at all.

[PeterisP]

This is all about scaling. You want to do 10x the customers with 2x the employees, so that the business finally starts to make money. The service level that took 10-15% of your resources back then would take the majority of your resources now; the same % of your resources now is much less hours per customer.

[nacs]

There shouldn't be a linear increase in support requests with a larger customer base.

As your product scales to more customers, the percentage of support requests generated should be going down as you improve your product and support documentation based on existing customer support requests.

[sk5t]

This ("shouldn't be a linear increase in support requests") is true some of the time, but not all of the time in all lines of business. Make a thing foolproof, and the world will go on generating greater fools, you will see a greater variety in weird requests or bizarre expectations, etc.

[Aeolun]

The number of requests may scale linearly, but the number of actual issues won’t.

[jwr]

But that's my point, isn't it? If you want to do 10x the customers with 2x the employees, you will be cutting into your support resources, and your customers will suffer.

This is exactly why we (as customers) all have to suffer bad or no support. And sadly, we put up with it, mostly.

[SpicyLemonZest]

There are serious overhead costs to running a company 10 times as large. If you also have to hire 10x the employees, you'll end up needing to charge more than most customers are willing to pay. (Customers who are willing to pay out the nose generally do get good customer service, even from organizations that are normally bad at it, up to and including teams of engineers deployed to the customer's office to help out.)

[a1369209993]

If you have 200 times as much revenue, why don't you have 200 times as many employee-hours?

[Swenrekcah]

I think most companies want economics of scale, but even if they don’t:

Finding 10 good engineers that care about your customers is difficult but doable. Finding 2000 is much much more difficult.

Trusting 10 engineers to communicate with customers without promising things they shouldn’t, mentioning upcoming features that hurt current sales, have generally good communication skills, is again difficult but doable. Asking that of 2000 people....

[bostonvaulter2]

That highly depends on how much money you're getting from each customer

[jtmcmc]

as someone who did support for years and now does engineering I think this is so correct. Support is listening to customers, not only that they are listening to a LOT.

I think it's valuable for engineers to talk to customers but they and product should also actually listen to support - they are probably telling you a large majority of the pain points your customers are experiencing.

also - and another major thing - make sure you have a way for support folks to become engineers, product managers, designers, etc... in my (clearly biased) opinion this often results in an engineering / product department with a deep understanding of your customers needs in its bones

[evrydayhustling]

Can you share anything about what you've seen work as far as collecting and broadcasting experience from support to other teams?

[lbotos]

1. Invite support to product/eng meetings where you are prioritizing. Add them to the agenda by default so it's natural to expect them to speak. This is huge and helpful.

2. Consider baking in "Support gets a MINIMUM of X things" on priority. Tough conversations will be had, but support/product/engineering will learn how to get what each other need. This one falls apart and "when the going gets tough". Support gets the short end of the stick usually. (That's why I advocate for a Support Engineer, so those things don't even need to leave support, they just get fixed and when support speaks, the teams know it's big.)

3. Make sure whomever is heading support knows what other stakeholders need to see, so they can deliver. Some would call this "data driven" but in some orgs, "data" is just 3 angry users.

4. We currently use this term "Stable Counterparts" and that's vital, figure out who should regularly be talking to support and about what, and once that relationship forms, things get smoother. Until then, support will be yelling into a void.

[evrydayhustling]

Thanks for this rundown! I'm especially attuned to your (3) and (4); we've run into a lot of CS teams creating "liaison" roles with sales/product/engineering, and even in some cases with finance teams re: categorizing causes for churn and such.