That’s what my company does, and none of the engineers ever come in. My manager comes in when he has meetings, and I’ll go in sometimes, but I’m usually alone. None of the benefits of collocation with all the of downsides of an office.
I find that office days work a lot better. Everyone comes in Tuesdays and Thursdays or something.
The company still needs to pay a full office (decreasing chances that money will be used for home office benefit or raises), people are still forced to live somewhat close to the office, not realizing the biggest benefit of remote work: living where you want, close to the people you care and freeing up money and time.
If working together really helps, it's enough that those who think that coordinate and agree on days to go to the office. If nobody agrees, than maybe the benefits are only perceived or subjective?
I will be honest, I believe that lots of people go to the office because their 9-5 (+ commute) job made it impossible for them to maintain and cultivate social relationships outside work, which means they see the office as their attempt to escape loneliness. I am not saying that's everyone, but that for many people is the case and that explains people non-stop interrupting, walking in on others, chatting etc., which is quite common in office environments.
That said, I think that remote work needs also a few key elements to succeed:
- a remote culture in the company (e.g., everyone understands flexibility in terms of working time, meetings are online-first, documentation and async work culture, etc.) - a good space to work at home. I can't imagine working on a stool and a laptop like some people were forced to do during covid. - discipline (e.g., not let work time bleed into personal time, blocking time etc.) - good social relationships with friends/family. It can be very alienating otherwise.
I've just left a company that used to have an internal RFC process and it was a very significant barrier to progress that stifled innovation, led to breakdown of working relationships and caused the most productive engineers to run for the exits.
RFC is a request for comments, and it turns out you have to be really careful about the kinds of comments you solicit and who from. As soon as you ask people to comment you are setting an expectation that you will take their feedback onboard and address their points, but there’s a real asymmetry here - it is much easier to leave a critical comment, or to ask a question, than it is to address the concerns or answer the question.
This asymmetrical nature puts much more work on the shoulders of the RFC author. Similarly, the people writing the RFC have typically thought much harder and longer and deeper about the problem than the people giving feedback on it. This leads to authors having to re-explain their thinking in detail, covering points that they’d omitted for brevity or because they are obvious to those with a good understanding of the problem.
Suddenly, the task changes from shipping the feature or making the change to achieving consensus on the RFC. I have seen that process take months - far longer, and being far more expensive than just doing the work would be.
The worst part is - no one is in the wrong! The authors write the RFC in good faith, the commenters review the RFC in good faith, and they rightly expect that any problems they identify are addressed. But the whole process can be soul crushingly slow, painful and full of professional conflict.
I’m not saying that RFCs are bad overall, but you have to have a culture of accountability, pragmatism and getting things done to actually make this process work.
In some cases I have seen, people use RFCs to steamroll decisions when they are the only stakeholders. Here the waste comes from the fact that the proposal becomes just a bureaucratic step or a way to diffuse responsibility.
In the case you mention (which I have seen many times) I would say the general issue is that the goals and the constraints are not qualified sufficiently. If that's the case, then there are only 2 cases: there is an objective way to measure if an objection or comment makes sense or not, or it is subjective. If it's objective, then consensus is easy to reach, if it's subjective, it needs to be acknowledged and usually the decisions falls on those who are responsible for the outcome (e.g., the team who needs to maintain or build the thing).
Of course, the debate can move to constraints, goals or even ways to measure, but these are generally more straightforward.