Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In my experience, remote takes already-inefficient and error-prone workplace communication cultures that manage to muddle by with in-office workers at "merely" a significant productivity cost, and makes it totally unworkable.

The obvious solution is to fix your very-noticeably fucked up communication culture, since that would also improve in-person work.

Some orgs and managers seem to have decided, comically incorrectly, that WFH is the problem element in the above scenario, however.



You mean having 3 layers of management do a drive-by at developer desks in the space of a day, with conflicting asks is bad?

Or having the universe revolve around Jira, berating devs for lack of story progress in standup, and shouting about velocity in sprint ceremonies.. while also doing the above said verbal drive-bys? Who is causing all this churn?? Where is our focus? Where are people spending their time??

It's unknowable.


I sometimes wonder if all the time spent inputing and tracking various not-naturally-generated "metrics" is worth it. Manager and executive hours analyzing this stuff and devising systems for it and arguing over which systems to use and crafting mandates and plans, can be extremely expensive. Expensive ICs like programmers can easily lose 10-20% of their time to task-tracking and time-tracking and shepherding various things along that only exist for better tracking. Like, if we just didn't do those things at all... would productivity go down? Or up?

The cost of doing all this measuring and evaluating and preparing-to-measure certainly isn't being measured, though, so we'll never know.


Yes, and often the management instituting such granular tracking systems are also the people who want to go outside it for their own "quick asks".

It's entirely possible to construct beautiful metrics, amazing velocity charts, etc and have a terrible product with miserable users. Many such cases.

Some of this metrics stuff is like "expressed vs revealed preferences". Users who complain about your product and demand new features more quickly don't want a beautiful burndown chart. They want you to improve your product. You may actually need to slowdown to speedup. It's likely you need to do some R&D, and lots of experiments that will look bad on metrics.

You see this a lot when you quantize teams into little buckets like operations vs new features vs customer success vs core engineering teams. It's possible for a team run by a bad actor to have nice metrics while being a net drag on the other parts of the org.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: