5 ms·
> 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
by tenacious_tuna 2y ago
> 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 2y agoI 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 2y agoI 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 2y agoThe 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 2y agoFor 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 2y agoSure, 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 2y agoIf 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.
- lumost 2y agoThis is the reason that consultants often get paid ridiculous hourly rates, and in-demand consultants may overbook. So far, my experience has been those that are likely over-employed - tend to be poor workers. I might be "ok" with their output because I can't tell if they are still ramping up or what else is going on. Again, high trust environment.
- deleted 2y ago[deleted]
- closeparen 2y agoI 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 2y agoI 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.