I'm genuinely interested in why RTO is trending. I searched Harvard Business Review, Gartner, and other sources just last week trying to find the rationale, but I wasn't successful. In fact, I found those sources to be a little cautionary. E.g., they say "if you do switch to in-office or hybrid, make sure you actually have metrics to evaluate the effects" and "ensure it makes sense for the actual work to be done by each role".
I also found results suggesting flexible working policies had positive properties like higher employee satisfaction, retention , and a wider applicant pool.
I'm not interested in hearing why the choir here at HN thinks companies are making these decisions, I want to see evidence of their rationale so I can put myself in management's shoes.
I was also studying many MBA books about decision making in corporate environments. Many cool things about data driven decision making. Costs and alternative costs, etc., many cool things, some even with scientific background. RTO is also analyzed in similar manner. The truth is that RTO is great way to ditch people with longer commute and/or kids easily and for free.
And unions (as they’re in Germany) are happy.
But let’s get back to reality, the business decisions are made in the style “I like this” and “I don’t like this”. Only most obvious decisions are somehow backed up. And RTO is known to work well to ditch 2-3% of workforce in few months for free. Parents go first, high performers go afterwards. Headcount reduced, job well done!
The way with severance packages can go for years with many rounds when the packages are too small. Severance packages also involve social plan negotiations with unions… Somebody will go to court for sure and sue the company… So obviously let’s do RTO, it’s cheap and quick. And improves collaboration of course. First round with mandatory 3 days in the office and second one with 5 days in cheapest possible open office with chaos, distractions and noise.
I think, two rounds of RTO reduce headcount by 4-6% and the company is still functional. Work packages are delegated to the folks who stay. Few months later lost key persons get replacement. It’s not like throwing 2/3 workforce and concentrating on core business.
The problem is that proper studies on this topic will take years to really understand the positives and negatives of having the majority of your employees working remotely. --Researchers need to be able to track people through their careers to understand whether or not WFH is a net benefit to them and/or their companies.
So you're really going to have to deal with only hearing what people think.
RTO is trending for many reasons - some are doing this for bad reasons, I'm sure, but I also know that some managers are pushing for this because they a) see that junior developers aren't getting the necessary mentoring to help them develop and grow into seniors, and b) because they feel that people are spending more time on tasks because they're less likely to reach out if they have to ping people, wait for a response, and try to work through things without benefits like being able to draw on a whiteboard and such. --Maybe some companies are handling this better than others, but they are valid concerns.
To be clear, I'm not wishing for evidence of whether RTO is good or bad.
I want evidence that proves "it's about cheap layoffs" or "it's about real estate" or "it's because they want to monitor people" or "<insert any speculative reason on this thread>"
Once we have evidence"it's about layoffs" then we can debate whether it's ultimately helpful or harmful to cull headcount that way.
Depends what sort of contract they have (and/or how much perceived leverage they have - firing high-income workers who have a public platform can make for messy PR)
It is likely too late for many existing contracts with packages built-in, which probably also overlap with the longest-working (and thus most expensive) engineers.
It's also a dumb strategy because the good people will easily find another job and leave and you end up with office full of the least competent employees.
But yes I'm pretty sure this is a big part of the reason for these mandates.
From what I've seen (at a fortune 100 company) they made the supposedly "best" employees fully remote, and they neglected to tell the others that there were "limited slots" for fully remote and thus they had to come in to work. After a few months of coming in for work, they then laid off those employees, as not enough people quit for that to happen. To be fair, I was given a severance, but it still sucks. And the office was in bad shape, bathrooms poorly maintained, cafeteria in disarray, with substandard food (compared to before). The reason they're trying to get rid of employees is to make their stocks look good. We did better during covid by all measures, when everyone was working remotely.
I've long suspected it's got to do with office real estate.
You spent $10m or $100m on a building that's now half empty.
Either you downsize or commit to enterprise scale sunk cost fallacy and enforce RTO so your real estate investment isn't "wasted".
City centres also thrive on RTO, with high street shopping on a generational decline it's up to office workers and their employers to prop up the economy of the CBD one overpriced lunch at a time.
The city centre / real estate thing sounds like an externalisation - which companies famously dont give a shit about.
It should be a tradegy of commons at best: it may affect the CEOs 401k, but not by much (0.000001% for their individual decision to RTO for that company y). It like buying McD shares then going to McD for lunch every day with your team.
Most companies, at least in the U.S., don’t own their offices. They lease them.
In fact, a whole bunch of office leases were supposed to be expiring in 2024/2025. If this was the reason RTO wouldn’t be picking up right now since they would be cutting back and ending their leases.
I feel that companies still misunderstand how to evaluate these metrics they're collecting on the efficacy of RTO.
IMO, RTO efficacy should be measured on a team-by-team basis. There are no doubt zero "one size fits all" approaches for entire orgs, or entire companies (and if there are, then the metrics should /strongly/ reflect that)
To actually measure efficacy of any measures, you need to implement them in isolation. It is really hard to evaluate how working from home is affecting productivity while simultaneously doing mass layoffs and pushing people to replace their fired collagues with AI
> I want to see evidence of their rationale so I can put myself in management's shoes.
I think worthwhile evidence would only be available if two things, both questionable, were true:
1. an unbiased sample of companies implementing RTO are willing to disclose their reasons - e.g. make public announcements, or cooperate with academic studies.
2. they were honest about the reasons.
If common reasons for RTO would make the management look bad (and some might even be illegal in some places) then the first is less likely, and the second is highly unlikely.
You'll probably get better results than the level of Sloan from the NY Fed, the AEA or Glass Lewis. They point out that profit-seeking strategies outside of the concept of ordinary business[1] can exist on a spectrum from highly ethical to highly unethical, ideally[2] all pursued simultaneously in proportion to their risk.
[1] e.g. through leveraging class politics, hyperstition or militias.
[2] From the point of view of the responsible stakeholders, that is.
Of the information I have reviewed brain storming / creative sessions are better in person versus online sessions. This does lend to hybrid approaches being useful. All other metrics were better or had no difference.
One point I did note is that there is an increase in management overhead when workers are separated, and this increase in workload by senior management is likely a pain point for them - even though there are likely productivity benefits in forcing management to communicate through official channels and have a more organised approach to task delegation/internal messaging.
From a financial perspective office spaces are a type of investment vehicle. Prior to the GFC office space was lucrative, and that was again peaking pre-covid.
There are likely secondary motivations at play beyond productivity.
I might be too late for you to see this, but I'm curious why your final example requires the function "f" to receive the canWrite channel. I must be missing something. Couldn't the Ordered map signature be:
func OrderedLoop[A, B any](in <-chan A, done chan<- B, n int, f func(a A))
Instead of:
func OrderedLoop[A, B any](in <-chan A, done chan<- B, n int, f func(a A, canWrite <-chan struct{}))
Or is there a reason that "f" can't be wrapped in an anonymous function to handle the blocking logic?
You're not late. Just yesterday I've configured new reply notifications via RSS.
Typically function "f" does two things. 1. Performs calculations (this can be parallelized). 2. Writes results somewhere (this must happen sequentially and in the correct order).
Here's the typical OrderedLoop usage example from the article:
OrderedLoop(in, out, n, func(a A, canWrite <-chan struct{}) {
// [Do processing here]
// Everything above this line is executed concurrently,
// everything below it is executed sequentially and in order
<-canWrite
// [Write results somewhere]
})
Without the "canWrite" the entire body of the "f" will be executed either concurrently or sequentially. With it - we can have this dual behavior, similar to critical sections protected by mutexes.
It's worth mentioning that OrderedLoop is a low-level primitive. User-level functions like OrderedMap, OrderedFilter and others do not need the "canWrite" channel to be exposed.
Yeah, people are being snarky and saying it's obvious, but it was new to me! I guess I'm not staring at base64 all that often. It's a neat trick though, now I'm going to pay attention next time I have an opportunity to use it.
Offline is good for things like your ball sort game or a calculator. But the developers of that sort of thing want to make money, so they sell apps in the app store.
Offline order history is only a marginal improvement on the e-commerce experience from a customer and business perspective, so it's more appealing to us engineers who appreciate it as a feat of engineering prowess.
In other words, offline isn't PWAs killer feature. Besides, native apps can do it too.
PWA's killer features are circumventing the app store and the app store tax and not maintaining two codebases for Android and iOS.
Another Hacker News client would be a good example of a good PWA that you might install to your phone. It could have niceties like "save for later" or special styles applied to your favorite commenters. Offline support would be useful too, of course but not the main reason to develop a PWA.
Uncensored, paid content is another significant use case.
The authors write that it's "counterintuitive " that in states with low crime and efficient beaurocracies, the uberrich tend to conceal or relocate their wealth more. See:
"This suggests a counterintuitive result: use of offshore finance is driven not only by negative political conditions such as corruption and lack of civil justice, but by positive conditions, such as regulatory enforcement and civil justice."
But it's not counterintuitive at all. Those people aren't concerned about getting mugged and they're definitely not concerned about how long it takes to get a construction permit in a corrupt country. They're concerned about state-sponsored expropriation.
Given so many of the comments here about tracking the offshore accounts down and confiscating the contents, it's no surprise.
Irrespective of whether their practices are immoral, unethical, unfair, or unjust, they're definitely not counterintuitive.
It's genuinely hard for me to understand how the authors could believe otherwise.
I'm intrigued as to the framing of your post. You seem to be positing that it's entirely expected and understandable that wealthy individuals in well functioning systems should commit fraud to the detriment of the system that brought them their wealth. That seems counterintuitive to me, at least.
If we're talking about wealth not income, then no, not really. We don't usually think of asset seizure as "taxes". In other words, one "taxes" flows (like capital gains and wages) and "siezes" stocks (like bank deposits and equity).
"You seem to be positing that it's entirely expected and understandable"
I wasn't making value judgement, but yes, if you look at it with the assumption these wealthy individuals are cold, calculating, self-interested actors, then it's "expected and understandable" to me.
"That seems counterintuitive to me, at least."
I think you're using "intuitive" as a shorthand for "the way things ought to work in a righteous world", where I find incentives and disincentives to be a more intuitive way of understanding the world.
"wealthy individuals in well functioning systems should commit fraud to the detriment of the system that brought them their wealth"
To be fair, it's not necessarily fraudulent to have offshore accounts or to conceal your identity (it can certainly be depending on the circumstances). Technically I have an "offshore" account, I just happen to be living outside the US and a US citizen. I also use mechanisms to conceal my identity when registering domain names, for example. Is it the same thing, no, but these people might not technically be doing anything illegal.
It isn't necessarily true that those systems "brought them their wealth" either. Plenty of them likely inherited wealth that was accumulated long before the current systems were put in place (granted, it could very well have been accumulated illegitimately 300 years ago).
(Again, I'm not saying any of this is how the world should work, I'm trying to look at the world dispassionately and describe how things seem to be)
At the level of wealth we're discussing, these individuals probably have to think about "diversifying" among nation-states. Instead of worrying about whether to short the tech sector, they're worried about a country being invaded and the new puppet regime deciding to nationalize the hydroelectric dam they financed. Or they may be worrying about whether their country of residence will pass a law that the biggest national telcom must sell the government a majority stake (i.e., their share) at a government-mandated price denominated in an inflating currency... with expert bureaucratic efficiency.
Nope. Legacy protection. Protection from state seizure and civil forfeiture. Protection from nationalization. Protection from a spouse or even your own children. Protection from takeovers of family businesses and assets.
There are a number of reasons why we might use offshore companies and apparent tax havens - while the taxes are an added sweetener, the main reason is that there is often concrete rule of law in these jurisdictions.
Did you know that for Russians and Chinese, the US is a tax haven? As long as you're not a US resident, you only pay US taxes (which can be easily optimized to be far below Russian or Chinese taxes). You enjoy a high degree of anonymity. You also get to gamble in the biggest equity markets of the world, which are backed by a strong financial system eager to lend you gambling money based on your assets.
Compare that to Russia, India or China, where your assets can be seized at a moment's notice, on the whims of some pencil pusher bureaucrat or judge.
> If you are building a public API for external developers you don’t control, invest in HATEOAS. If you are building a backend for a single frontend controlled by your own team, a simpler RPC-style API may be the more practical choice.
My conclusion is exactly the opposite. In-house developers can be expected (read: cajoled) to do things the "right" way, like follow links at runtime. You can run tests against your client and server. Internally, flexible REST makes independent evolution of the front end and back end easy.
Externally, you must cater to somebody who hard-coded a URL into their curl command that runs on cron and whose code can't tolerate the slightest deviation from exactly what existed when the script was written. In that case, an RPC-like call is great and easy to document. Increment from `/v1/` to `/v2/`, writer a BC layer between them and move on.
The thing to internalize about "true" REST is that HN (and the rest of the web) is really a RESTful web service. You visit the homepage, a hypermedia format is delivered to a generic client (your browser), and its resources (pages, sections, profiles, etc) can all be navigated to by following links.
Links update when you log in or out, indicating the state of your session. Vote up/down links appear or disappear based on one's profile. This is HATEOAS.
Link relations can be used to alter how the client (browser) interprets the link—a rel="stylesheet" causes very different behavior from rel="canonical".
JavaScript provides even provides "code on-demand" as it's called in Fielding's paper.
From that perspective, REST is incredible. REST is extremely flexible, scalable, evolvable, etc. It is the pattern that powers the web.
Now, it's an entirely different story when it come to what many people call REST APIs, which are often nothing like HN. They cannot be consumed by a generic client. They are not interlinked. They don't ship code on-demand.
Is "REST" to blame? No. Few people have time or reason to build a client as powerful as the browser to consume their SaaS product's API.
But even building a truly generic client isn't the hardest thing about building RESTful APIs—the hardest thing is that the web depends entirely on having a human-in-the-loop and your standard API integration's purpose is to eliminate having a human in the loop.
For example, a human reads the link text saying "Log in" or "Reset password" and interprets that text to understand the state of the system (they do not have an authenticated session). And a human can reinterpret a redesigned webpage with links in a new location, but trivial clients can't reinterpret a refactored JSON object (or XML for that matter).
The folly is in thinking that there's some design pattern out there that's better than REST without understanding that the actual problem to be solved by that elusive, perfect paradigm is how you'll be able to refactor your API when your API's clients will likely be bodged-together JS programs whose authors dug through JSON for the URL they needed and then hard-coded it in a curl command instead of conscientiously and meticulously reading documentation and semantically looking up the URL at runtime, follows redirects, and handles failures gracefully.
I also found results suggesting flexible working policies had positive properties like higher employee satisfaction, retention , and a wider applicant pool.
I'm not interested in hearing why the choir here at HN thinks companies are making these decisions, I want to see evidence of their rationale so I can put myself in management's shoes.