Hacker News new | past | comments | ask | show | jobs | submit login
How intermittent breaks in interaction improve collective intelligence (pnas.org)
109 points by mpweiher on Aug 14, 2018 | hide | past | favorite | 16 comments



I'd be careful about trying to extrapolate this to everyday work situations.

They were performing a very specific task (solving a traveling salesman problem) that had a clearly-defined optimum solution and little room for a lot of the kinds of thinking that are needed in business scenarios, such as challenging the business case and lateral thinking.

I didn't notice them stating a overall duration for the experiment (admittedly I did skim), but it sounds like it took place over the course of, at most, hours - not the weeks, months or years that would be relevant to someone trying to optimize a product development process. That means that their "intermittent communication" case probably still involved communication at a frequency that would be downright unsustainable in a business setting, and would certainly be something most of us would think of as "constant". For example, assuming the experiment took place over 2 hours, then the intermittent communication group would be taking a look at each other's work about every 20 minutes.

(edit: I checked again, and caught it - looks like I was being generous in my time assumptions. An entire trial lasted no longer than 14 minutes. The "constant" group was checking in with each other at least every 50 seconds, and the "intermittent" group at least every 2.5 minutes.)

It's still an interesting result, mind. But it's not going to support anyone's position on the value of daily stand-up meetings.


Key takeaway from the paper

> Instead of supporting more transparency, the results imply that technologies and organizations should be redesigned to intermittently isolate people from each other’s work for best collective performance in solving complex problems.

In addition, Jesse C. Shore, the author posted a Twitter thread summary about this research [0, 1].

> when people interact intermittently (as opposed to constantly or not at all as in previous work), they explore on their own AND learn from each other.

[0] https://twitter.com/jessecshore/status/1029124892439072768

[1] https://threadreaderapp.com/thread/1029124892439072768.html


redesigned to intermittently isolate people from each other’s work

Why does the organization need to be redesigned? How about we just stop trying to micro-engineer interactions, give knowledge private, quiet work space, and let them do their thing.

This is what most knowledge workers do that I've seen, when left to their own devices: first they put their head down and try to work on a problem, come up with some promising solutions and/or find some sticking points, talk it over with colleagues, then go back to work on it solo some more. Repeat until convergence or deadline arrives.


Wow just at a time I was considering this. So currently in a workshop doing an evaluation with a group of people and the amount of group think that starts to occur is unbelievable. You notice it when people start ignoring relevant information. So wrote the problem down and came up with a solution of doing a split between: 1-formulate your own ideas. 2. Then meet and discuss.

Based on this maybe ideal maybe 1. Formulate own ideas 2. Meet 3. Forumulate own ideas 3. Meet


Seems like an interesting parallel to this US Army discovery: https://arstechnica.com/information-technology/2018/04/army-...

Over communicating may increase velocity, but it seems it decreases overall quality.


On a related note, I've often wondered how the normalization of knowledge-seeking via Google affects collective and peak intelligence across a population.

My naive guess is that fast, normalized access to information increases mean intelligence, but decreases peak intelligence. I have a hunch that the production of positive outliers requires input volatility.


Good result and makes sense. Sometimes people need to step away to have time to consider and integrate the new facts and perspectives they've been presented so they can attack the problem from a different perspective. Forcing continued debate can cause people to dig in on their view of the problem.


> Forcing continued debate can cause people to dig in on their view of the problem.

Yes, I've seen it. It's refreshing when people quit talking and build their debate position as in Napster[0], the RFCs[1], and even the Nail Cabinet [2]

[0] https://abcnews.go.com/Technology/story?id=98865&page=1

[1] https://tools.ietf.org/html/

[2] https://craftcouncil.org/post/garry-knox-bennetts-notorious-...


Interesting parallel between this result and the technique of "dropout" which is a key technique used today in training neural networks that has found to prevent the network from overfitting to a locally optimal solution by randomly disconnecting nodes.


Good, so it is in line with open offices being bad because of the constant interaction and interruptions


So pair programming is a bad idea?


Shocks me that you're getting downvoted for this because that's exactly what the results would imply. Of course that's in regard to the Extreme Programming always on, constant pair programming approach. Pair programming isn't totally bad of course, and has its place, but yeah the results would seem to imply that consultancy-style (I'm looking at you, Pivotal) pair programming is a good way to produce reliably mediocre code with a body shop.


Ha! Field of software programmers act like a hive mind. People latch on to something and then it becomes their religion. Any criticism causes hurt feelings.

I've been programming for long time and have seen these trends come and go. Right from xml being the best thing since invention of wheel to micro services being elixir to all programming woes.


No, it's a good idea, but it's better in combination with solitary work.


Nope, it is an excellent idea. Just not all the time.


I enjoy pair programming on occasion, but I can imagine doing it all the time could be detrimental.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: