5 ms·

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 g

by lbotos 8y ago

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.

evrydayhustling 8y ago
Can you share anything about what you've seen work as far as collecting and broadcasting experience from support to other teams?
- lbotos 8y ago
  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 8y ago
    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.
jwr 8y ago
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 8y ago
  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 8y ago
    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.
jtmcmc 8y ago
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
trynewideas 8y ago
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 8y ago
  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
deleted 8y ago
[deleted]

by lbotos 8y ago

evrydayhustling 8y ago

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

lbotos 8y ago
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 8y ago
  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.

jwr 8y ago

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 8y ago
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 8y ago
  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.

jtmcmc 8y ago

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

trynewideas 8y ago

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 8y ago
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

deleted 8y ago

[deleted]