3 ms·
There are many good points here. Companies depend on in-person proximity for automatically communicating. The article identifies a few cases where remote struct
by vii 6y ago
There are many good points here. Companies depend on in-person proximity for automatically communicating. The article identifies a few cases where remote structures fail, like in responding quickly to new circumstances but it's a more general problem.
Ideally, groups manage to articulate priorities in a planning process and share what people are working on. However, these processes sometimes do not exist, and when they do they rarely identify all the work. People are regularly drawn into unplanned work, e.g. helping other teams. Also, to excel as an knowledge worker (e.g. software engineer) you need to have a few experimental projects, too risky to fit into the planning process and which should not be discussed there. Getting help and mentorship on these can greatly accelerate career growth, and that's often what people do late at night in the office. This is definitely not inclusive, but is how people signal that they are going above and beyond.
Remote work exposes the gaps between official processes and the informal ones that spring up to enable human collaboration. Making these explicit would be valuable for fairness, to help people without experience understand what is really going on.
Doing that is very hard. If these informal power dynamics were documented, indubitably they would be improved; they are very often unfair. Another way of looking at it, is that the informal processes typically fill in gaps in poorly designed formal processes :) It would take extraordinary organisational maturity to be comfortable sharing this dirty laundry.
In summary, companies that go more remote will find ways to fill the gaps that are currently patched over by in person proximity, and this is for the best as it means tackling tough cultural painpoints
- xfour 6y agoThis is a great way of articulating this issue. A engineering group I interact with loathes to document or version their code, and they maintain this in-crowd mentality that I call Arms-Length development. It works great when everyone is in the know because they’re so close to one another but breaks down quickly, and will see increasing frustration with this attitude as we remain remote for longer and longer and forever, eventually. It seems like the engineering in one place as the rule rather than the exception is flip flopping.
- ghaff 6y agoThe one comment I'd make is that lots of companies already have distributed teams and, in the case of open source software, are typically working with outside people distributed all over the place. So "in-crowd mentality" is pretty much an anti-pattern as soon as the butts-in-seat co-located assumption is broken for whatever reason.