[ChuckNorris89]

I tried sharing these studies at my ex employers in Europe hoping they'd spare me the hellish 40 minute commute in stop/start traffic and they weren't interested at all.

Management there only values "butt time in seats" and the ability to come over and interrupt you by tapping you on the shoulder whenever they need something.

As one of my ex CEOs put it: "If I don't see my employees stressing out at thier desks I get the impression they're not working."

Until we get over this psychological attachment of management loving to visually see their slaves on the open office plantation through their private panopticon[1] offices, remote won't take off no matter how many studies get published.

[1]https://en.m.wikipedia.org/wiki/Panopticon

[fizx]

As someone who has gone to the dark side, there's an interesting tradeoff here. There's basically three scenarios:

(1) all employees are trusted and unmeasured, but you have to tap people on the shoulder every once in a while to confirm that they're on track. Naturally, this is easier if everyone is on-site.

(2) everyone is accountable for producing of tickets, and you can check that everyone is at least doing some work. Check-ins can happen via comments in tickets.

(3) Everyone just does whatever they think they're supposed to be doing, and the manager only finds out something is wrong when the employee volunteers the information or the project isn't delivered on-time.

(1) is the common case, (2) requires time and skills many managers don't have (and creates @#$% Jira commentary form the peanut gallery), (3) requires building an excellent team with years of mutual trust between them, and still goes wrong all the time.

Seeing you at your desk working, and asking a casual question or two at the water cooler is by far the easiest (laziest?) way to make sure things don't go too far sideways.

[ergothus]

> (1) all employees are trusted and unmeasured, but you have to tap people on the shoulder every once in a while to confirm that they're on track. Naturally, this is easier if everyone is on-site.

I don't get it - shouldn't one-on-ones and regular progress check-ins (be those standups, metrics (This is your #2), whatever) give you that information? None of those are easier when on-site. In fact, given today's move towards open offices, any form of 1:1 collaboration is easier remotely where you don't have to fight for precious meeting room space.

I think the core problem is that you're trying to prove "everyone is working" when we should be interested in "the work is getting done". Seeing that everyone is working doesn't actually mean progress is getting made. If you have to take steps to answer that question anyway, the first question is fairly pointless.

[davidjnelson]

It really depends on the communication styles of people. I had a manager I loved that would drop by every few days and just ask “how’s it going”? Then I’d fill him in. It was fun and low key and highly productive.

Also had managers that were basically invisible but kept a great crap umbrella for us. Loved them too. Ended up working a ton and getting enormous amounts of work done because trust and autonomy are huge.

I think the worst situations are when managers are too insecure to be honest with direct reports. That’s decidedly uncool and super ineffective.

Also, it seems managers get so overloaded that 1 on 1s and stand ups end up being mostly a waste of time because it’s too hard to remember all the little details.

So remote or in office isn’t really the issue. In my view, remote is superior due to productivity, flexibility and happiness, but it does require everyone to do regular video chats and pair programming.

Ironically, the in office folks have the hardest time with this because they feel they need to get up from their desk and find an overly booked conference room as you mentioned.

Simple solutions are context dependent, but could be along the lines of a) work remote if you have the discipline, b) asynchronous slack based standups, c) report status as you go in your tickets, d) every day or two peers and managers sync up 1 on 1 or in person depending on their preference, e) have clear goals as a company and a team, f) have good technical product people writing 1-3 day user story tickets including completed designs if it’s ui work, g) have good tech leads writing 1-3 day technical improvement task tickets, h) vote as a team on contentious technical decisions, then disagree and commit, i) generally chill out a bit and let work be enjoyable.

At least that’s a start...

[ergothus]

> I had a manager I loved that would drop by every few days and just ask “how’s it going”? Then I’d fill him in. It was fun and low key and highly productive.

> Also, it seems managers get so overloaded that 1 on 1s and stand ups end up being mostly a waste of time because it’s too hard to remember all the little details.

I'm not sure how the first quote doesn't count as a 1:1 - the goal isn't to have a highly formalized process, it's to have communication. Some about the specific work, some about general work and workplace, but communication.

Total agreement about the overloading of management though - I haven't had a boss in years that didn't regularly have most of their schedule booked and often double-booked. I had to fill in for my manager while he was on vacation for week and it reaffirmed my lack of desire to do management - and I only had to deal with pieces that couldn't wait a week! I sometimes think the recent shift to focus on regular management 1:1s is all about reclaiming enough time to actually know what their team is doing.

[davidjnelson]

> I'm not sure how the first quote doesn't count as a 1:1 - the goal isn't to have a highly formalized process, it's to have communication. Some about the specific work, some about general work and workplace, but communication.

Yes, you’re right, I guess those were a form of 1 on 1s :-)

> Total agreement about the overloading of management though - I haven't had a boss in years that didn't regularly have most of their schedule booked and often double-booked. I had to fill in for my manager while he was on vacation for week and it reaffirmed my lack of desire to do management - and I only had to deal with pieces that couldn't wait a week! I sometimes think the recent shift to focus on regular management 1:1s is all about reclaiming enough time to actually know what their team is doing.

Absolutely! It’s wonderful to have empathy for this! :-D

[hobofromabroad]

> > (1) all employees are trusted and unmeasured, but you have to tap people on the shoulder every once in a while to confirm that they're on track. Naturally, this is easier if everyone is on-site.

> I don't get it - shouldn't one-on-ones and regular progress check-ins (be those standups, metrics (This is your #2), whatever) give you that information? None of those are easier when on-site. In fact, given today's move towards open offices, any form of 1:1 collaboration is easier remotely where you don't have to fight for precious meeting room space.

This is not quite the case everywhere. We have agile 5-8 person offices and people are still supposed to walk out for longer phone calls occupying one of the smaller meeting rooms.

But I actually like that different teams can mix a lot easier.

[ergothus]

> But I actually like that different teams can mix a lot easier.

I've heard this claim for open offices a lot. I never understand it. It's not like I'm AGAINST easy collaboration. But I spend (or try to spend) more time on my own, and everyone "collaborating" around me and expecting that I can turn off my peripheral vision and hearing with a brain that is hardwired to NOT ignore those things just makes the majority of my time worse.

Plus, in the last 20 years and 5 companies (spanning 8 offices if you count office moves) I've never had adequate meeting room space (defined as: We need a space to spontaneously talk without disturbing others, can we find it trivially?) for more than a 3 month span after moving to a larger building. Hardly scientifically conclusive, but personally persuasive.

So I'm all for collaboration between people, including between teams, but I don't understand sacrificing the REST of the time in the name of that one thing.

[benhurmarcel]

> But I actually like that different teams can mix a lot easier.

My team shares an open office with another one, working on a different project. We see them every day.

I don't think anyone knows any name of the people in the other team.

[JimboOmega]

"I just stare at my desk. But it looks like I'm working!" - Office Space

[VonGuard]

Reminds me of an old adage about tech work and other skilled labors: If you give me a task that takes a normal perosn 8 hours, and I finish it in 30 minutes, you're paying me for the skill, knowledge and experience that allows me to do it in 30 minutes. I do not owe you another 7.5 hours of work. I owe you the job being done, not the hours it should take to do it.

[Chirael]

Isn't that one of the reasons Hacker News exists, to fill those other 7.5 hours?

[umvi]

> I do not owe you another 7.5 hours of work.

Only if you are a contractor and you've fulfilled your contract. If you are a salaried employee I expect you to keep your hopper of tasks full so you aren't sitting around idle 95% of the day waiting for me to feed you 30 minute taskers

[malvosenior]

Judge people by their output. If someone is performing well and shipping, then it doesn't matter if that takes 10 minutes or 8 hours. Many people work better with a lot of space. If you fill someone's hopper so they're forced to work 8 hours a day, then you'll quickly find the tasks that used to take them 10 minutes to complete now take multiple hours due to: burn out, stress, context switching and most likely bad management.

[SketchySeaBeast]

Why? As a salaried employee you're literally paying me for my ability to get work done, not for my hourly output. If the goal is to keep me busy for X number of hours a day, instead of getting a job done whatever it requires, why am I salaried?

[umvi]

> If the goal is to keep me busy for X number of hours a day, instead of getting a job done whatever it requires, why am I salaried?

The "goal" in a lot of cases is nebulous (i.e. "keep developing the product", "improve stability", etc). There might not be a manager feeding you tasks every time you run out. At least in my company, you are expected to figure out on your own how to continually make the product better and proactively do it, not sit around idle after rapidly finishing the last task your manager gave you.

If you are just a dumb worker that can only work when your manager fills your queue, you are not valuable to me as a salaried employee (you are more valuable as a contractor who I can call upon for a one-off difficult task that you can then complete in 30 minutes).

[SketchySeaBeast]

So you're not trusting the salaried employee to use their judgement on how best to utilize their time, but instead assuming they instead use their skill to be a butt in a seat and working for at least 40 hours? What's special about the salary then? It's just easier than an hourly system?

[Xelbair]

Great way to turn that 30 minute task into 8 hour task.

If employee is getting extra works as a reward for being efficient guess what will happen.

[r00fus]

As someone who works with client billable hours, actual work usually takes the least amount of time. The communication about your completion, testing/confirmation, documentation and shadow/knowledge sharing take the remaining 7.5h (using your analogy).

If you're truly doing all those things in 30m, you should be running the show.

Sometimes taking the full 8h allows you to put in the packaging to confirm you've done the "hard" part.

[VonGuard]

Everyone in this thread below is assuming after the 30 minutes I just fuck off and do nothing. LOL, why would anyone pay me if I did that? Obviously, there's always a ton of stuff to do. But, again, it's about results, not hours worked. There's times when you have to put in almost 48 hours non-stop, others where you don't have to work all week. The point is that if your employees have tasks to do and they're doing them, who gives a fuck about how long it takes them? The 40 hour work week is fucking horrible, anyway, and as is pointed out later in this thread, creative work like coding goes on in your mind pretty much 24/7. If I come up with the solution to a problem Saturday night you can damn well be sure I'm taking some time off to compensate for that. Otherwise I'll burn the fuck out.

Sure, some unknown quantity of people can just fuck around and hide from work, but again, you're not paying me because I'm a fuck off person, yer paying me because I have the decades of experience, and because you know with certainty I'll do the damn work, find more work when I need more, and will never miss a deadline on my own fault. Everyone on HN just assumes bad faith all the time, geez....

[davidjnelson]

If I finish stuff early there’s always more that can be done to help the team. Our ci can be improved, our ux can be polished, app perf can be profiled, engineers can be mentored, customers can be listened to, relationships can be strengthened, unit tests can be added, refactoring can be done, architecture can be simplified, etc.

It feels good to help people, as long as it’s with healthy boundaries so as to prevent burnout.

[xyzzy_plugh]

This is only true if you're getting paid the equivalent of a normal person working 8 hours.

Most tech workers get paid a bit more than that.

[watwut]

I would find it unethical, including in team where I am fastest.

[malvosenior]

What's unethical about it? If someone produces what needs to be done, then does it matter how they do it?

[watwut]

Just like I don't want employer to flip it into "we need 12 hours worth of work" or hold unrealistic deadline over mu throat, I will ask for new task if original estimate was too short.

I did actually signed contract that actually specifies fI'll time - 40 hours.

[malvosenior]

That's not how creative work works though. Do you ever think about your code at night or the weekend? Mental work is basically always on and can't be judged by the amount of time at the keyboard implementing it. The whole concept of tasks per hour doesn't map well to software development.

[malvosenior]

Why can they not be trusted and measured? I trust my employees and encourage them to be creative and autonomous. I also expect people to ship their progress regularly and work in strategic alignment as helped by the direction I provide in our regular meeting cadence.

It's a weak manager that's constantly concerned about their reports not being productive. Nothing in the world is easier to spot than someone who doesn't produce. You don't need to optimize for that, when it happens, deal with it. Optimize toward keeping your team motivated.

[justbaker]

Does the employee deliver? That should be a yes/no answer. Micromanging employees minutes is an ineffective distraction to reaching that goal of delivery. The more autonomous each is while still moving in the direction of the common goal of the team, the more trusted they can be.

[malvosenior]

Absolutely. You will get the best work out of an employee if they have as much autonomy and creative input as possible. I've never understood why that's so difficult for a lot of managers to realize. I suspect most people aren't cut out for leadership because they don't have the trust, confidence or lack of ego required to motivate people without power tripping on them.

[Xelbair]

>> Micromanging employees minutes is an ineffective distraction to reaching that goal of delivery.

i would say that it is a very quick way for employee to reach towards a new company.

[otakucode]

I would like to suggest a tremendously simple (4) : Every day, each employee spends no more than 5 minutes reporting what they did the prior day, and what they are planning to work on that day. If they're blocked by anything, they can mention that and ask for assistance.

I just finished working on a fully remote contract that worked that way, every day at noon there was a conference call that never took longer than 15 minutes. It worked great. A couple manager types were on the call, and they'd share any developments on the contract side of things, feedback from the customer, things like that, but mostly they just listened and took note of potential issues and made sure they got resolved (so like if you mentioned a problem one day then didn't the next, they'd ask if it got dealt with).

[fizx]

Making standups useful to everyone on mid-to-large teams (i.e. > 6:1 employee:manager ratio) is quite challenging, but yes, you raise a good point that this is viable, particularly for smaller teams.

[wolco]

Sounds horrible. Have meetings when they are necessary. Talk to people throughout the day. Send weekly status reports.

Don't waste a day resolve that issue now.

[bonestamp2]

From my experience, as long as the company is divided into small project teams, a project manager can take 10 minutes every day to have a group meeting for everyone to share what they worked on yesterday and what they're working on today. Call it a scrum meeting or a stand-up or whatever, but it doesn't have to follow any specific model as this will probably vary depending on your type of work.

We have 8 people on our current project team and we can typically finish this meeting in under 5 minutes each morning. We have some people on each coast, and half the people are remote so we do it at 10:30 am Eastern.

It keeps everyone accountable to the company and each other, and because everyone knows what everyone else is working on, it makes it easier to avoid overlap and divide up tasks in the most logical way possible.

[baron_harkonnen]

In the many jobs I've had I've never seen "things go side ways" because those tricky employees have finally found a way to not do any work! By and large the vast majority of workers have the capitalist cultural logic deeply ingrained in their psyche and personally feel value only when they produce meaningful work. Most people are not trying to get away with doing less, and, at least in my experience, feel the most satisfied and secure when they are working hard and creating visible products of their labor.

When I've seen "things go side ways" it's almost exclusively at higher levels of management when politics create goals other than "create an amazing product". Anyone who has worked both in a large company and a small startups has likely seen the difference between "my boss's goal is for us to create a best in class product" vs "my boss's goal is for him to get L_current +1 promotion".

There are no companies that have failed because the workers have finally figured out how to sneak their way out of doing work. But workers do have a hard time being productive when "productivity" is some weird game that no one will really explain the rules to.

But the logic of blaming workers who get "off track" is a huge part of the culture we need to get rid of to have successful remote work.

[fizx]

Agree that 90% of people want to do effective work. The problem is that 6 people have 7 opinions about what effective means.

It's not about blame, it's about trying to ensure the team works together cohesively, and that individuals are unblocked.

[MaxBarraclough]

> There are no companies that have failed because the workers have finally figured out how to sneak their way out of doing work.

I suspect there are such companies, but that the guilty individuals weren't serious professionals. Hire bad enough 'developers' and I can see it becoming a problem.

If the job is shovelling snow, I imagine it becomes one of the management's chief concerns.

[davidjnelson]

2 seems to work well. Keep people updated as you go. It’s compassionate - managers have a lot on their plate, give them an assist.

[nabdab]

It’s a valid concern. If you don’t have transparency into ongoing work, then you aren’t ready for remote workers.

If the only method for your manager to know what people are working on is to tap people on shoulders, then doing that isn’t a “bad behavior” for the manager, it’s necessary behavior.

Of cause a better solution is to have trust and plans. (Agile, scrum, waterfall, napkin sketches or whatever it doesn’t matter as long as people align during planning and have transparency into the plan). But in the absence you still need to have management in sync with what is going on.

Naturally the best pathway forwards is to look into changing your system to include all these value adding elements. But enabling remote work while management is critically dependent on physical presence to continue operation is not a good idea. And the solution is not just for managers to “give up the mindset” of knowing what’s going on below them. Trust is great when it works, and toxic when it doesn’t. The agile mantra of increasing trust is not just supposed to advocate blind trust. It’s about building a framework and working routine where we are validated in trusting each other.

[thrownaway954]

My manager _constantly_ will shout out, "does anyone know what X is working on?" It pisses me off to high hell that a manager has to ask his workers what another worker is working on.

I honestly think that EVERYONE should be using a ticket tracking system and just put assignments in a person's queue. I don't see why this is such a big deal or looked down upon. It's so easy to see what everyone is working on, run reports to see how long things took, have a place to keep track of notes which builds a knowledge base, the benefits are limmitless.

Not to mention the fact that if all you have to do is look at the reports to know what is going on, you don't physically need the person there which will allows them to work from anywhere.

[quadrifoliate]

> I honestly think that EVERYONE should be using a ticket tracking system and just put assignments in a person's queue. I don't see why this is such a big deal or looked down upon.

As I see it, none of the queuing stuff is really controversial.

> It's so easy to see what everyone is working on, run reports to see how long things took

This, on the other hand is usually what's controversial, and the reasoning behind that is that it often leads to management using past data as a stick to drive "faster" future development, with silly statements like “Well, the average plugin took 2 days to write, why is this one taking 7 days? Oh it must be that the person doing it is lazy. Better give them negative feedback on it and tell them it can affect their promotions”.

The example is contrived, but the motivations and behaviors are very real. Competent developers tend to leave companies where they are constantly badgered about stuff like this by managers who have never developed software. In the extreme case (very few organizations are this bad, but they do exist), all you end up with is the remaining ones who know how to show that they are doing a lot of work, but are generally afraid to show their lack of knowledge in any area for fear of being dinged by the data-equipped management for it.

Since this is not conducive to the technical health of a software development team, estimation practices that purport to be unrealistically accurate are what's looked down upon.

[krageon]

> management using past data as a stick to drive "faster" future development

Of course bad management is bad, but the idea that the type of metrics available to them make any material difference is not one that has any merit to my mind. A bad manager will always make your life hell, regardless of what measuring tools they have available.

[quadrifoliate]

> A bad manager will always make your life hell, regardless of what measuring tools they have available.

Correct. That's why developers with bad managers strive to make as few measuring tools available to them as possible. In other words, if you're a manager and your employees seem to resent and fight against more ways of measuring "velocity" and the like, you should probably consider that your usage of this data and how you express the results might need some work.

[siffland]

A huge problem with ticketing systems is then management uses it to track all productivity.

We had a ticketing system and one guy in our group had between 60% and 80% more tickets than the rest of us. So it would seem we were all slackers, however he took the tickets that took like 2 minutes to do (password resets, account unlocks, etc...), meanwhile i would get stuck troubleshooting a production performance issue that would consume hours. Management didn't care what the ticket was, they liked to see pretty numbers of tickets completed.

I might be the only one who had this experience, and i am not saying ticketing systems are bad, they are extremely useful, as long as everyone knows how they work.

[garettmd]

You're definitely not the only one to have this experience.

Honestly, I think the problem is structural with regard to management. Just changing the process or tool (ticketing vs constant communication with manager) isn't enough. It probably needs to be combined with smaller teams (i.e. Amazon's pizza rule) and management defining goals and "success" as more than meeting some narrow KPIs (MTTR on tickets, for example)

[thrownaway954]

On the flip side... At my previous job, cause of the ticket tracking system, it was shown that I handled 40% of all tickets that came into our team of 7 people. And this wasn't 2 minute tickets either, these were projects also.

Sorry you had that experience, but to me the justification of those types of system are solid.

[taurath]

All you need is a 10 minute standup to solve that problem every day. You can even do it async and have people post it on slack or something. If people aren't saying it in enough detail, then ask for more detail.

[RhodesianHunter]

Take the ticket backlog one step further, have a scrum board with to do, in progress, blocked, done columns and then management can't get an excellent high level view at any time

[growlist]

One thing that amuses me - you can provide the very simplest tools (such as an issue tracker report) and some managers will still utterly refuse to use them, to the point of open hostility, because it somehow undermines their position to open a link and read an online report as opposed to asking a subordinate to read it to them instead ¯\_(ツ)_/¯

[sanderjd]

Yep, my biggest frustration is when people (not just managers) ask questions instead of looking things up. And it can be hard to push back against because they are "just trying to get the answer more efficiently by just asking". Which is true, it's usually more efficient to ask someone who knows something than to find something yourself. The problem is that it preempts work to be done in serial instead of doing a bit more work in parallel. There is a point at which that makes sense, there are things people know that require a lot of legwork for someone else to find out for themselves. But "what are you working on" is pretty much never in that category.

[otaviokz]

Unfortunately there's always people living in the 1800s...

[growlist]

True. The enterprise sometimes keeps going in spite of its leaders...

[100100010001]

I disagree with the “tapping on the shoulder isn’t a bad behavior”. It is counterproductive as illustrated by the linked cartoon.

https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt...

[vidarh]

They weren't saying it isn't a bad behavior in general, but that in the absence of visibility into what staff is doing it is a necessity. It's far worse than having proper visibility, but until/unless you have that visibility, it's a lowest-effort way of getting some visibility.

Of course the right thing to do is to work to get proper visibility, and when you have that, then the "tap" is pointless interruption.

[auiya]

Managers who tap aren't interested in work visibility. That can be achieved via a simple email. Managers who tap are only interested in hearing themselves talk at others.

[croon]

> If the only method for your manager to know what people are working on is to tap people on shoulders, then doing that isn’t a “bad behavior” for the manager, it’s necessary behavior.

It is bad behavior, for two simple reasons:

1) The tapping of the shoulder (both literal and figurative) doesn't award any information, only the question afterward. So focus on what that question is, and implement whatever information that gets you (if any) into another system that doesn't require you huffing around interrupting the flow of your employees.

2) If that is your only method, you have already failed, and anything you do in that position that is not directly related to getting out of that position, is bad behavior.

[BigJ1211]

> As one of my ex CEOs put it: "If I don't see my employees stressing out at thier desks I get the impression they're not working."

This really hits the nail on the head, in my experience this is accurate for employers that are anti-remote, they want to be able to see people "work". I've argued that that means they are essentially paying people to be there 8 hours a day, not that they're working 8 hours a day. You see it a lot in stale offices, people are sitting at their desks appearing busy. Work doesn't get completed in the that time and they start hiring more busy drones.

It's absolutely baffling to me that we can't look at the statistics at a higher level and recognise that it's a highly inefficient way of working.

[galfarragem]

Company's politics boil down to how the person in charge sees himself: as a boss or as a team leader. When it is like a boss, run and don't look back.

[nkrisc]

Likely they don't have any higher level way to gauge or measure productivity, which is why they fall back to something they can see: how many people are there and for how long. If they could measure how much work is actually getting done, they'd probably forget to even gaze upon the serfs toiling.

[sixstringtheory]

This seems like a big use-case for JIRA. It can do all sorts of reporting, and if you're engaged and looking at it every day you can see work as it gets done (as long as people use it in a way you've all agreed, which is a separate and simpler problem). Even a simple Trello board would go a long way (my personal preference).

Ironically, many places will use JIRA/Trello/etc, and then still have the sync meetings where you repeat all the actions you've performed on the board!

[2muchcoffeeman]

I get more work done and work longer hours when I work from home. Meetings are a good reason to turn up to the office if you have an agenda. And maybe the odd guild or two. Or brainstorming on solutions with team mates. But this only requires you to be in the office a couple days a week max. They could get 20% more work out of me with no impact to my non work life but ...

[krageon]

> we can't look at the statistics at a higher level

We can look at them and your management can too. The important takeaway is not that they don't know or can't learn, it is that their sense of control over you is more important than any measurable truth. Once you realise it's just a dysfunctional personality trait it becomes a lot easier to understand why it's so hard to change.

[alexis_fr]

It’s easy when work gets completed. I would hire anyone remotely or let them play games at work if work is done. It is more difficult when we think their work in average or has a lot of defects. Then, the contract is for them to put in the required hours with decent concentration, and they have fulfilled their part in a measurable way that satisfies the manager. And truth be told, if their work were perfect, they would be promoted.

So, home office for senior developers with awesome productivity only?

[Notorious_BLT]

Then the junior developers never get the benefit/mentorship of the best senior developers, instead they get mentored by the senior devs with poor productivity. That seems like a recipe for more unproductive developers

[pts_]

Hire juniors who can actually read the fscking code and docs.

[pts_]

Hah that's a tall order in 2020. Most of them can only watch videos and ask others.

[bogle]

This is my experience of British management over the last quarter of a century. I am an expensive contract resource but I still get paid for turning up and not so much for providing working software.

When I am working remotely, due to the organisation's inability to measure productivity, fostered by their management's "bums on seats" culture, I can't demonstrate that remote work is a benefit to them.

[deepGem]

Ditto in India. Though economic realities are forcing companies to give at least one work from home day per month. It is estimated that companies are losing close to $20B in traffic related stress.

[pts_]

In mob programming culture it's not even bum on seats but bums crowding around a seat!

[commandlinefan]

> mob programming

Why waste one person's time when you can waste ten?

[choonway]

No wonder Singapore is like that too. 50+ years after independence from the British is not enough to change culture.

[throwaway9301]

The interesting question is: "why?".

David Graeber's book "Bullsh*t Jobs" is about that.

These companies main priority is not efficiency and productivity. If it was, they could hire less people to do the same work and that would foster unemployment.

They have a political and social role: hire as many people as possible. Keep them employed and busy and keep an eye on them.

Become too big to fail and you'll be rewarded with overbudgeted contracts (and even bailouts, sometimes).

[chucksmash]

> These companies main priority is not efficiency and productivity.

Still with you here...

> They have a political and social role: hire as many people as possible.

You lose me here.

Most companies are out to make as much money as possible now or in the near future. I spent the first three years of my career in QA at a total BS Jobs company (120k+ employees, lots of government contract and enterprise software work). So many people coasted, nothing ever really got done, etc. Even in a totally dysfunctional organization like that, hiring was either about backfilling attrition losses or hiring people that were expected to directly or indirectly contribute to revenue growth.

Never attribute to a vast socio-political conspiracy that which can be explained by the emergent incompetence of a large organization.

[shantly]

> Most companies are out to make as much money as possible now or in the near future.

The company in the abstract, sure. Not managers and VPs and such. Not even the C-suite, necessarily, or at least they likely have other concerns in addition to just the company making money. It's the principal agent problem plus the management version of résumé-driven-development, basically.

[lnsru]

I call this “general wants to see his army”. I can read Wikipedia all day, but I must be present. Funny thing, all managers are allowed to work from home. Developers not! There is open office with small desks for 8-12 people in one space.

[jrockway]

I think this is because people don't understand how engineers spend their time. The stuff displayed on the screen makes no sense. Sometimes things that sound simple take weeks ("iOS Safari and Chrome behave completely differently!") and things that sound hard take an hour ("yeah that's just a flag flip"). What are "unit tests" and "code reviews"?

Even with 12 years of professional programming experience, I am only beginning to have an idea of how long things are going to take in the context of a small team. If you've never programmed before, I don't know how you could possibly come up with an idea of how long something should take. So it reduces to the heuristic of "well they're at their desk, I'm sure they're doing something."

[tyfon]

Personally I work remotely in Norway with a similar commute, but I do travel into the office for some face to face meetings. Most is done via slack or something similar though and my productivity is vastly higher. I also don't need to waste 2 hours every day of my personal time that I can instead spend with my wife and children.

They also save on office space.. I don't see how this is not a win win for everyone either.

Your ex CEO sounds like a psychopath.

[ChuckNorris89]

That's South/Central Europe for you. Not everywhere is as evolved as Norway.

[atomwaffel]

Eh, I work in Norway and while I can work remotely on request, my inquiry about doing so regularly one day a week was met with “what if shit hits the fan and we need you here urgently” from my manager (my house is a ten minute walk from the office) and “if we allow one person to work remotely, everyone will want to” from HR.

[tyfon]

You should tell HR that would be great, one seat at the office costs a lot. They have a huge savings potential :)

[atomwaffel]

Yes, but think of all the meetings you can’t have if people aren’t at the office!

[BurningFrog]

Unless your work output is very easy to measure, demanding you show up to work in one of the only ways to ensure you're at least putting in an effort for your employer.

Of course, one of the hardest professions to measure output for is software engineers.

I once worked with a guy who, it was discovered after a long time, actually had two Silicon Valley jobs. That he actually showed up at! He walked/drove between them a few times a day, and managed to keep the illusion up for quite a while.

I'm guessing he has 4 "remote" jobs now :)

[bitL]

I used to have 3 remote dev jobs at once. It was exhausting but doable; my problem before was that no company was utilizing me at more than 30% of what I could sustain and I was upset I was wasting my time. So I had one web dev, one Java and one Deep Learning gig in parallel. The only issue was with conflicting times of meetings. I didn't tell either company I was working for another but had a prior agreement that they wouldn't mind if I did unrelated work elsewhere as well if it didn't affect deliveries for them. I used the extra money I got to pay off my Top 10 MS in ML and MBA.

[8note]

having multiple start up jobs makes some sense, really. you as an employee are making an investment in terms of time in exchange for shares of the business.

the VCs aren't putting all their eggs in one basket with startups, so why should the workers?

[oh_sigh]

Maybe the problem is you were trying to invalidate their e tire management worldview with those studies. Instead, a more effective strategy might have been convincing management that while their methods were generally fine, for your specific case you might buck the trend. At least, that's how I've had luck with this problem. And also reassuring(and proving through my actions) that they wouldn't need to devote special time just to managing me vs managing the horde.

[precisioncoder]

Logic doesn't matter, it's the ability to sell it. This goes for almost all major decisions which are usually decided based on emotional "gut feelings" rather than logic and statistics.

I would suggest something like: "I've been crunching the numbers on how to increase efficiency and been pleasantly surprised at how well we're performing compared to our competition. I was thinking of trying an experiment based on this new study I've read <Link> where we leverage existing great management techniques to also allow remote work on a limited basis. If you're interested I could show you the numbers but I think with a small sample set <me and a few other good developers> we could prove that this could boost our efficiency even higher! In fact even though it's increasing our numbers we can even offer it to the team as a perk, <study> has shown that when a team gets a perk even if it boosts efficency they work even harder! We have this great new/old project <X> that would be perfect to measure the numbers with. How about I roll it out at the beginning of next month? Don't worry about the planning, I have some experience and can have a proposal on your desk by the end of the week."

[chrisweekly]

Mostly good advice. Along similar lines (w/ more detail of course), see DHH's book "REMOTE" which includes advice on how to sell the idea to mgmt. As a first step I'd recommend starting even smaller though, vs framing it as a new and demonstrably better way for projectS to be done in general (ie, a big change). See if you can find a way to demonstrate the benefits on a personal/individual level, without making a big deal of it. If you can start the bigger conversation (involving teams / processes / policies) already armed with evidence of success at your current workplace, you'll gain credibility and engender confidence / assuage fears of those in management who need convincing.

For my part, I've been self-employed (full-time consulting), 98% remote, for about 3 years. Before that, in almost 20 years of traditional software-related jobs, about half my working days were remote. I was fortunate in being able to insist on a high degree of autonomy wrt how/where/when I got my work done, for most of my positions. Not always possible, but you'll never get the freedom if you don't look for the oppty and make the case for it.

[esotericn]

I personally just do it.

It's then empirically obvious that I get more done and am happier.

If they don't like it, they can sack me. I earn more than twice minimum wage, ergo I can work half the year and get by.

It's never happened yet because it turns out actually people like people who get stuff done. Who knew?

Behind this monitor I'm looking out at the river, watching Winter roll in as I eat lunch. :)

[commandlinefan]

Remember, we live in a corporate culture where people who have offices with doors that close praise the “collaboration” of the open office that the rest of us serfs suffer under. You’re dreaming if you think productivity is actually the goal: power is the goal (their power over you). If you manage to produce anything in spite of management’s best efforts to thwart you, that’s entirely accidental.

[dashscript]

> power is the goal (their power over you)

working remotely gives too much power to workers because interviewing elsewhere becomes so inexpensive. In fact I'd argue most remote devs that are not already at the top of their potential compensation/status (say, someone working in the linux kernel team) are interviewing constantly. Most companies not aiming for top tallent are better off taking on contractors than remote full time developers.

[bitL]

The worst thing is that Europeans take this attitude with them when they move to USA and then enforce it everywhere. They just can't imagine somebody working remotely properly and have the need to micromanage over IM, i.e. employees getting messaged immediately when one's status switches to "away" or similar.

[dmix]

> the ability to come over and interrupt you by tapping you on the shoulder whenever they need something.

Yeah, the answer to the OP articles question about why the remote studies work out that way isn't a big mystery.

The first thing you learn working from home is self-motivation and training yourself to get "in the zone". Then try doing the same at an office, where interruptions are far more often.

But that said not all offices are like this. A lot of companies work to 'protect' their creatives/engineers from disruption from the extroverts/talkers. Either by isolating them in separate closed office rooms or having rules like headphones on = don't bother them.

[disgruntledphd2]

What if I'm both a creative/engineer (DS, actually), and an extrovert/talker? Do I need to ignore myself when I have headphones on?

[dmix]

It's a generalization, fall back on common sense and work with people who fit your personality/work style.

[disgruntledphd2]

Clearly :) It was a (terrible) joke.

[dmix]

Oh mb.

[otabdeveloper4]

> interrupt you by tapping you on the shoulder whenever they need something

Well, yes, that's what you're being paid for.

The alternative is hard KPI's and getting fired for not meeting them, which is not something you really want.

[Merrill]

I know one person who works remotely in transcribing and one in editing. They have specific numbers to meet in terms of lines and pages. In fact the transcriber is paid by quantity.

[noarchy]

We're getting perilously close to seeing software developers reduced to those kinds of measurements again. People stuck working in "Agile" shops are putting up with "velocity" metrics. And with the spread of GitPrime, for instance, they're even seeing lines of code per day used as part of their metrics; something that used to be considered a relic of the past.

[jve]

Probably works for them. But don't measure code like that.

Bill Gates: Measuring programming progress by lines of code is like measuring aircraft building progress by weight

And then, how do you measure someone refactoring code and ending up with -1kLOC?

Or someone thinking hard for a few days to come up with an elegant algorithm?

[tima101]

I believe a change must come from bottom up and not from top down. Management won't change since they have little incentive to do so. Employees who are not happy with synchronous office work with a lot of interruptions should quit and start small successful companies that are asynchronous and remote.

To help this movement, we built open source SaaS boilerplate. We also built Async, an asynchronous team communication tool designed specifically for small teams of software engineers.

[mnm1]

Remote has already taken off. Some people will always be stuck in the slave master mentality by choice, not because they don't know any better. They just love to control others and make others' lives miserable. Many managers literally have no other skills or purpose in this world other than that. Fuck them. The rest of us will be productive remotely while the master and slaves will work in open offices where the idiot executives actually believe that random sharing of bullshit is what writes code, fills in the accounting books, and in general does actual work. As long as those morons are making money though, their idiocy will live on. And how can you not make money in advertising these days? So it's a long uphill battle for the rest of us who prefer to get things done and do non work stuff afterwards than the moronic control freaks who think collaboration is the key and somehow the code or article writes itself. The alternative is starting that fifth game of foosball before lunch and getting to actual work sometime in the afternoon, continuing at home, and maybe finishing by two to three am if you're lucky. No wonder people work so many hours with such little efficiency.

[JDiculous]

If there's anything I've learned working office jobs at corporations, it's that you can't change the culture around "butt in seats" management because it's almost like one of the core identities of the leadership. There's always a non-technical C-level executive at the top who values "butt in seats" management, and remote work isn't one of those things that anybody will speak out to defend, particularly against the superior(s) at the top of the food hierarchy.

It's kind of like how legalizing prostitution makes way more sense especially for the sex workers, but nobody ever talks of legalizing it because nobody wants to be the guy to bring it up or challenge the status quo.

Just leave and get a job at any remote-friendly company. The grass is really greener.

[Rapzid]

It takes a LOT of influence to directly affect culture at a company. If you don't have the amount of influence the best you can hope to do is spread and promote the ideas; just like in society. Except, it's a bit easier to change jobs than to change the society you live in :)

[_pmf_]

Businesses optimize for low middle management quality (being able to keep track of attendance == good enough), not for good grunt quality.