While in India: Osmotic communication
One of the things that has been puzzling me during my time in India is the amount of time that is spent in meetings pushing information to people rather than them pulling it.
In previous projects that I’ve worked on a lot of the knowledge was moved between around as a result of osmotic communication
Osmotic communication means that information flows into the background hearing of members of the team, so that they pick up relevant information as though by osmosis. This is normally accomplished by seating them in the same room. Then, when one person asks a question, others in the room can either tune in or tune out, contributing to the discussion or continuing with their work.
After thinking about it a bit more I’ve identified a few reasons why I think this approach doesn’t work so well on my current project.
The ability to ignore background noise
The ThoughtWorks Pune office is pretty much one big room with over 100 people in it so the amount of background noise is fairly constant.
When we’ve tried to run our standup near where we sit it’s been impossible to hear people standing 5 or 6 metres away from you.
You therefore end up getting into the habit of blocking out anything going on around you as was evident when there was drilling being done in the office.
The side effect of doing this, of course, is that there could be relevant discussions going on around you and you’d be much less likely to notice.
Team size/distribution
The second problem is that the team is distributed which means that we’re never going to overhear any conversations in Chicago and vice versa.
To add to this our team is now 25+ in size so it’s spread out over 3 tables one of which is only within shouting distance.
Martin Fowler wrote an article about team rooms quite recently and while the ideas make sense I’m not sure how they scale as team size increases.
Overlap of roles
Although this by no means applies to everyone that I’ve worked with I’ve noticed a tendency for people to stick to their role much more than I have in other countries.
Therefore a developer will only do 'developer tasks' and a QA will only do 'QA tasks' for example.
When you have overlap such that a developer may be 'pairing' with a QA or BA on something then the types of conversations that are head seem to lead to information moving around the team more effectively.
About the author
I'm currently working on short form content at ClickHouse. I publish short 5 minute videos showing how to solve data problems on YouTube @LearnDataWithMark. I previously worked on graph analytics at Neo4j, where I also co-authored the O'Reilly Graph Algorithms Book with Amy Hodler.