Open floor plans are even more problematic when the R&D team shares the space with sales / marketing. In that setting only one of the teams is getting any work done, I'll leave you to guess which one.

Yes - There is less than zero thought put into open floorplan seating charts.

We had in sequential rows - Level1 support, R&D, Development. Sat like this for years.

So R&D was sandwiched between the team that was constantly on contentious urgent calls, and the dev team they ran over to ask for help.

Best open floorplan seat I ever had was in a far corner way off from most dev, sat near a trader who spent all day on the phone yakking. Just like a total storyteller kind of guy, incredible yarns were spun .. kind faded into interesting background music for me. Like leaving the History Channel on in the back. Philosophy, science, history, movies, politics.. etc.

Is that a bad thing? Since we started WFH, I’ve heard a lot of stories of oncalls spending an hour on things that could have been handled in 5 seconds if the right person had gotten sucked in on the way back from coffee. “Oh, I recognize this bug from two years ago, here’s what you gotta do.” “That customer’s symptoms are impossible, ask for more details on how they’re doing suchandsuch because they must be leaving something out.”

What you describe is a completely different problem which happens to (poorly, inconsistently and costly) happens to sometimes get solved by open office space.

Having proper knowledge bases and procedures, including how the ask "the team"/seniors "ad-hoc" questions and get feedback reasonable fast is what you want to have to solve that problems IMHO. Because that also tends to work if e.g. some people are sick or gone (knowledge bases) or can't come to the office (e.g. sick kids at home).

Through most important I would say is that communication in remote work is very different to office work and "just throwing slack into the mix" and doing the rest like before isn't going to cut it.

And yes that needs proper tooling, too and yes most of the tooling marked for this purpose today is .... pretty bad, sometimes utter garbage creating more work then they save time. Similar the part of procedures is often completely ignored, too.

I'm just not sure that there's any way to build a knowledge base that can fully replace asking seniors ad-hoc questions workflow. I've worked at places with amazing build tooling, monitoring, etc., and they still never came close to solving it. (This is actually the primary reason I'm excited about LLMs - I don't particularly enjoy the ad-hoc questions part of my job and they seem like the most promising avenue to finally solve it.)

Well, yes, until the stuff which has to be delivered by the people sucked in to do support stuff starts lagging and missing deadlines. Then, suddenly, lots of people start being really unhappy (usually at the expenses of the people who were helping).

If the oncalls don't have the knowledge to solve the issues they encounter, they need to escalate them and somebody needs to put more time in developing a more comprehensive knowledge base for them to reference, not just "steal" time from other company functions.

But your solutions imply things that you would probably not accept to do if you were the one having to do the work for these solutions.

You are saying that people will be blamed for taking too much time to an example saying it would took 10h of someone's time instead of 5 minutes. Why the company will value more the deadline you are referring to than the time it takes for operations to solve the problem?

You are saying people should escalate. But on the example, the person who has the solution is the person you say should not be disturbed. So you are just asking to disturb uselessly people who cannot help, so your solution is even worse.

You are saying more time is needed to develop a more comprehensive knowledge base. But who should take the time to fill up the knowledge base if not the people who have the answers, which, in this example, is the people you say don't have time. (and moreover, funnily, those people complaining to be distracted are also very very often not doing any effort to share their knowledge somewhere accessible).

I'm slowly getting very irritated by the whole WFH debate: there is way too much arguments that boils down to "the problem is that _I_ am the one that people distract, so let's do my solution that is sooooo much smarter, let's do something where _I_ am happy even if it makes the situation worse for everyone else". That slowly creates this impression that a lot of pro-WFH are just little kids.

Yes. Management wants to be all about the metrics & KPIs, but then throw in this "open office plan / RTO is needed for collaboration" fuzziness on top.

If you want to be metric driven, it's important that the processes be allowed to fail. Otherwise you are robbing Peter to pay Paul, and the KPI that looks BAD is not where the process is failing necessarily, but where the time got stolen from.

Well it depends on your tradeoff decision between SLAs & Development productivity.

If you hire explicit 20% staff to do operational tasks, and also wall off a fixed rotating 5% of your dev team to assist them.. then you've made a conscious decision on resource allocation of 25%. If the other 95% of the dev team is getting interrupted every 30minutes by "questions" then your operational staff/rotation is not resulting in better runbooks, etc.

If you want better SLA and your operational staffing is not sufficient, then you should see your SLA breach, make staffing/process changes, etc.

When development just papers over these issues you end up with great operational metrics and bad development metrics, so then everyone can be even more upset at dev!

Personally, my experience is the exact opposite.

It's very easy to say "hey, can you share your screen" on a remote conversation. While in person that will require moving at minimum 2 people (often more) into a compressed setting with bad visibility at some random place of the building.

We had a coworking space where some company was running (phone) customer service reps a few tables over. I didn’t use that one very much