I guess if you keep setting OKRs like "5% lower support call volume" for years then at some point your reputational risk goes up because you've made it impossible to contact an actual human being.
A bug plus shitty automated support with no human in the loop is an intentional product decision. They could have humans in the loop. They could have human support. They could make bugs like this more easily remediable. But they don't. On purpose. To the extent that their "fare review process" and the app failed. Now it's going to be fixed by some PR person. Because it's still cheaper, apparently, than the alternative design decisions.
This outcome is a result of their intentional product decisions.
One is an emergent consequence — the "banality of evil", a property of the corporation itself. The other is active malfeasance — something that's not so much even about the corporation as about an individual horrible person in a decision-making role, where the correct move for customers/employees is to boycott the decision-maker, rather than the company; and where the correct move for the company is to fire the decision-maker, and distance themselves from them as much as possible. (Unless it keeps happening with different people in the same company, at which point it becomes a thing about the company's culture.)
Companies can be evil on a structural level. But also, companies that aren't evil on a structural level, can be parasitized by evil individuals. Unless the company actively pursues hiring evil individuals, why would you hold the latter against them?
The point of companies having reputations is to predict what they'll do, and thereby trade with companies for which trade with them will predictably be positive-sum, and avoid trade with companies that would predictably be zero-sum or negative-sum.
A company itself being evil on a structural level, predicts that in the future it will do many zero- or negative-sum things, regardless of employee turnover.
A company that is not evil on a structural level, hiring one evil individual, who does an evil thing and then gets fired, doesn't predict any future evil behavior from the company.
It's what would be true for the situation outlined in the root comment of this subthread to pertain: that it was "an intentional product decision."
For that to be true, there would need to be an individual that made that decision, with the thought-process I outlined in my first comment. Such a thought-process wouldn't just be sociopathic (zero-sum), it'd be negative-sum/"evil". It would be a choice to hurt both drivers, and the corporation itself (when people inevitably find out), and oneself (when blame is inevitably pointed at them.) For what? Who knows. Evil. (Industrial sabotage, maybe.)
Obviously, like another commenter said, this wasn't an intentional product decision. (It was maybe an intentional project management decision, but one made in by no one individual.)
But that same commenter rhetorically asked why it mattered whether it was an intentional product decision or not. That's why I explained the difference. Acts of evil individuals that have parasitized good companies shouldn't reflect on those companies (once the evil individual is removed.) Acts of structural evil — acts that are generated from an algorithm the corporation is following as a whole, and would still follow if you replaced every employee ship-of-Theseus style — should reflect on the company itself.
This, of course, is an example of the latter kind of act, one that should reflect on the company itself.
But it's important to distinguish these acts from acts that are, in fact, committed by bad actors that have "infiltrated" the company. For the same reason that we distinguish "terrorism" from "domestic terrorism." The latter — domestic terrorism — can, in some ways, be "a reflection of the culture of the country." When there's a school shooting, we can ask what the country is doing wrong that leads to people like this cropping up. But the former — plain old terrorism — is not, and cannot, reflect on the country. The person who committed the act wasn't even an enculturated citizen of the country, so what would it tell us about the country?
It won't be long before we have a daily post here on HN called Killed by Algorithms, and every story will be different.
It's terrifying because it illustrates the lack of trust that the general public has in tech. Instead of "looks like someone's having a bad day at the Uber office, guess they'll fix it soon," it's a plot trialling a new form of exploitation. Two replies in, someone wants to nationalise the company. That's a lot of lost trust.
In other words, technology is bringing scale and leaving the cost of the rounding errors to the most vulnerable.
I'm not saying it's unexpected, I'm remarking on adverse market conditions that will affect most of HN.
I have never used Uber, doordash or anything like these. On purpose. Even when given free Uber eats vouchers at work (covid...). They still seem to be winning.
- Some engineer will get paged, look at the incident, and eventually the root cause of the bug will be found.
- The root cause of the bug will be fixed to prevent it from happening on new trips, new fare calc tests will be added, etc.
- Engineers will identify which commit introduced the bug and which dates/trips are possible affected.
- Someone will run a batch job that recalculates fares for all of the trips that might be affected, and payments will be made to any drivers who were underpaid.
A lot of the people in the comments here are reacting negatively to the fact that support tickets are partially automated. However, there are a few things to note.
The first is that fare calculation code is very complicated, it involves lots of geofence calculations (e.g. to detect toll roads or bridges) and in some cases there are other location-dependent rules, various promotions may be running, etc. The only people at Uber who are qualified to determine whether or not there is a fare calculation bug are the engineers who actually work on fare calculation code. Sometimes there are obvious errors (like in this example), but in most cases the fare calculation bugs are subtle enough that support agents wouldn't actually be able to verify if the code is wrong. Even if the support person could tell there was an error (as in this example) the best they could do would be to escalate the issue to engineering and wait for a fare calc engineer to investigate.
Additionally, besides support tickets there are a lot of other monitoring systems that look for abnormal deviations in number of trips happening, fares, etc. If there is a major bug affecting something like fare calculation it will show up in these metrics and someone will investigate.
I don't work at Uber anymore so I don't know the specifics of how this bug was handled. But in general I would say that bugs do happen sometimes, and Uber has policies that seem reasonable (to me) for detecting the problems and correcting any erroneous payments made.
It might be a "bug' from uber's perspective. For we mortals they interfere with basic economic functions. When my grocery store overcharges me for something they can can push a fix to me within seconds. The customer service person doesnt need an engineer to see that potatoes shouldnt cost that much. And they are empowered to correct the error immediately, with cash in hand if necessary. Nobody at uber has such power.