[tenacious_tuna]

> It's harder to catch those folks...

I don't understand this; if they aren't producing what's expected of them, that's noticeable, and a problem. If they are producing what's expected of them, that's good, and what's it matter what they're doing with their time?

For the first time in my career I feel able to actually perform to the expectations set for me as remote staff. I don't have to invent busy work to do while I'm waiting on another team, I can just go do laundry.

If management doesn't have faith that their team's output is what it "should be" that's a separate problem from being in-office.

[AviationAtom]

I think it's harder to quantify realistic work outputs in some settings, especially if work outputs have been skewed in recent years by people cooking the clock. In others I think they have observed a drop in work output. With the formerly very loose labor market I don't think there was much they could do about it before, but now they see RTO as an option to rein it in. I think if both sides of the equation more consistently approached things in a reasonable manner then both sides would be better off.

[ryandrake]

I still don't understand the connection between physical presence in a building and someone's work output. If someone's work output is unacceptably down, then that person should be warned or let go, regardless of where that work is physically done. If the manager doesn't notice the low work output while remote, he's probably also not going to notice it when it's in the office. How will RTO "rein in" someone's work output? Is there manager going to use the physical presence to actually stand behind them watching them type into a computer?

[lumost]

The concern with over-employment is that many "healthy" organizations rely on trust. Someone says it takes ~4 weeks to do something, I don't want to have someone else "re-scope" the effort to verify that it really takes 4 weeks. If someone is only doing 3 days of work each week - then realistically this task could have been done in a little over 2 weeks.

On a long enough time horizon, someone will pick up on this and perceive the engineer as "slow." If multiple people are doing this in the team - then the org is probably in trouble.

[ryandrake]

For a lot of things, especially in bigger companies, a programming task could take 4 weeks, where the coding is only 2 days of work. The rest is spent on writing docs, ticking checkboxes in some internal release tool, and waiting, waiting, waiting for approval from code reviewers and multiple gatekeepers. I've seen a 5 minute programming task take a month to deploy because the privacy and legal approvers were on three week vacations, and the project couldn't go live until their feedback was given (and possibly resulted in code changes).

[lumost]

Sure, but usually these things can be accelerated if you are blocked and can't do other work. It's usually expected that you are doing other work while waiting, be it ops, reviews, invention/simplification, design, coding for other projects, or networking with coworkers etc. It's not uncommon for a firm to be amendable to spending some portion of time on outside activities such as education, event planning, or (sometimes) a side business/startup.

If everyone is spending 5 minutes working every 4 weeks... why would you hire extra people outside of contingency coverage?

[simoncion]

If everyone is spending 5 minutes working every 4 weeks... and your company isn't paying for "hurry up and wait"/hot-standby personnel, how the fuck did your company mismanage things so badly so that they're paying their people full-time programmer rates for 60 seconds of labor per week?

If my workload is such that I can work four "full time" jobs and every one of my employers is happy with my work product, then that's nothing but great for everyone.

[collingreen]

If the work doesn't produce a viable business then the org is most certainly in trouble no matter where people are.

If the work does produce a viable business and management just wants to squeeze more out of people then I think it is a different problem.

I agree a good business operates on trust. I also agree with other posters that the current business norms of mass layoffs during record profits, PIPs, "managing out", clawbacks, and all the other abuses have clearly shown the trust isn't there the way folks claim "the good old days" used to be.

I dont think lying about your employment, intentionally sandbagging, or cheating your employer are ethical behavior but I sure see why folks feel like being the nice guy is a surefire path to exploitation.

I personally would like to see a normalization of very different employment contracts that do a better job of balancing the two sides. I assume this means a return to strong unions (although plenty of issues there as well; certainly no silver bullet).

tl;dr With "make us enough profit and we'll probably fire you tomorrow" always looming over your shoulder I understand why loyalty to a company has dried up.

[closeparen]

I just had what should have been a one-hour task grow to consume most of my focus time for the week, due to hitting a perfect storm of internal platform bugs and getting caught in an edge case straddling the branches of a cloud migration.

Everything in software engineering is like this. You never know when you're going to stumble into a rat's nest of unexpected complexity. Should I be on the hook to pull 100 hours this week in order to maintain a normal pace on my tickets despite the snafu? Of course not, that's ridiculous. At the same time, there is no way for my skip to verify these types of stories across 100 reports.

[caf]

I think if both sides of the equation more consistently approached things in a reasonable manner then both sides would be better off.

Replace "reasonable" with "trusting" and this is literally a restatement of the Prisoner's Dilemma.