On Andi Roberts and Communication Patterns Matter | bytecode.news

ByteCode.News<br>Search posts🔍<br>RSS

communicationleadershipmethodologypsychology

Executive coach Andi Roberts wrote "The social physics of conversation: Communication Patterns Matter", a well-researched and well-done essay covering Alex Pentland's work on what makes some groups outperform others.

Pentland focused on "idea flow", how ideas flow through a group and whether the group is thinking together or creating the impression that it's thinking together, while mostly agreeing with a small core.

The research is sound, but Pentland and Roberts both struggle with translating recommendations into practice, and even the recommendations are largely based on assumptions about specific shared physical spaces. When teams "see" each other mostly on Teams or Slack, as in many open-source projects and many commercial ones, the recommendations for the watercooler fail to land: there is no water, there is no cooler.

In The Mythical Man-Month, Dr. Fred Brooks suggested that communication lines were a burden for a team - but that's the colloquial form, and it's not the fair reading. Dr. Brooks said that if each communication line had to be coordinated, then the communication cost compounded, often drastically.

However, this is combining two flows into one: there's a coordination flow, and an idea flow.

Eric S. Raymond made the same split years earlier, in The Cathedral and the Bazaar. He rephrased Linus's Law as "debugging is parallelizable": the crowd of contributors filing patches and bug reports works in parallel, each talking to a coordinating developer but rarely to each other, so the crowd never pays Brooks' quadratic cost1. That cost survives only in the small project core, often a single core developer or a handful of them. Raymond had already pulled the two flows apart: the distributed halo is idea flow, and the small core is coordination.

The assumption buried in Brooks' law is that everyone on a project must talk to everyone else. Raymond's point is that they don't, and shouldn't. Idea flow isn't coordination. Ideas aren't subject, in and of themselves, to coordination; that happens only when the group makes a decision. Treating the idea layer as a coordination problem, and reaching for coordination-shaped fixes, is a category error.

The problem for me is that we have all this material saying "be more collaborative," and "working together works well," all of which seems true - and many of us have seen teams that worked like this, or even been on one, if we were lucky. But description isn't a plan.

Brooks and Raymond and DeMarco and Lister (of Peopleware) did the field a genuine service by describing these teams well - and none of them pretend to hand you one on demand, because there's no such blueprint to hand out.

What I can offer instead is smaller: I've been blessed to serve on some very effective teams, full of people smarter than I am, and I tried to pay attention. A couple of things showed up over and over. Take these as an aperitif to possibly inspire readers to offer their own advice.

One possibility is a simple cultural lever: humor is a fine status-flattener, especially if a team leader uses it, aimed at himself. A "dad joke," even simple "groaners," creates a flat structure that enables free observation, and creates very low stakes for interaction. Once interaction is habitual, expected - because it's more than okay to laugh at bad puns - then serious interaction is a very short step away, and the serious interactions can use the same horizontal span that the jokes do.

Another possibility is borrowed from DeMarco and Lister: low-stakes shared wins! Peopleware suggests easy opportunities to succeed together, best when there's no evident management structure. Again from personal history, one mechanism I've seen is to have a team prepare a simple meal together. Start with a simple suggestion: spaghetti. The team can then decide together whether to make meat sauce, meatballs, marinara, side dishes... and split duties up to complete the meal2. If it fails, as it would when I was cooking, then it's amusing, not tragic - and the process exposes natural team roles with very low stakes3.

Notice what both levers have in common: they're cheap, they're low-stakes, and they build the idea layer without ever touching the coordination layer. That's the point. But not everything belongs on the idea layer.

Some things should be based on coordination, of course: incident command, security disclosure... even architecture should have someone accountable and with decision-making powers, even if they factor in the group dynamics. These are specific cases, though. Ordinarily you'd want a web of communication - a "mesh," in networking terms. A small team can run a full mesh, where everyone genuinely talks to everyone; that's the thing Brooks calculated, and the cost is real, which is why it only works when the team is small. A larger team wants...