[helen___keller]

This is exactly the tradeoff, right?

By definition this is more efficient communication when you can ping someone irl, interrupt their flow, and get an immediate response.

And yes, it’s significantly worse for deep work.

In exchange for losing deep work, you no longer have to write a detailed thought to your PM, wait 5 hours for them to ping back “sounds good to me”, then begin working on it the next business day not feeling sure if they even read what you wrote.

[commandlinefan]

> This is exactly the tradeoff, right?

But you're also expected to meet your weekly "commitments" in JIRA - which means you're going to be working nights and weekends to do the work you're supposed to be doing since you were interrupted all day to do the work other people were supposed to be doing.

But you're right, this _is_ the tradeoff, and it's by design, since you're "exempt".

[milesvp]

No. The answer isn’t nights and weekends. It is much easier to simply document interruptions. This also means that during planning you can now actually plan appropriately for your time.

Please don’t accept the narrative that exempt means unpaid overtime is ok.

[verall]

> which means you're going to be working nights and weekends to do the work you're supposed to be doing since you were interrupted all day to do the work other people were supposed to be doing

Only if you're totally overscheduled?

It is a balance: you need to do your own work, other people need you to do their work, and you also need other people to do your work. Depending on your and your company's culture you may need to block out sections of your day for deep work. Or you may need to ask your manager for support to not be the SPOF for a bunch of other people's work.

[nostrademons]

I've never worked in a place driven by JIRA, always companies where they just expect a small team to come out with a product or major feature on a timescale ranging from ~quarter - ~year. You're evaluated by whether the product or feature launches and how good it is, not by how many tickets you close.

[no_wizard]

That sounds more of a planning / culture issue than something thats unavoidable. At the beginning of the pandemic, this happended alot, where I had to wait for PM input or what have you, but eventually, culture molded to be more async and we were given more trust to do things we felt were right.

We re-structured meetings to be more productive, for example: PMs are required to write all the requirements in advance of a refinement session so everyone can read them first, and you are expected to have read them. This opens up for async discussion (via Jira messages) and come refinement meetings, a way to ask and discuss directly.

In the last 2 years since thats taken place, I have not had another instance of waiting on a PM for a response.

In cases where we need something more urgent, there are always ways to get a PM on the line ASAP, we have protocols for that (seldom used, but they exist)

[helen___keller]

Yes, there exist company cultures and management styles that greatly assist remote teams

[steveBK123]

It can be asymmetric though of course.

The smartest person on your team is going to be interrupted the most. The worst person on your team is going to do a lot of interrupting. So your highest quality producer will produce less & your lowest quality producer will have their incompetence papered over. With remote, a lot of this interruptions are now on slack, and searchable.

In an environment with a lot of juniors that need coaching, the office definitely excels. For a team of mature engineers trying to work on challenging tasks, it can be highly disruptive.

I've been in a fully remote job and gotten more built in the last year than in probably my previous 5 years in office. Meanwhile when I was in-office, most of my coding was after hours (back at home).

Remote also means I spend less time in conference rooms listening to monologues and more time on 1-1 or small group zooms with productive screen shares of code/data/probelms.

[bluGill]

You should ALWAYS put your smartest/best developers on the least important project. This means your second best developers can grow to become your best developers, and nobody feels bad about interrupting the best developers. It also means if an urgent must do now project comes up your best developer is free to drop everything to do it - who cares that you just made the least important project late, while if they were on an important project management would have to think about priorities. (most do it now projects are things that can be done in days or weeks, if they are more than that it needs to go through the budget process)

Any large project will have plenty of technical debt that isn't important to clean up now but should be done. There are always new tools to try and see if they add value to your project. There are new frameworks to try that might or might not be worth telling everyone to start using for the next story.

The above does work for a tiny company of course. However for larger companies it is important.

[willcipriano]

> In exchange for losing deep work, you no longer have to write a detailed thought to your PM, wait 5 hours for them to ping back “sounds good to me”

In my experience those people take forever to make decisions anyway so you'd be doing exactly that from the office.

[ipaddr]

You can write a deep thought at 9am get on with your day and wait. Same thing happens in person.. send an email from your desk and wait.

Not sure I see the difference unless you are roaming the hallways ready to pounce to ask them a quick question before their next meeting.

[op00to]

The hallway pouncers are well known. I am remote but used to visit an office and knew to stay away from people who would do the hallway pounce and you’d walk away with a bunch of work. No thanks dude!