I wonder if it's the platitude doing that, or the explicit affirmation that _most_ of it looks good, but just XYZ needs tweaking. That intention is explicit in the first message, and potentially implied but unclear in the second.
755 karma · joined October 9, 2014
It follows that founders (or employees who were early enough to have a founding mentality), often, tend to care more about their products and services than anyone else will and this can lead to centralized decision making being highly effective. This is the case for Steve Jobs, Bill Gates, Howard Schultz, Brian Chesky, and Elon Musk (please set aside any recent personal opinions of him).
It also follows that "manager" CEOs and senior leaders are often hired into a role with different incentives that relate far less to them caring about the product, customer, or business, and more to the movement of specific metrics. In these cases, centralized decision making can lead to deterioration of a product experience to the point of irrelevance. This list might include Scott Thompson (Yahoo), Dennis Muilenburg (Boeing), etc.
I don't believe it is anything inherent to a "founder" or "manager." Simply put: centralized decision making can be effective in an organization where the centralized decision maker has the insights and is close enough to the customer and market to make good decisions. It can be massively detrimental if the person is detached from the customer and market.
It is just the case that a founder happens to be much more likely to be close to the customer and the market than a hired leader, and likely has much more of a desire to be so.
This might be wrong, but it has tracked in my career so far. I've seen great managers, horrible managers, great founders, and horrible founders. The only thing that has been consistent is that the great ones are _far_ more likely to deeply understand the customer they serve and the product they build than the bad ones.
To be clear, I’m not defending the system either. It’s fundamentally broken by design. But it’s certainly not solely the greed of hospitals that got us here.
Hospitals and payers negotiate rates and contract at that rate before the service is provided. Assuming the service is not denied by the payer, the hospital knows that they'll only be reimbursed 18k from your insurance company (or at least has the data to know in advance, putting aside whether any one person could tell you what it will be). The 90k only served as a starting point for negotiation with payers and is usually obscenely high due to other regulatory and contractual reasons related to the negotiation process. Their "list rate" is shown on your bill, but was absolutely never expected to be received.
As a result, it's not a "loss" of revenue at the time of service, and isn't recognized as one.
Now, because GAAP requires revenue be recognized when realized and earned, that service became "revenue" to the hospital after service, even though they haven't been paid. They might later "write that off" (I.e. recognize a loss) if the payer ultimately denies that claim, or you refuse your responsibility (I.e. your copay). But in that case, the hospital did not, in fact, make the money.
The scenario you mentioned is generally understood to be permissible, but it's not exactly clear to me why. Perhaps that the information became "public" (whether intentional or not) when discussing it in a public forum such as a coffee shop?
But, yes, all of these shorthand definitions are designed for the general public's consumption, and skip over specific nuances - including the SEC's definition. The sentence read above would seem to permit a person with a fiduciary duty to share information with someone who does not have one, and for that person to trade based on the information. However, we know this is not permitted.
In any case, I think my comment still stands. I specifically called out in my parenthetical in the original comment that the information would need to be knowable only by those with a fiduciary or confidentiality obligation to the company. This seems to cover your comment and sibling's concern.
Regardless of the level of fidelity, if you got that information from an unaffiliated third party entity who captured it in the delivery of their own services, it is not "only available to those with a fiduciary responsibility or confidentiality obligation to the company"
It sounds like we are saying the same thing and you don't feel my original comment was clear enough. That's fine feedback. But there's no substantive disagreement. The points you listed above are all fine to trade on.
Further, I struggle to understand how one could learn information which is non-public without "theft" of that information. It would seem that, by definition, if the organization begins sharing that information with individuals who have no confidentiality obligation, they have now made that information public.
What does tend to happen often is that others assume "public" means "written in the news" and that is certainly not the case. There are plenty of things that are knowable by the public but not obvious, and it's perfectly fine to trade on that.
I was trying to avoid the use of "insider," because people tend to assume that means employees or directors, but that is not the case. Outside organizations who have, as an example, signed an NDA with the organization may learn of material non-public information, and trading on that could constitute insider trading.
Regardless of when you learned it, the quality of BMW's cars (in this example) became public information when they started selling them to the public.
Now, however, if an internal employee told the technician that BMW had removed all QA checks from their line, and (s)he should expect quality to fall precipitously in the years ahead, that would be different.
The link you referenced also clarifies this point, but it is different from what is written in your comment.
Note: this doesn't change the fact that the answer in this particular case is no, it's not insider trading. You are, as parent mentioned, just the first to know the news.
It also had the nice benefit of forcing people to store actual knowledge in Notion where it could be organized and more easily discoverable.
Anyway, all this to say - there are many reasons to purge slack history that aren’t nefarious (even if the practice is ill advised by some)
But beside that point, Facebook has been able to force side loading on Android for years and still distributes via the Play Store, so that’s probably at least some evidence that they believe that distribution channel to be worthwhile.
But this concern requires a few things to be true:
- An alternative app store is created that does not employ any form of restriction to protect users from this
- Legitimate apps that an end user needs see value in publishing themselves on this alternative app store
- There is a critical mass of users that prefer the alternative app store, such that the legitimate app publisher no longer sees value in publishing to Apple's app store
- As a result, those users who would have preferred the privacy and safety that Apple provides are now forced to use the new app store
This is a possible doomsday scenario, but it's not clear to me that enforcing and protecting a market in which Apple is effectively guaranteed a profit on everyone else's apps is the right solution? If this were to happen, perhaps we address those apps through direct legislation that targets user privacy, akin to what the EU has started to move on? Or a solution similar to this.
Feels like we keep trying to look for a conspiracy when in reality that answer might just be that leaders believe their teams to be more productive in office
(Note: I'm not saying I believe this to be true, that there's evidence for this, that it's right, or anything else along those lines. Just that the most plausible explanation is that people asking for RTO believe it's going to make the company more valuable, not their commercial real estate holdings.)
It seems like making others aware of how much the two party system is harming societal progress is important, so we can start making decisions to inch us closer to where we want to be, rather than continuing to fall victim to the status quo.
If you eliminate terms like "medicare for all" or "socialized medicine" and just ask people if they believe someone's access to care should be limited based on their financial situation, most people would say no. We often agree on the crux of the issue, but disagree on the mechanics of how to get there. But when we try to force people into binary solutions it's either "the people for socialized medicine" or "the people against socialized medicine" and that's a guaranteed downward spiral.
From an end-user's perspective, there's very little difference between "the task didn't work" and "the task worked, but took longer than your patience to wait." Both appear to be broken.
Most software engineering is about making sure the happy path works well. When lives are on the line, you need to also plan to minimize the possible damage that can happen when things go wrong.
[The above does not necessarily apply in highly regulated industries or where lives are on the line]
But more importantly, once you've fixed the "show-stopping bugs," putting the software in front of customers is probably the best next step, as even if it's bug-free, that doesn't mean it solves the problem well.
Or, rather, perhaps it would make more sense to say they "got it different" than a human probably would, who might clarify that you intended to compare a thing to itself or simply say "They're identical, so they weigh the same" or something of that nature.
Instead, the models all explain volume, density, etc which are applicable if you're comparing feathers to lead or steel (as is common in their training data, I'm sure), but doesn't make as much sense in this specific question. Yes, yes, I realize different bundles of 1kg of feathers could have different volume and density. But it seems clear that's not the intent of what the models are communicating.
Typical consumers have no way of ensuring their UI is, in fact, encrypting the data and not farming it out. They cannot verify the source code themselves, because they don't have the technical skill set they'd need to do so (nor, frankly, the time). They're reliant on the goodwill of whoever packaged and installed the offering for them not doing anything to that offering.
Technical power users can circumvent this because they can build/install from source, verify keychains, read the source, etc. Non-technical users can't do this, and need someone to help them. That someone will most likely be in the form of a third party organization that does this in exchange for money. They're placing their trust in that third party.
The point I'm getting at is that, eventually, a consumer has to trust a third party who may have incentives that don't align with their own. They're just playing a game of which vendor to place that trust in. This is why centralization is still the predominant architecture choice for the overwhelming majority of products, even in a world where myriad decentralized solutions exist for almost everything. It turns out that having bespoke third parties run decentralized solutions for customers is often not a better product experience, and still has the same root problem even if it manifests in different ways.
2) Even if the above were not true, at that point you're back to an internet enabled smart home device system, and now we're simply picking which vendor to trust over the other. But in both cases, the option for the vendor to collect telemetry data about your usage of the products exists.
There is really no viable way for the typical consumer to be able to both have a good product experience for something like this, and to prevent a cloud vendor from having access to their data. Unless I'm missing something obvious.
Having options like this is great for powerusers, but the vast majority of people are not that. They need something that just works. Of course that still doesn't mean they need their garage door collecting telemetry data, but they need something more than a LAN-connected smart device.