I could get a quick ya or nay form them on some things and it was so much faster for everyone involved.
If it was a ya, I knew we had something, still more work to do but the case would skyrocket through the usual channels and engineering was engaged and ready.
If it was a nay, the usual channels it went and everyone was ok with that.
The engineers would give me a few minutes knowing I wasn't going to bring them poorly thought out garbage, I would limit the rate of these special situations, and special customers / sales guys could get the job done way faster.
It was a well known process by those who knew about it... but not everyone knew.
Customer support is a cost center and the focus is on mitigating the cost of providing that support. If you fail to do this you can burn through a lot of cash quickly. What management needs to realize is that this is also an important interface point which requires attention. This doesn't happen at all, or is inconsistent.
It's important for at least the following to happen:
1. Bad issues that engineering will fix don't get stuck in support.
2. Product management review and respond to feature requests, or enable support to respond to customers.
3. Support have a reasonable level of technical and communication skill, and are empowered to answer for the company.
4. The organization works through rather than around support.
What I've always found interesting, is that all of these are often failing in some way at the same time in an organization of any size.
Your role as the back channel is helping to provide some coherence here. However, things can go bad if you left. Inevitably, this is the fault of the company, but when I've found myself in this position I've tried to "promote" people in support to take the lead on this role. Further, formalizing the special request process to be minimally tracked helps visibility with my manager and others. Eventually managers ask why you have become a gopher.
Improving the workflow often involves helping support build relationships with engineering. Management can buy in if support attrition is high (it often is if there is a limited career ladder for support) and it can also improve their perception when people are focused on trimming support cost.
To be frank, it seems like an organizational way to say "we don't find this work to be valuable or interesting, and we'd like to do the bare minimum of it - in fact, we'd like to unleash smart people to explore new frontiers of just how minimal the bare minimum could possibly be."
It seems like this leads to incredibly predictable problems: brain drain, demoralized workers, the bare minimum being aimed for and not actually being achieved, etc.
I feel like a better organization has no "cost centers" - every single role at the company contributes to the mission and to the bottom line. If they didn't, that position wouldn't exist.
What am I missing?
Unless you’re into fraud, “accounting” and “accounts payable” are examples of cost centers. You don’t hire a bunch of innovative people to boost it because it’s not going to ever increase your revenue.
The distinction is made from a strategic perspective because scaling up “cost centers” should be avoided at all costs and scaling up “profit centers” is something you want to do as much as you can.
It has no overlap with “interesting work”. Very often the boring parts of an industry are the profit centers (e.g. in academia the profit comes from packing students into classrooms, not research).
Some examples (that I have seen in reality):
Finance departments are cost centres, until you give them enough resource and they find you a more efficient tax structure. Cut finance departments start to struggle with things like credit control which affects your revenue.
Distribution Centres are usually seen as a cost centre, until you drop spend and it impacts COGS or customer lead times, or inventory in shops raises because of less frequent deliveries and you get out of stocks.
IT is a cost centre, but when funding is reduced change across the whole business slows and other areas are impacted (eg the customer web experience).
In reality the distinction of “some areas generate profit” and “some areas just cost” isn’t true in the end. All areas contribute to profit - some just do so indirectly.
I think the idea of Michael Porters “value chain” is better, where everything contributes to customer value (including indirect functions). The argument this makes is if you see some areas as just cost centres (e.g. fulfilment centres) then you can miss your ability to maximise customer value (e.g. offering faster delivery options).
Even sales people don’t usually generate profit on their own because without the other business areas they would be selling hot air.
Expecting enough of them to just volunteer their time doesn't appear to be a sustainable answer.
I spent a few years in IT as a Product Manager (or a similar role), and I viewed my primary role as protecting my team from the barrage of shit that I got, so that they could focus. This involved making sure I was politically the first point of contact and reducing back-channels (some are fine, but not ones that change functionality, involve significant work or are too distracting), placating the people requesting functionality or fixes by understanding how serious the dependency/issue was, triaging it and either placing it on the roadmap or saying no. We also had an engineering manager that could be the contact for specific bugs who could then triage and pass it on.
You're so, so spectacularly wrong on this, I am honestly gasping for air.
Accountants are the only people who know if your company is alive or a walking dead. How do you expect to run a company if you don't know reliably and with precision how much money it actually has/makes/spends? Money is the lifeblood of a company! Don't you want to be constantly improving the way you make, spend, and report it to investors and the public?
The biggest companies in the world typically end up with CEOs that come either from sales or from accounting. That is not an accident. Business is about money, and you want smart and innovative people to look after it. Conservative CFOs can be the death knell of a company, among other things.
Calm the fuck down. It’s a conversation.
> Accountants are the only people who know if your company is alive or a walking dead. How do you expect to run a company if you don't know reliably and with precision how much money it actually has/makes/spends? Money is the lifeblood of a company! Don't you want to be constantly improving the way you make, spend, and report it to investors and the public?
You entirely missed the point. At no point did I say accounting was not important. I pointed out though that investing more and more into accounting does not boost returns. If that were true, every company could just hire thousands of accountants to boost their profits. This is what separates a cost center from a profit center. Your department provides value in the same way that running water does. It’s critical and you don’t want to skimp on it, but it’s just a part of the business that isn’t helping grow the total market capture.
> The biggest companies in the world typically end up with CEOs that come either from sales or from accounting.
Why would you include sales together with accounting? Sales is precisely the opposite of accounting in this regard because it’s very easy to tie sales directly to revenue. So easy their compensation is literally based on it.
Not so hot take: CEOs that come from accounting and not a customer-oriented profit center are the worst. They know what the numbers look like but are fundamentally disconnected from why customers give money to the business. Seeing the minutiae of the ins and outs of money gives a super false sense of understanding the business. Accounting CEOs are terrible in any industry that requires innovation or getting ahead of trends.
However this:
“Accountants are the only people who know if your company is alive or a walking dead.“
I disagree with.
A walking dead company is only walking dead until one of its initiatives pays off.
The accountants will only know this after the fact, whereas numerous other functions may know it to varying degrees of confidence before the fact.
The accountants know when your debits have to be repaid, how likely they are to be repaid or refinanced by then, and what the penalty for not doing so will be. I'd argue that, in most cases, nobody employed in the development/production chain will have that information, possibly not even the CEO.
Yes, they may have models and estimates, but the real information will be in the hands of those involved directly.
Even things like refinancing and the options for doing so can be affected by things like letters of intent from potential large clients, industry validation, etc.
Just knowing numbers and dates isn’t enough.
I’m not saying accounting isn’t important, but it just isn’t the only source of truth.
Support can very much be a profit center. Support personnel is relatively cheap; if their services are priced correctly, they can easily become a stream of recurring income - and everybody knows that "recurring income is best income".
However, this requires efficiency and creativity at the managerial level. It's easier to see support as a burden and just work on shrinking its costs, instead of maximizing its revenues by formulating good price plans. The former is an internal effort that is fairly easy to implement in short timeframes and will easily win brownie points with direct superiors (who doesn't like to cut costs?); the latter requires actual pricing skills and market knowledge, and might take a while to get results. The mediocre manager will always prefer the former.
This sets up perverse incentives, that as far as I can tell, are theoretical, but have potential to become more prevalent. Because of the cost center as a profit center idea, my ISP can generate more revenue by providing less value to me. If failing infrastructure causes me to call support more often, and more support calls increase the likelihood of more revenue, why should the ISP invest in better infrastructure?
The key to having a successful business is to carefully align the incentives of specialities in an organization to make the most competitive offerings to the market. If there are competitors, and customers can switch to them, and the competition is more compelling, then I would go to other ISPs.
"Cost center" can be transformed into something else given both an understanding that support can and should contribute to future sales, and an organization capable of putting that understanding to work.
I have seen a similar scenario in manufacturing where various setup, prep, quality tasks are seen as cost centers and minimized.
Doing this kind of thing has ripple costs. Always.
In a perfect world, we make software, or hardware, and it just works and people grok it.
In the one we live in, these are fantasies and we can choose to understand, recognize the value, or not and get the benefits or not.
The users, customers, move from role to role, and support often determines their willingness to use the product again. That is straight up powerful marketing by referral.
Support often is the first to understand a user, customer needs an option too, or add on, replacement, preventative maintenance. Done right, these leads into lean, consistent sales.
"Cost center" to me has always been a bit silly in this way. There is opportunity to add value throughout the chain of people, process, machines, systems that are all necessary to properly conceive, realize and deliver something to others.
One thing often missed along with failing to understand value is failing to ask to be compensated for it.
Doing things in a robust, high value for the dollar way is not the cheapest way, in terms of raw product price, and depending, size of margin.
But, we do get what we pay for too, and the lowest price often comes with externalities paid by both the enterprise and its customers too.
Sometimes I see this all framed as a luxury. That is just as much of an error, and does come with unnecessary costs and or poor alignment with actual value.
If there are serious UX issues, your designer might not uncover them, but support will hear about it. If there are edge case performance issues, your dev team might not uncover them but support will hear about it. Very few people know more about how real users interact with your products than support.
I should have included that. Glad you did.
not much, or everything -
it's basically an accounting term on how you are tracking an expense and so it is very insightful as to how the effort of your project,group,department etc. is perceived by upper mgmt
so "we don't find this work to be valuable or interesting, and we'd like to do the bare minimum of it - in fact, we'd like to unleash smart people to explore new frontiers of just how minimal the bare minimum could possibly be."
is pretty spot on, if the effort has been (mostly arbitrarily) categorized as such..
when i learned the accounting theory behind it, it suddenly illuminated managment attitudes in current/previous jobs - literally in some orgs overly reliant on this perspective there is literally nothing certain efforts can do through official channels to be viewed as 'valuable' ..
* people expecting to use a sophisticated tool (for doing complex business processes requiring special know-how) without paying for and spending time on adequate training)
* people unwilling to RTFM, google, youtube, etc.
* people whining when a general purpose tool doesn’t fit their exact workflow to a tee
Back in my support role for higher end software, I flat out hit numbers comparable to sales and generated a ton of great leads.
Fact is, people do what they do and they have their reasons.
Judging them and acting on that judgement by marginalizing an important and necessary part of the process has a higher net cost to the world, and often the enterprise, than just doing those things reasonably does.
Net happiness goes up too. True for the enterprise and users, people at large.
And the fact is, enterprises seeing to make every support transaction a positive ROI are, in fact and in deed, penny wise and pound foolish.
They will see an opportunity cost due to missed sales opportunity.
They will see greater load due to people using an inferior process and poorly empowered people, repeatedly.
They will see a diminished overall market perception.
Their products will provide less value due to a greater misalignment with both exiating and potential users needs, which drive perception of value, which drives more dollars.
Personally, having been on all sides of this matter, I rank what we are discussing at the very top when considering who I will buy from and or work with.
Flat out, when I see enterprises putting seriously crazy amounts of money in the bank, I accept zero excuses in this regard.
It is not necessary. Lives are short, money hard to come by. Best get solid value for the dollar.
Right now, I am in the small business space and rock solid support is how we are killing it.
Been there, very large, small, medium, consumer, b2b...
Don't tell me it can't or should not be done when billions land in accounts free and clear.
It can. Should.
I spend with those who get that first and foremost.
And I don’t mean that cynically - since if it’s as easy and guaranteed profitable as you say, why wouldn’t you be able to convince numerous CEOs to unearth all of those extra billions?
Again, if the priority is to always have a positive ROI, and that metric is computed every quarter, without due and inclusive consideration for externalities?
All the things I discussed here are going to get watered down. And it is always the same priority on max dollars now, max recurring dollars now, and WGIF about the future, others.
Where that happens, so do the things I just said. Not my mess to clean up.
Some enterprises get it. They get my time, attention, dollars and referrals first.
Beyond that? Got better things to do.
Clearly you value things differently. That does not make anything I said wrong.
Take care. You get last word on this.
For us, great customer support is one of our stronger sales arguments. In fact we've not had to push hard on sales due to our customers calling former colleagues who moved to a competitor to tell them "you have got to get this software". Having great support has been key to this experience.
Most of our support people have been recruited from our customers, so they know not just our software well but the processes and regulations around it, allowing them to quickly understand the issue at hand and offer relevant help.
So while it might look like a cost center on paper, I'm quite certain it's a massive net gain overall.
Of course as you say, we work hard to mitigate the cost of providing that support, like routinely looking at implementing changes that'll reduce repeat support issues. Maybe as simple as reworking a dialog text, to adding more automation.
We had 'official' faster escalation paths but those inevitably are determined by $$$ and there's always more ways to measure 'important customer' than can be defined / shown in $$$.
Management was totally aware of it all and supportive.
But eventually I got tired of the land of 'support' and moved on for a variety of reasons, mostly because time and again I saw support treated like the usual 'cost center' and I didn't want to be a part of that.
> What I've always found interesting, is that all of these are often failing in some way at the same time in an organization of any size.
The formalization of it is frequently the cause of it failing or being inconsistent. Once it's a workflow that's explicitly acknowledged and condoned by management, it will start to lose its effectiveness. As an official express lane between customers and engineering, every account/sales person will become aware of it and overload it, either in the general course of supporting their client portfolio as much as possible, or even worse, by making this internal express route known to clients, as they can get incremental revenue by branding it as a "VIP Support" service or to make at-risk clients feel special. Which will eventually end up in actual client contracts in some form or another, opening the door to client abuse (or misuse) as well as causing legit cases that would have gone through this implicit channel to get routed to and trapped in normal support because the client at hand didn't pay up for the express lane.
You've also replaced a channel built off of relationships and mutual trust/respect into one based on official responsibilities and inertia, and all the hazards that entails. Such as political/managerial turf wars that add friction to the process, as well as cost minimization efforts that deskill the role over time and profit maximization efforts that overwhelm the capacity of the role, alienating the engineering team and undermining the entire intent.
... not to say it's impossible. But that's generally why you'll see it failing in some capacity any time you witness it, because it's almost impossible to maintain equilibrium the moment you officiate it.
An alternative that tends to be more lasting is for management to _actively facilitate organic growth_ of these sorts of things. Enable and encourage and provide opportunities for inter-departmental relationships and lines of communications to form. That way there is no single "back channel", and organic lines of communication between different parts of the org are robust against the loss of a single node.
In my opinion, we had this. They were your senior support staff or were operations; some companies combined this into a formal role called "Support" or "Service" "Operations."
But then we as an industry decided that operations is bad[0] and if you write the code then you can obviously test the code, deploy the code, maintain the code, and support the code. Then every Hip And Cool Start-Up adopted the model of "sysadmins and support staff are bad because we've had bad experiences in the past so we will also have our devs talk directly to customers until they get tired of doing that and we just replace it with a contact form encumbered by CAPTCHA and a no-reply e-mail address."
As someone who has greatly enjoyed, been very good, and very well paid (so my employers agreed that I was good at it), at support and operations roles only to see them disappear into the inky void of Everyone Codes All Of The Time, I am both biased and frustrated.
0 - Because money, I suspect.
I've been heavy in the data space, and get to do some fascinating work with folks, helping design data models, implement analysis, and other things in a wide variety of verticals. It's support, so sometimes there's some more tedious things too - there's no avoiding that. :)
But, and perhaps I'm biased, it's still a great career path, even if it's not as flash as "code all the time" work.
But support being support ... it is eventually devalued and I chose to learn to code to move out of those types of roles.
When I moved on (through a somewhat handy acquisition and layoff and etc) some engineers reached out to me to join the support team there.... but I was done with support (and other factors).
I think if there was a stricter division between support and technical sales, there would be more of a temptation to focus on burning through support requests as quickly as possible. The flip side of this is that it is easy for us to get bogged down in a complex half-support half-sales opportunity situation and that can sometimes cause other support requests to fall through the cracks.
Parent likely established a working relationship with individual(s) in engineering organically over time, and at some point leveraged that relationship to ping them about a customer issue that crossed their path and seemed to be an engineering concern vs user-error. That didn't cause waves and went well, and got repeated enough to become an established but unofficial "thing" parent was capable of, and they became known by a few sales/account folks as the go-to person when they felt a situation may warrant that unofficial route.
You can make a career off of doing this sort of thing, but I'd caution against it. If a company is hiring for specific scenario of "fast lane between client and engineering", the actual job is "support with special escalation privileges, servicing clients splurged for the premium package". You get all the soul-crushing hell of working a normal support role, but with the added benefit of solely servicing clients that expect you to hand them the world because they paid extra for it. Which is far closer to a nightmare than a dream; particularly considering someone working one of these official roles likely has the skills to pivot out of the support org and into the engineering org in some capacity, and drastically increase their salary potential while simultaneously improving their quality of (work) life.
In a more general sense though, pretty much any career benefits from doing what the parent described. It's effectively just flexing your soft skills and establishing relationships with people outside of your immediate sphere/department. Which has a tendency to make it easier for you to get things done, and garnering a reputation to that effect.
I was a regular support drone as far as anyone knew.
I just had some connections that came about because I could be discrete and the engineers understood that I didn't bring them garbage too early (without enough information) or without good reason.
But above all: be a good listener. Listen to what they say, think about it and build it on next time you talk with them. If they see you showing interest and learning about their domain, you'll get a direct line to them. And don't always bring them problems, be sure to stroke their ego too by asking what they're working on.
It doesn't happen overnight, it requires perserverence and a dollop of luck. You won't walk into a job like that, it takes years of building a reputation for yourself.
The dark patterns used in software like AVG and avast, both making every system I see them on so slow that they might as well be unusable, are all focused on getting more installs, be it to force people into getting whatever "premium" subscription or harvesting data(e.g. attaching themselves to every sent email like a virus).
There are very few that I could actually recommend, like Malwarebytes - for most users, Windows Defender will be more than enough nowadays. I haven't used a mac in a while, do you actually need AV on them today?
Most people using only the app store helps cut that down.
https://unit42.paloaltonetworks.com/new-os-x-ransomware-kera...
>Transmission representative John Clay told Reuters via email that the ransomware was added to disk-image of its software after the project's server was compromised in a cyber attack.
>"We're not commenting on the avenue of attack, other than to say that it was our main server that was compromised," he said. "The normal disk image (was) replaced by the compromised one."
Would make it past Apple's new notarization scheme these days?
At home I have over 8 Linux machines and the only times their fans get louder are when I am actually running a video encoding program or something CPU intensive like that. Some of them are slower with only 4GB RAM and they are always responsive.
Isn’t it basically finger printing files and intercepting IO and so the resources it uses just depends on the activity of the device not the age of the CPU
Malwarebytes installs a program with elevated privileges that starts on boot and always runs in the background, and regularly sends data home - despite that it is an ON DEMAND scanner.
I have written to the company to understand this virus-like behavior, and have gotten no response.
Do you have a reason to trust them?
My reason to trust them is that they seem to be generally respected still, I've been using them for a long time and they've yet to start annoying me with dark patterns and upsells - of course that's not a super great indicator.
This is so true it hurts. Veracode releases an annual report ("State of Software Security"), part as marketing material, part as an industry insight leaflet. The worst offenders for software security and defect rate are, year after year, security products.
As an infosec veteran, it's obvious to me that the "industry" at large is not obeying the rules they set for others. The shoemaker's children have no feet.
This used to be the case, but the commercial/enterprise cloud version of MBAM (required by my company) is godawful. It seems to call out to its cloud back end every time an executable launches, and it murders performance. It's most obvious in terminals when it causes a simple command that should run in < 1 second to take 4-5 seconds.
The problem is for a lot of jobs you don't get a choice. The employer enforces it, no dark patterns necessary. And then you end up with a computer that is 70% busy doing AV-stuff and leaving 30% for actual work.
So, since we're an Apple developer, we decided we would use one of our DTS (developer technical support) tickets. Nope. Pre-release anything is not supported.
So, we ended up waiting for release, bought a new M1 mini and then started our porting effort. Then, we ran into problems and used one of our DTS incidents and we got some help. However, we lost months.
Product I used to work on had frequent false positives from antivirus software marking certain files as having some malware or whatever in it.
It's super unpleasant trying to get those changes pushed out. Glad that they were able to get some resolution quickly, usually that isn't the case, at least in my experience.
20 years ago Google would have sent someone to Mozilla HQ for a week to work on stuff
> More of a concern was user reports that some antivirus software was flagging all our Universal Binaries as malware, and corrupting the Firefox installation the moment the update arrived.
> The software was using machine learning techniques and presumably observed that our combined Universal Binaries didn’t quite look like any other legitimate software it had ever seen before.
> Attempts to contact the vendor through regular support channels were unsuccessful so we ended up searching LinkedIn and managed to find an engineer working on the core antivirus detection.
Often the expert is too valuable to give up, or is a poor choice for customer engagement. If you have a consulting team, they may lack the experience needed, or reputation, that the customer wants. As soon as you send the expert onsite, you will have a challenge not sending them at a later time. This scares off engineering managers from lending their engineers because inevitably they have to fight off the requests.
The better workflow is one where you can send a less expensive resource (however you measure it) onsite and have them work remotely with the expert. If you can stick with that you often end up with the onsite person leveling up their skills and the ability to re-engage in a scalable manner. Any engagement needs prep before the onsite, a plan for escalation when onsite, and a disengagement plan.
Edit: Apple also had to change the linker for the sake of Macromedia’s monolithic applications. Another story though.
So it's hard to tell if the size of the vendor is the issue here.
I've resolved to never, ever run A/V software on any machine I control based on the quality of those devs.
Note that there may be still ways to bypass it if you're an attacker sitting at the computer, rather than a hapless user.
If Apple wants to create incompatible hardware, let them put the effort & money into fixing the software, if they want the software on their platform.
Anyway, found a guy working on keyboard layout stuff at Microsoft through LinkedIn as the other support channels were non-responsive. Unfortunately he just confirmed the change if I remember correctly. But at least we knew what was coming.
And they are Mozilla. Imagine Indies.
The Modern Day Apple requires you to get some Mainstream Media publish about How Apple block Open Sources Software to be running on M1 before Apple saw the PR damage and start acting on it.
But Apple and Mozilla headquarters are 5 miles apart (roughly). Couldn't you just walk/drive/scoot/fly/what ever over and talk to someone?
If you knew someone and had scheduled time with them, then yeah I'm sure you could hoverboard your way over.
>"Attempts to contact the vendor through regular support channels were unsuccessful so we ended up searching LinkedIn and managed to find an engineer working on the core antivirus detection. They immediately understood the seriousness of the problem and took prompt action to get a fix shipped, thus preventing quite the disaster for the users of this product. It’s notable that without this last-ditch effort we would have been effectively blocked from releasing a native Apple Silicon version for an indefinite period."