Slashdot Mirror
Study Suggests Too Much Collaboration Actually Hurts Productivity (inc.com)
An anonymous reader quotes Inc:
Our attention in the workplace is a precious resource that often falls victim to tools like email, Slack, and so on, which bring a nonstop supply of things to read, things to respond to, things to file, things to loop others in on, things to follow up on, and in general, things to do. This "always on" dynamic has roots in a desire for increased workplace collaboration and productivity, but as is so often the case, it turns out there is a balance to be struck for optimal results. New research shows that groups who collaborate less often may be better at problem solving....
In a study titled "How Intermittent Breaks in Interaction Improve Collective Intelligence", the authors use a standardized problem-solving test to measure the contrast between time spent in collaboration mode against the quality and quantity of problem solving results. The group with no interaction predictably had the highest options for solutions, but those solutions were of lower overall quality. The group with high interaction had higher quality solutions, but less variety and a lower likelihood to find the optimal solution. The intermittent collaboration groups found the desirable middle ground to balance out the pros/cons of the no interaction and high interaction groups, leading them to become the most successful problem solvers.
The article warns of a "collaboration drain", suggesting managers pay closer attention to when collaboration is (and isn't) necessary. "Once upon a time in the land of business, people primarily communicated through conversations, meetings, and internally circulated printed memos. In the absence of email, Internet, cell phones, and CRMs there was a repeating cadence of connection, then disconnection, even while in the office."
"In this case, 'disconnected' really amounts to uninterrupted -- and able to focus."
In a study titled "How Intermittent Breaks in Interaction Improve Collective Intelligence", the authors use a standardized problem-solving test to measure the contrast between time spent in collaboration mode against the quality and quantity of problem solving results. The group with no interaction predictably had the highest options for solutions, but those solutions were of lower overall quality. The group with high interaction had higher quality solutions, but less variety and a lower likelihood to find the optimal solution. The intermittent collaboration groups found the desirable middle ground to balance out the pros/cons of the no interaction and high interaction groups, leading them to become the most successful problem solvers.
The article warns of a "collaboration drain", suggesting managers pay closer attention to when collaboration is (and isn't) necessary. "Once upon a time in the land of business, people primarily communicated through conversations, meetings, and internally circulated printed memos. In the absence of email, Internet, cell phones, and CRMs there was a repeating cadence of connection, then disconnection, even while in the office."
"In this case, 'disconnected' really amounts to uninterrupted -- and able to focus."
But, I've been saying this for over a decade.
'We've got to get Slack and integrate everything into Slack...'
Slack is a waste of fucking time. You thought email was a time sink? Has, Slack and collaboration everywhere is a disaster.
I guarantee you that when Elon Musk spins up a company, they ain't using Sack.
https://dilbert.com/strip/2017...
#DeleteFacebook
Who could have imagined that groups of people spending all their time in meetings or chit-chatting don't tend to accomplish very much?
This is a sickness that flows from the top down. Managers don't produce anything tangible, so the only way they can show "productivity" is to have a full meeting calendar.
One is the very long and well recognized problem that communication is overhead.
Another is exacerbated by the communication problem, when faced with the depressing reality that you can't do things fast enough, businesses think more people == faster. In pursuit of this ideal, work is forcibly divided into uselessly small chunks, requiring insane amounts of coordination and utterly destroying individual competency across the product.
XML is like violence. If it doesn't solve the problem, use more.
Everything defined with "Too much" by definition is not good. I hate when people say or write things that have ambiguous criteria, but just say "Too Much".
"Too much", air and water can kill you.
"Search all your parks in all your cities, you'll find no statues of committees."
Well, except for this one, sort of... https://en.wikipedia.org/wiki/...
Every development position I've had, I spend the first 6-8 months building goodwill and trust. Exceeding delivery times, getting to know what's important to stakeholders, making sure everyone's input is (reasonably) utilized, and testing the hell out of things so they don't break. While those are, on their own, well and good, being on fire for 24 weeks is not my goal.
My goal, in actuality, is eventually avoiding 90% of meetings. The more I can create a sense of "he's on it", the more they leave me the hell alone.
It's worked beautifully everywhere. It ends up being a win-win: I spend more time actually working, and the only time folks in the org see me is when a) I'm listening to what they want and b) I'm delivering to them what they want. Which in turn breeds more goodwill.
TLDR; I love software development. I fscking hate meetings.
https://theoatmeal.com/static/...
so you're saying... TOO MUCH inclusion is actually... a bad thing?
Better delete this post before the "alt-right" people use it to create a legion of super soldiers.
In otherwords, everyone in moderate America already knew this.
What's next, Contributor Code of Conducts is about adding more useless people to projects instead of maximizing productivity? Nah, that'll never happen.
Developers shouldn't be using email, slack, ... to collaborate. They should all be sitting in a massive open office, working elbow-to-elbow with each other!
Coming up next: water is wet, air contains oxygen, men think dirty thoughts about women all the time.
I envy the chutzpah of "researchers" who got the grant for this. Any grunt from any megacorp which emphasizes sitting in meetings will attest that at one point or another they couldn't get _any_ work done while at work, and had to do it at home. I spent years working like this at MS in early 00's. Substantial portions of one of their most successful products were written by me on my Dell Inspiron laptop, from my couch in a tiny rented apartment in Redmond. Thank god for Remote Desktop. At work, we had 1:1 ratio between developers and PMs. PMs had to justify their existence, so they'd pester devs to write specs for features, then pass them off as their own work, and then rigidly schedule everything with arbitrary deadlines, and spend the rest of the product cycle "reporting status" to one another, and "managing" the bug backlog (which manifested mostly in "punting" bugs to v.next and releasing a buggy product before an artificial deadline). And of course they'd schedule an endless array of meetings to bikeshed over the most inane and immaterial bullshit, and they'd drag devs into those meetings too.
Google was heaven after this. Holy shit, I could actually get things done _at work_ (and easily 3x as much work, too), and not have to work weekends, and my team had a grand total of two meetings a week, and one of those was optional (a "chalk talk" to deep dive on new features in the product, or discuss interesting papers). No slack, no meetings, no "stand-ups", just raw, unbridled productivity.
This also has a good side effect: when it is expected that people would actually do significant quantities of high quality work, and not just bullshit all day, those who can't pull their weight leave pretty quickly, which has a multiplicative effect on the overall productivity.
The study would have come out last year, other than the fact that it had multiple authors.
"National Security is the chief cause of national insecurity." - Celine's First Law
News at 11!
Followed by our story on 60 people trying to put in a wooden post.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
go figure. ho hum.
As a developer, "collaboration" and "agile" usually means I do all the work while Product Owner and UX Designer chat up girls in the break room.
It seems obvious that if you need to say something meaningful and non-trivial at a meeting, you must first spend time alone to observe, think, experiment, or whatever is appropriate to the subject.
spoil the broth
Too much collaboration == endless meetings.
is they're placing organisational work flow under the title of collaboration.
Working Scrum environments are rare in my experience. For example, when a daily standup meeting goes 4-6 hours minimum, with everyone whining, "I'm blocked! Blame him!" and pointing fingers at someone else for every thing in their swim lanes, it gets old. Or a manager demanding to keep the dev team always in sprint mode, because marketing demands their deliverables that were already sold to customers, and the devs are always in a fire-fighting mode, trying to code something in place to make the customer happy (and keep their job), the fix stuff later.
In fact, because of this daily push for deliverables, and when they are done, marketing heaps more, extreme shortcuts are taken. I have seen developers have all their production code run as root, with a DB user with full permissions (and doing a quick check... no full rights, code exits.) They feel that if a security hole gets exploited and made public, with lawsuits happening, they have layers of corporate bureaucracy protecting them, while failing to make a deliverable too often will get them to get pink-slipped, so security, readablity go out the window. Technical debt? That's for the next schmoe to deal with, because there is no time, ever, to refactor and fix the fact that code is a tangled mess of garbage.
Standup meetings are pointless, because they turn into blamestorming fests, and after lunch, little winds up getting done anyway other than finding another blocker to point at for tomorrow's kangaroo court.
Of course that's the case, collaboration is one 1/3 of the work. You also have to stop and listen.
This is my signature. There are many like it, but this one is mine.
Ice is water but not wet. There are also many planets were air contains no oxygen. I am not trying to be a smart ass but instead remind you that things are not usually as simple an obvious as it seems.
Well, there is this old saying: "Too many cooks spoil the broth"
Nuff said
Clive DaSilva Email: clive.dasilva@gmail.com Ubuntu 18.10 Kernel 4.18
Sometimes, it's useful to have actual testable, documented, statistical evidence for "common-sense" knowledge. Particularly in these days of "manage by metrics" - no amount of common-sense arguments will carry the day over a well designed numerical evaluation.
And, as others have noted, sometimes the "common-sense" things aren't.
...no no. We don't need to hear any more. That'll be all. You're dismissed.
Thanks again.
It's the three hole problem. Sometimes hearing a bad idea just gets it stuck in your head, and despite knowing there is a better alternative, you just can't think of it anymore.
Computers deal with this problem all the time, within their own circuitry. On one hand, it makes sense to split up the work among multiple processors or cores. But the more parallelism that is applied to a job, the more communication overhead is required. The trick is to find the right balance. That is why, for example, database servers let you set the maximum degree of parallelism--Max DOP--so that you get the optimal balance between multiple tasks being done at once, and not too much communication overhead.
It's really the same problem with teams. Balance is key.
Coming up next: water is wet, air contains oxygen, men think dirty thoughts about women all the time.
That is incorrect. Between around 11 PM to 7 AM, I don't think about them at all. Now DREAMING about them is another matter.... ;)
This finding wouldn't seem to be Common Sense for a manager (loosely defined...), whose major "tool" is communication, and to whom collaboration is seen as a way to get things done efficiently...
Common sense is continually conflated with "absolute and obvious truth", when in fact a given subject often has multiple facets, each with its own "common sense" perspective.
Amdahls law is a great way of thinking about it. But I think reality is even worse: Amdahls law shows you the limit in efficiency given a parallelizable fraction of the work. But my experience is that context switching is also an expensive thing for humans. When I start programming, it usually takes 2 hours to get in the zone and reach peak productivity. If you interrupt that work with a 1-hour meeting in the middle of an 8-hour day, I go from perhaps 6 to 3 work hours at peak productivity... (Because of this, I prefer to schedule as many meetings as possible on the same day when possible.)