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.

> 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".

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.

If their supervisors believe "exempt" means "abuse this person with all the unpaid overtime", and don't respect their time and autonomy and expect them to respond to every interruption and get all their own stuff done, it's very unlikely that documenting those interruptions and "planning appropriately" will actually make a positive difference. More likely it'll just get them told they're being insubordinate.

Now, the ideal answer in a situation like that is to leave and find a better job. But if everyone in a situation like that could just leave and find a better job, we wouldn't have situations like that for long.

Yeah, I’ve worked in some very toxic workplaces. The other reason to document, is that now you have ammunition that you can take to progressively higher levels of management. Bureaucracies hate paper trails, and the sooner you can establish a paper trail the better off you are. But I do get it, often “heads down, do your work” is the only path due to factors outside of work.

I dunno; I'd say "bureaucracies love paper trails—they just want the bureaucracy's official paper trail to be the only one," heh.

But yeah; if you're in an organization that is not totally lost to corruption (of whatever stripe), or one that has to answer to higher authorities, like federal laws and the SEC, then documenting can be an extremely effective way to force, if not necessarily genuine changes of heart, at least skin-deep changes of behavior.

The case where I saw stuff like this happening second-hand (it was to a family member), the rot came, unfortunately, from the top. My family member was doing absolutely amazing work supporting the stated mission and values of the organization, and was having to fight tooth and nail to make it happen. Unfortunately, the organization's actual mission and values were much more along the lines of "make lots of money and pander to the people who will give it to us," so the job description was changed overnight to one supporting part of the organization that they had made perfectly clear over their years in that position they would have nothing to do with (because it was the part that most strongly violated the stated values). This was sufficient evidence that, after they quit and applied for unemployment, the state agreed this was constructive dismissal and paid out in full.

> 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.

Well, not to put too fine a point on it, but every job _I've_ ever had ends up devolving into a 24/7 expectation without much in the way of appreciation. This seems to follow the person, not the company.

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.

> whether the product or feature launches and how good it is, not by how many tickets you close

We're measured by both.

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)

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

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.

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.

> You should ALWAYS put your smartest/best developers on the least important project.

How do you retain your smartest/best devs when you are putting them on the least important projects and expecting them to tolerate infinite interruption?

Certainly there is a tradeoff of coaching vs doing for seniors, and you want to raise your overall team up.. but in practice a lot of "agile" environments are very focussed on output, and want to see more points/stories out of higher paid people. It sets up an adversarial system where nothing is expected of some, and everything is expected of others.

You are also correct about team size. In an engineering org with 1000s of people, you want everyone to grow and no 1 person really matters.

In startups, small orgs, and teams of 3-5 devs.. you do need your best doer to, actually, well.. do.

The best/smartest get to work on interesting problems. They get interupted a lot, but between they have time to try interesting things that someone focused on the important wouldn't. They are the ones trying rust first. They are the ones asking "what if" and trying new architectures on a small scale.

> 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.

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!

Did you notice that the grand parent is promoting instant interruptions with remote meetings? You're talking about being able to ignore your coworkers requests easier.

Seems pretty contradictory, no?

I also do wonder what the real value of it ignoring live requests is. You personally get to stay on task but what about what's lost? If you block two or more people isn't it worse overall?

Work should be structured to be as non blocking as possible in the first place. If its not, there is either an issue in planning, resources, or in (unlikely) cases, truly it has to be serial, in which case it should be planned accordingly

I'd also argue, that 2 people being blocked because of X should warrant breaking through any focus period, as thats clear indication of an issue that needs more attention.

If you're talking about 2 people being blocked simply because they don't know what to do, thats why companies should have proper mentorship programs in the first place, it was a need hidden because being in-office made this less visible of a need, but it was always there, and dedicated mentorships are better than ad-hoc problem solving in these types of cases. Not every senior needs to be in the "deep work" pool (we do mentorship on rotation where I work)

> Work should be structured to be as non blocking as possible

Which works if the work is predictable. If you’re in a dynamic environment, that’s not possible. Hence, agility.

To take an absurd example, military command shouldn’t be RO.

Noobs mostly do the interrupting and want to be able to interrupt.

On the other hand, the experts are just getting interrupted with noob questions, and end up helping several people with their tasks in a day and their own task is still there undone.

Noob get promoted and expert doesn't.

Expert hates the noob.

Clear enough?

Unpopular opinion, but this seems more like an issue of developer comfort than actual productivity, similar to how taking adderall can make you feel more productive than you actually are.

If the product quality depends on you maintaining a flow state for extended periods, then you're either working in a research lab or it's a poorly designed product.

I say this as a dev who also gets annoyed when my deep focus is interrupted, but so long as the interruption is actually warranted (and with my company's culture it usually is) I swallow my annoyance, task-switch and get the job done anyway. I'm already earning a higher salary than than most people in the world with good benefits and flexible hours. I can be mildly annoyed at work sometimes if it helps get the job done.

> If the product quality depends on you maintaining a flow state for extended periods

I think you've conflated quality and productivity; you started talking about one then switched to the other. They are related but not the same.

Certain dev tasks require deep flow for good results/quality. Robust refactorings, abstraction design and prototyping. Basically anything where you have to preserve invariants under code transformations. This isn't all dev work, and isn't necessarily frequent either, but when flow state is required it's usually important work that's core to a program's operation, so product quality definitely depends on flow.

If you're working on such a task, an interruption requires a return to that flow state to ensure good quality, and that takes time and will definitely impact productivity.

Other tasks do not require going very deep though and so achieving comparable quality doesn't require much depth in your flow. Interruptions won't affect productivity much in such cases.

My two cents.

I think the key point of the line you quoted was "for extended periods". Obviously flow states are useful, perhaps even required in some contexts, but to demand a full day of uninterrupted flow-state engineering bliss is IMO unrealistic and very often counterproductive. Software development at the company level is a team sport, and being actively hostile to necessary communication simply because it "interrupts your flow state" is the act of a prima donna or "rock star" developer. I've refactored a lot of code/been doing deep design work and been interrupted during said work. Did it make my personal task take substantially longer to complete due to the task-switching/getting my flow state back? Sure, but the interruption was for a good reason and my help was actually needed. On balance the interruption saved the company money and time because the drop in efficiency of execution for my slice of the pie was less impactful than what my help was needed for.

Now if you're getting constantly pinged for stupid shit that anyone could Google, then perhaps you should politely confront the person(s) doing so and make your expectations clear rather than declaring a pox on all interruptions.

> Sure, but the interruption was for a good reason and my help was actually needed.

Wouldn't this be true of just about everyone complaining about such interruptions though? I can't imagine anyone would mind being interrupted if the building were on fire. People just differ on what they consider to be good reasons.

I'm sure there are unreasonable people on all sides, both those asking for unreasonable conditions to interrupt them and those not respecting reasonable conditions for interruptions, but I don't think it's the majority of the people complaining about it. I've been in this situation a few times, and lots of people just don't have good impulse control and so don't even think twice about interrupting you if it's more convenient for them.

I disagree. I can move through quite alot, quite well, when I can work in a deep flow. 2-4 hours of deep work can be incredibly productive end to end and we follow TDD pretty strictly, which lends itself well to really thinking about problems and their solutions in my experience thus far, but it requires the ability to really walk through a problem space.

Our code quality here has improved significantly around this, and we are shipping faster than ever.

That isn't to say I'm unavailable (or anyone else) its that there is an acceptance that not all things are urgent, and if they are, its warranted to break through any focus periods.

Doesn't sound like we disagree that much. You are actually available, but not all things are urgent. I'd say the difference at my workplace is that pieces of the product are extremely old, developed under different architectures with different technologies under multiple management regimes of varying quality. There's a lot of tribal knowledge, so everything is kind of urgent by default as someone new to a specific piece of code can't move forward efficiently without picking the relevant SME's brain. Forbidding interruptions would be akin to mandating "only the SMEs can work, and the rest of you need to waste money twiddling your thumbs or banging your head against obscure legacy code until they feel like helping you". Most of the time when I'm interrupted it's because someone's blocked and I have the knowledge to unblock them, or I can at least point them to who does, so my loss of flow state is their gaining the ability to move forward at all, and everyone benefits.

By contrast it sounds like you guys designed your product around maximizing the impact of flow states and minimizing the need for interruption. I bet you have good documentation too. I'm honestly jealous, it would take tens of millions and years of re-writes to do the same here, and our prime customer wouldn't be willing to accept the delay even if we had the funding.

It may not be that "only SMEs can work" but that "SMEs don't have 5 tickets this sprint but 3 high level deliveries over the next quarter" thus they are allowed work uninterrupted from the daily churn and focus intensely (contributing to their already high base knowledge). Whereas other engineers are constantly distracted and stay surface level trying to stay afloat.

I completely agree with this way of working, and we have the same “protocol” as it were. I check my comms once every one or two hours to see if there is any pressing matters.

So little is actually urgent, unless you have some business critical infrastructure you have to maintain, but that sounds like a different role entirely.

Feels like and environment problem. One workplace I had was an open office, but it also had a few dozen "focus rooms". Very tiny booth sort of room with A desk and outlets. Someone in a focus room clearly shouldn't be disturbed, but in the open space you're generally a bit more open.

If you want to work in silence - become a monk.