We write software for container terminal and other logistical actors, and seeing the software being used by real users is so incredibly important when designing new screens and workflows, it's baffling to me that developers aren't taken on-site more often.
The the few times end users were there, they clearly did not give their honest opinion in front of their bosses. And really even folks giving feedback who use a product are poor at doing son.
But support is where the rubber hits the road and folks actually encounter real issues that they can't solve on their own and create real pain points that will come up.
In my example there were still a lot of issues we'd take back to engineering and they'd say something that amounted to "but they said they don't use it that way" and it was a real chore to get engineering to understand the difference between what an executive asks for / some of the requirements they were given, and what the real user does / needs / asks for. Understandably engineering resources were sometimes irked by this, and support often took the hit politically because of it. It was one of the reasons I got out of support despite getting along with the engineering teams really well.
This got me the best feedback I have ever gotten, and I regularly implemented fixes and changes that made the C-levels rave about the product (because their entire staff was so surprised at someone giving a shit.)
I was quite impressed by my head of product's subterfuge, she was incredibly talented.
That job taught me a lot about what to avoid in a corporate culture, because of how dysfunctional that was that the more actual work I did the worse my reviews got and the more my managers seemed to hate/resent me being on the project. It was a situation I hope never to repeat in my career.
And all that just to preserve some egos. Though to be fair, in some cases users do request crazy stuff, you just shouldn’t listen to them and look at what they actually do.
* Conditional formatting cut a 2 hour weekly job down to under 5 minutes.
* The intern, who was hacking away and learning VBA, spent around 20 hours and was able to automate 4 hours per day of manually retyping info between Oracle and a couple spreadsheets. Would have been about 2 hours if he knew VBA going in, but he learned a ton.
* 2 hours standardizing a spreadsheet format and making a custom macro to shift values by x rows and y columns turned a monthly 2 hour, tedious update task into 2 minutes.
- Knowing that such a person exists
- Knowing that the fix is simple
- Knowing that they will have time to look at a thing quickly
I'm a person who will answer any question on any topic if asked, and help anyone with anything if I have the ability to do so. That's because I enjoy doing stuff in general and my long projects aren't meaningfully going to suffer. Counterpoint, the only people pestering me on this are friends / close colleagues and it wouldn't scale.
I reckon that the net benefit of being willing to do that to the company is positive, but honestly I'd do it anyway because sometimes 2 hours hacking on a powershell script is a welcome distraction!
"How is the user actually using this software?" is sometimes a weirdly hard question to answer correctly in reporting chains.
Then when those reporting chains get siloed due to budgets and in-fighting and over-complicated "change management procedures" (due to often over-zealous risk aversion, maybe to avoid losing budgets), it's far too easy to find yourself not developing for the actual users but for some ideal "manager-user" that doesn't actually use the app day-to-day (or maybe even at all) and instead believes the map is the territory. (Those that think the issue tracker about the app is the status of the usage of the app, or worse that PowerPoint screenshot demos of the app are all that matters and tells them everything about how the app functions.)
At the same time we were giving the devs/engineers a taste of what the requirements should REALLY be, or what the problems REALLY were. That gave them a far better idea of what our pain-points were.
It happened that devs/engineers, while in the presence of theirs and the customers' C-levels/Directors, they only smiled, nodded and agreed, which is kinda dangerous as they were forced to agree on insane, intangible, and unfeasible requirements.
We learned that what executives say and what operation does is not the same thing, which is why we sell our software we say: "We'll fix your problems, but be warned: we won't do it your way", and as long as that expectation is maintained we have very happy customers.
He wasn't wrong ;)
Have a suggestion on how something could be done better? Your way is too complicated and our users are dumb as posts. So we can’t do it. It’s not worth even thinking about.
Of course if THEY want to do the complicated hard to understand thing, it will be fine.
Just one of MANY examples.
Why do the job if you have actual contempt for your users?
It's not contempt, it's understanding who is at the end of the keyboard.
In this case our customers are fairly capable, but the software is really for their end customers who are in a niche industry that is AMAZINGLY behind the times in terms of technology, and the people they hire who actually end up doing a lot of interacting with the software are honestly barely high school grads and are surprisingly incapable / startled by anything out of a very specific routine.
To... To get paid, isn't that obvious? Sometimes you have to do what you have to do.
Truth is, most people are smart enough. If this is a product for internal use, then they might be also extremely motivated, as it happens when handling some piece of software becomes a key element of keeping a job.
Taking the approach of "our users are dumb" makes sense only when you're not thinking about providing value for those users, and instead you're worrying your product could make the wrong first impression (and probably not on users, but the managers), and thus not get bought. It's a valid priority for business, but it would serve everyone better if people were up-front about it.
I agree, if we assume they're going to try. It's not a perfect world and IMO most people really aren't trying / putting in the effort on the things we think they should. It's not fair, but if they're not going to try, they're still the person behind the keyboard.
That's a managerial problem not a technical one, so any technical solution like dumbing down the user interface will almost certainly fail.
I imagine the hypothetical lazy user thinking ‘I cannot figure out a way to convince my boss that I do not understand this UI...’
Nah, that's an indicator the software is most likely not very useful. Like in code, in user interfaces too there's both essential and accidental complexity. Plenty of the latter to improve on, but reducing essential complexity === reducing features === reducing utility of the software.
> I imagine the hypothetical lazy user thinking ‘I cannot figure out a way to convince my boss that I do not understand this UI...’
I imagine said lazy user asking the boss to buy a training course. If that software is so important for the company, a training course is both useful and cheaper than hiring someone who maybe can learn the software themselves in place of said lazy user. Training courses tend to provide ample opportunity to slack off too, so that's a double win for the lazy user :).
(That said, from personal observations of my wife's and mine, people seem to be split on that somewhat halfway - one half will jump at the opportunity to learn something new and progress at their workplace or in their career, the other half will roll their eyes and ask "why should I bother"? That latter group responds to "because it's that or your job" argument, though.
Focus on making management at the company feel like they are doing something for their deployment and get more forthright feedback because they can't be in as much control. Establish some direct follow ups, if needed, to primarily tackle the support issues, but ensure the folks who were on-site are part of that conversation. Present a summary of the event back, including action items which you take from the event alongside their pet problems/requests.
As much as possible we try to bring a person from Product (dev + design + PM) to be involved in the launch project. The benefit here is that the product team gets direct access to the users. And they get "early access" to the challenges our customers face: in the early days of using a new product, the issues shine very bright compared to later when the users have found a suitable workaround. This has and will certainly continue to be essential to building empathy between the people who build the product and those who use it.
Developers should meet the customer organisation to talk to users. If you're not talking to users you're not getting the most useful feedback.
Where I work we often supply software to other software companies, and our UX team goes and visits their customers to get insights about how our products are used.
I've seen many a time where the customer interface contacts believed whatever bullshit that they were peddling internally, and the information we had was essentially completely wrong.
Vendors walk a fine line with these issues. You have to keep the bullshitters happy as they control the money, but you need to get shit done to keep the golden goose producing when sponsors get promoted/fired/held accountable.
Actually I worked over 2 years at a company developing in-house tools. For almost all tools/projects I talked directly to the end-users. 2 observations:
1) users become greedy when it comes to features (especially those users in supervisor/manager positions)
2) there's a tipping point with amount of desired features when users actually start preferring to use the newly developed software instead of a previous solutions
After my field visit I took it to the PO and we implemented these metrics in one sprint. With a single click they could print all import metrics about the last shift.
When normal users had to wait 20 seconds for a page, they didn't like it, but it was completely possible that the system just was that slow. But when the developers had to wait 20 seconds they used the time to look up what took so long and found minor bugs which caused the slowdown and fixed them right away.
As a result, the developers asked to be given more opportunities to work with the live system.
Also gives an immediate answer to all these "should we fail gracefully or crash loudly?" arguments.
Just a small failsafe to ensure nobody is nearby.
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.
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).
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
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.
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.
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.
This is exactly why we (as customers) all have to suffer bad or no support. And sadly, we put up with it, mostly.
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....
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
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.
On the other hand, I don't think it should be done to create a sense of urgency for developers. They are not going to work better if they also have to worry about each and every emotion that's being displayed in support emails like the example in the article. That's just creating a sense of responsibility in your company by appealing to emotions and guilt.
Every so often (rarely but say once a year or so), we bring some members of dev team along on an install. Its always very very eye-opening for developers to see what 'problems' look like in the field.
Further, something devs miss about installs is the lack of infrastructure you have to deal with (on a new build-out for example). So saying 'Just download latest version X and install on each of the clients' will take 5x longer than it does in comfy office environment since it means: (a) Go to hotel or tether phone and download 1GB file over 3G, (b) Put on USB stick, (c) go to each client, disable all USB restrictions and install new software, re-enable all restrictions (d) do all this while power is being turned off / on because electricians are still working.
In a very broad sense, sure. I don't want this account to be traceable to where I work now, so some details will be changed or omitted while keeping the kind of abuse the same.
We make a website where our clients can make timeslots available to the general public. The length of a timeslot is dependent on how many people the person booking slot intends to bring, as well as some other factors. Whether a person can book at a certain time therefore (partially) depends on how many people they tell our clients they'll bring.
We also made it so that the booker can change how many people will be coming along (for example because of sickness), or, if they are delayed, by how much, so our clients can more fully use all of their available resources.
However, how bookers were often using it, is by saying they'd come alone (if you have a very short timeslot, there's a better chance it's still available), and then change the number of people to how many were actually coming along. Or they'd just book a slot at the start of the day, and then delay it until they were placed on the time they actually intended to come. In both of these cases, they were abusing features which were genuinely needed for the product to work to their own advantage. It was slightly naive of us as developers not to take this sort of behaviour into account.
It's definitely important IMO for key people to be in contact with the userbase. Get a better look at what people are asking for, feel more directly responsible for both CS failures and successes, etc. And it overall increases the quality of support (rather than put people in CS who have no idea what's going on aside from the script they follow).
Key quote from the article:
> My experience with everyone reading support emails is, that everyone feel an increased responsibility and a sense of urgency to eliminate whatever emails hits your support inbox.
I am always sad when I see people who think doing customer support is beneath them. It's a red flag, IMO.
After some burn in time, is it really the user who is doing something dumb?
I've seen further steps down this road - if there are engineers already answering support emails, then why do we need support people at all. After all, engineers have better knowledge of technical details and can make changes themselves. No need for intermediaries.
I understand the reasons for having engineers read (or maybe even sometimes answer) support emails, but still I'd be extremely wary of again working for a company that walks this path.
Another extra perk of making devs handle the support is that they also have the chance to fix the underlying problem. Remember that for an engineer, fixing broken software is always less of a burden than correspondence with customers.
Don’t be so sure. Just because you’ve identified the issue or a good fix doesn’t mean the ticket won’t go in the backlog to die a slow death before you’re allowed to fix it.
I didn’t get that impression. The article mentioned reading these emails for 30m a week. Going from there to doing tech support yourself as a CTO is...
It seems to me that a CTO doing tech support either understand something I really don’t, or really fails to understand something I do. Superficially, it sounds like the sort of low-level digging around you get from engineers that got the CTO title but never got comfortable with the transition.
But the attitude displayed in some of the replies is exactly what I'm talking about when I say some people think support is beneath them.
question also works for PMs / devs / co-founders / ...
I know someone will respond that they don't have time read all of the support emails, but my response would be that getting so many support emails is itself a data point.
The fact that there's someone at the other end of the support channel who actively cares and understands the problem and the customer's voice is being conveyed company wide creates a better experience for everyone.
I think a handful of companies are getting more proactive with security reporting, but everyone still treats the quality of their services and front line support system as an afterthought.
If, when I reported an issue, and it was determined not to be PEBKAC... loop me in on updates, or followup with questions. I'm happy to try to reproduce issues, or give more details, or whatnot. I'm a user/customer - I want the product/service, and I want it to be better.
It would be great for companies as a whole to start realizing the value that you can bring to your existing customers through this experience, and to recognize that this is another face of your company.
This only works if they know how to convey the relevant issues to the right developers properly.
I had some large files on my Amazon Drive (the consumer product) which could never be downloaded via the desktop app, web browser, odrive, or rclone. I had to endure multiple instances of support going through the flowchart, and some promises of conveying my issue to the engineering team only to be met with disappointment.
I never managed to recover those files in the end.
100% this. I don't know that it was like this across the company, but the way customer-facing issues were escalated to my group was pretty awful and almost always mishandled. Customer tickets landing in the same queues as host/service auto-generated tickets, bad handoffs and prioritization, devs with no support experience asking for way too much information from non-technical people just trying to use the service. I suppose the first-line support org is to blame in part. Though it wasn't one of the hotter products they offer, it was definitely old enough and nearly foundational to have warranted several more subject matter experts on the support side. Seeing them tout themselves as one of the most customer-centric companies out there was flabbergasting when it came to that org.
(Source, used to eat bananas)
Simple CRUDs with non-complex infrastructure... that cost a boatload per client.
On the topic of reading support email; I think it's important that developers regularly have tickets escalated to them, and regularly hear about the trending issues; but that doesn't mean they need to spend a day in the queue. Processing support email is a skill that needs training and practice to do well; it's not something an engineer can do once a month or a few times a year with good results. Of course, this may depend on the scale of your support queue and of your team; there's a big difference in a few emails per developer per day and thousands per day.
That kind of says it all... There should be no reason support tickets should bog down their infrastructure. We're not talking about millions of real-time transactions here, even in the most popular consumer products. I should expect perfection because it's simply the most trivial product you can build, technology-wise.
Companies that want to get every team engaged with customer feedback can:
(1) Invest in their own data extraction and pipeline to push conversational info into cross-team dashboard.
(2) Perform or outsource a bunch of research and report on "voice-of-customer" to the rest of the org.
(3) Use active feedback reporting tools like ProductBoard or NomNom to organize (one kind of) customer feedback.
(4) Try passive conversation analysis from new tools like frame.ai (that's me!) or scopeAI
Or use ScopeAI :) (Biased since I work there)
- It's harder than development. Green fields are easier.
- It's pretty much a thankless job.
- You are sort of the janitors of the IT world. Not much respect.
+ The money can be pretty good. Because of the above, management usually rewards good support engineers.
+ You are welcomed by those who don't want to do support.
+ You stay fresh, learning other people's ideas all the time. This contributes to longevity.
All things considered, it's been a good career move for me. YMMV.
I recently moved from a dev/support combo role to more of a support one, and this really stands out to me. I'm supporting a half dozen solutions currently, and each one consists of a pile of different flavours of the month. I'm learning a ton of new technology to support the solutions, much more so than if I'd stayed on any one dev team.
+ it's one of the easier routes to becoming a literal expert in how to deploy the software.
I do agree that the pay does not necessarily reflect the fact that the job is often harder than mere software development: you're basically debugging other people's software in realtime, often while angry people yell at you.
If you need help migrating to another platform, please shoot me an email.
Since this is a workflow you've encountered might be something that people would pay for. I definitely like a CloudFront alternative that wasn't as overpriced.
I could imagine it if it was a grandma or grandpa (or similar, you get the idea)... but then she wouldn't know who Bill Gates was anyways.
>Bill Gates is being taken on a guided tour of the product support department's new office building, and during his visit, he asks one of the people manning the phones, "Mind if I take this call?"
In particular "Mind if I take this call?".
The entire idea of the head of a corporation (such as Microsoft in particular) asking permission in that way as if the employee who works for him would have some reason to object or be offended. As if he is butting in front of him in the line at a store or taking his last 10 minutes on a jetski.
"Mind if I..." would be a normal, polite thing to say in such a situation.
Basic human decency always enters the equation
Maybe there's no reason for the employee to object or get offended, but that also means there's no harm in asking permission since the answer will be yes. And there's harm in not asking permission, even though the answer will be yes. You have a couple of choices:
You can treat your employees like peers to get along with and respect. Even if it's more optical illusion than reality, this can make for happier - and thus more productive - employees.
You can treat your employees like minions to boss around. Not exactly the most motivating of environments for your employees. They could try and make their unappreciative boss a little happier... or they could browse facebook a bit more. And maybe steal a few pens to stick it to the man. Maybe not a big deal for a once-off interaction, but even that sets an example for your managers and their not so once-off interactions with their "minions"...
Let's imagine someone is doing heavy labor and digging ditches. More appropriate to just say 'let me do that for you'. Rather than 'mind if I do that for you'.
Bill must know it's not a great job to take support calls constantly and deal with the aggravation. No doubt that there are people (like with any job) that like the job and are fine with it. But those are most likely not people that Bill associates with, is friends with, or respects. The contrast between the parties is where the 'patronizing' comes in.
Another example is a Physician in a hospital. If someone is cleaning bed pans and the Physicians says 'let me do that for you' it means one thing. If they say 'mind if I do that for you' it means another thing.
"Mind if I take this call?" could easily be met with "would you mind taking the one afterwards? I know who's dialling in and we're just wrapping up a long-running issue"
I remember support commenting that lots of users seemed concerned about security (messaging to ask if their files are kept after) and we were removing them, plus it was written in the privacy and terms page.
Finally we put in plain writing that we didn't keep any files, right on the landing page... 40% lift in conversions.
Support is a better signal than exit surveys.
That's a really fast way to burn out your entire team.
Devs don't necessarily have good communication or people skills. They haven't been trained to respond politely when someone sends them a screaming, all-caps e-mail that their product is garbage. That's my job as the Support Engineer.
I would argue a once a month support engineer stint / shadowing would have more benefits than drawbacks.
Since I was still quite new, this introduced me to areas of the program I didn't know very well yet, as well as learning just how the users used our program. This knowledge has been invaluable when improving the program.
I also had several instances of me going "wait why did you click there before going here?" with a reply along the lines of "oh if I don't do that I'll get an error message, let me show you", bugs that had never been reported yet being present for years.
In other words, users are often sidelined by new feature requests (for other users) rather than a selfish conservation of time by developers.
The priority game is as yet unsolved, unless you can point me to contrary evidence (which I would be eternally grateful for).
In my experience, open source developers are just as bad, if not worse, when it comes to their treatment of users.
>> open source people, who don’t answer to managers, act similarly. Therefore, it seems unlikely to be due to managerial influence.
> well open source is a gift of labor, people shouldn’t look a gift horse in the mouth
What you say may be true, but also irrelevant to the discussion being had.
To an extent this is true, in the sense that one must consider the opportunity cost. When working on feature A or fixing bug B, I cannot be working on feature X or fixing bug Y. Also, some features might require a disproportionate amount of developer time compared to the time the user saves.
Just the other day I dismissed a feature request from a user which would have saved that user an hour or so doing a particular task. The problem was that it would have taken me over a week to implement and test (it required complex changes), and the user only had to do this task once a month at most. So for now, I couldn't justify the development time vs user time benefit.
That being said, my primary motivation is to enable users, letting them be more efficient and doing things they otherwise couldn't. I love adding features which allows users to spend minutes rather than hours doing a task, or even entirely automating the process. But I must be mindful of the opportunity cost.
At my last job the support team was a thin abstraction layer that seemed to pass almost everything directly through to my dev team. For a while I enjoyed it -- it is satisfying to see how my efforts could directly help customers, undertand how they were using the product, etc. The type of software I was working on meant that technical configuration problems were showstoppers and people hailed me as a hero whenever I stepped in and resolved their issues.
The downsides were insidious and slow to show themselves: lack of time to invest in fixing problems in a systematic way rather than helping customers one-by-one because of time consumed by support, inability to focus on feature work due to support-related interruptions up to 2-3 times per day, the sentiment from leadership that we weren't delivering new features fast enough because of our invisible support labor, the feeling of being "always on" because we had customers with high-urgency tickets around the globe, etc.
After two years of that, I was staring burnout in the face. I told my leadership I didn't want to work this way but nothing changed. When a month went by where I only made 3 commits to source despite feeling overwhelmingly busy I knew something had to change, if not in the org then in myself. I told my manager I simply would not participate in support any more and was deleting Slack from my phone, that if they wanted a good customer experience they needed to make the necessary investments. In my mind this ultimatum was the first step toward quitting my job. But an amazing thing happened once I started putting boundaries in place: leadership started talking about the need for better systems, better documentation, the need to prioritize work that would make the product easier to use and support. My productivity on feature work skyrocketed and my product managers were happy because we were over-delivering for their bosses after under-delivering for so long. I was given a large raise a few months later, the kind people normally have to change jobs to get.
For myself, I learned it's important not to enable dysfunctional process just because I can excel, for a while, in that process. I learned it's important to set boundaries in my work. I learned that focus is sacred and should be protected. If you are a leader in your company thinking about diffusing the support burden, carefully consider the productivity cost to your most expensive/valuable employees that comes with repeated direct exposure to customers.
Those Support Engineers are invaluable. They can investigate those requests, decide which ones are legitimate (we get a lot of either one-off minor freak things happening due to network glitches or customers just interacting with the software in really crazy ways and we don't have time to baby proof the software -- I should note that this is internal software, so we only have a couple hundred users), and for the things that do happen from time to time, like a customer accidentally closed something out and needs to reopen it but we don't normally allow that to happen so it doesn't get abused, we provide tools so the support engineer can fix those things without involving the rest of the dev team.
Once those things are taken care of, everything that's left, assuming the support engineer thinks it's important enough, can then be passed along to us. We used to only get a handful of those a month.
Now that there's no Support Engineer I get these requests all the time, and I'm getting burnt out, as I'm effectively working two jobs now instead of one (actually four, as I'm also an Architect now and the director of the phone systems, without the promotion, and basically have four bosses now, who don't communicate with each other and each have their own high priority requests I'm expected to do for each of them in addition to dev and support work, but that's another story....we lost a lot of people and there's almost no efforts being made to replace them).
Data are normalized and unified from sources including Zendesk, Intercom, Slack, and Service Cloud. Destinations include manual export, with triggered alert and warehouse sync under development.
In the middle is a layer of enrichment and search-based dashboard prototyping. Enrichment includes "sentiment moments" (wins, issues, risks), conversation cleanup via elastic tagging, and auto-tagging. You can see a peek at some of our research in this area at this blog post: https://blog.frame.ai/learning-more-with-less-1e618a5aa160
Importantly, there's no per-seat charge. We think everyone in the company who can have access should be able to explore customer conversations, visualize them, and export for further analysis and presentation.
I'm an advocate for developers reading/handling support things, but at the same time the skills that make a good developer are not necessarily the same as those that make a good support person. Having some rota/schedule makes sense, but it seems like a full day of doing support isn't going to make a developer happy, primarily because they want to be a developer - not a support-person.
The Support Team knows the product better than anyone in the company which is extremely valuable if/when you get promoted to another position within the company.
I had some conversations recently where I offered my opinion.
"I think this might be a bit complex for the given users who are using this."
"But they want all this information, we're doing it."
A few weeks later end customers are all confused and they're up in arms because they can't figure out how things work because the product threw the kitchen sink at them on one or two pages...
They had an online complaint form, but you were only able to use it on workdays between 0900 and 1600.
Was it an interactive form with immediate feedback? I'm trying to figure out a way to justify hours on a feedback form.
I did the website for a nonprofit I set up recently.
From past experience leaving a catchall "contact" email address around, we decided to omit a public email address this time because we didn't want it to be harvested and subscribed to random newsletters.
There's also plenty that can be learned from answering support - from discovering bugs to fixing them to understanding feature requests to satisfying customers (and the joy that you get from a happy customer), that it's our main onboarding tool for our hires across all departments. Sometimes support can take up a couple hours for a team member, but it's totally worth it. Not to mention our customers absolutely love our helpfulness and responsiveness in support and is one of the main reasons we've had plenty of businesses switch over from our competitors.
For a small company though, sounds like a fine way of doing things as long as people don't get bitter about the ones who actively avoid doing the support.
Don't spam everyone with every support email. You need a ticketing system at least to coordinate work, and prioritization and assignment to get workflow. Don't spam everyone with new tickets in the ticketing system either.
Having a rota of developers who either work directly with support, or on diagnosing and addressing issues that have come from support, is also a good idea I think. Problem areas will filter through from this.
Having all developers always interruptible by support will just slow things down. Interruptions from support often blow away half a day or more worth of development time, from context switching, checking out specific branches etc.
Obviously you want to prioritize work to address what adds value for the customer. But can you really do that if everyone has to be constantly disrupting their work to scan incoming streams of idiosyncratic support requests? That doesn’t make sense to me.
I’m all for cultivating empathy for the customer and keeping people informed, but why does that need to be based on a constant inflowing stream of requests, as opposed to a monthly customer-focused all-hands meeting or something?
The support org should have enough staffing to be able to 'train up' and start tackling more and more issues themselves. Even if they're not writing the software, they can often work to get reproducables or get you most of the way there "null pointer deref of x caused this bug" etc.
It’s not like they’re making everyone true combo support/dev people. Just giving devs an occasional taste.
It was not a glamorous job at all but it had a meaningful impact, one that many people gloss over, and I feel the same when reading this. The best thing you can do is care about your users and the people who deal with your users.
I couldn't even make it the 3 months. They didn't either. Their customers' lawyers were more agile than they were.
As an engineer, I think I would hate that being a required part of the job. But also as an engineer who works in the banking/transaction processing industry, the support was damn amazing.
A ton of things about the company went downhill as they grew and especially after they were acquired, but the support turning completely crappy was the worst by far.
- If you run a business targeting the enterprise, have everyone on the management team go on a sales call once a quarter. Often the CFO will not actually understand what the product is, much less how customers think of it.
- If you have sales people making cold calls have management listen in on a few. Again, you'll see how people think of your message.
Every company needs to do more to understand what the customers are struggling with and the easiest way to do that is to get on the front lines.
It's the closest thing you can come to true realistic user-testing.
I've met devs considering good code and well engineered systems as their ultimate work goals. While myself, only ever saw software as tools towards any actual value keeping the business afloat.
Does that make me a weird software engineer? Or one that should look for some better suited role? Still wondering...
My anecdotal experience is that these trade offs are rarely consciously made, instead made by who ever has political power at the time.
Like trying to know enough to deliver value while avoiding shooting yourself in the foot and also not wasting time on what's only seen as a black box by outsiders?
This is key. Support people is the ones that talk with customers, and know what's going on. Their experience is key.
In most companies this people is low-pay look-down people, gets tired quickly etc.
Is that not an appeal to emotion and thus incentivizes customers to embellish their issues with emotional stories to get expedited treatment?
The insight and nuance that comes from reading support conversations is second to none but more importantly emphasizing with your user enables you to focus more on building intuitive products.
Also, the "real purpose" of L1 tech is to categorize and prioritize incoming calls for further L2 / L3 processing. Knowing "who" needs to handle the call next, and its priority, is usually critical to getting real problems resolved timely.
We need to understand customers the way we understand our program. deep dive and debug their issues and come out with a solution that is win-win.
Terrible idea if people are 'forced' to do it.