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."
https://dilbert.com/strip/2017...
#DeleteFacebook
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.
That's the one thing I've always liked about Scrum. A nice quick meeting and then everyone goes off to do their own thing and if there are problems, the collaboration can occur on a limited basis involving only the people who need to be involved. Anything else can probably wait until the next daily standup.
On a side note, managers who try too hard (i.e., meetings, meetings, meetings, and more meetings) are worse than no managers at all. If you've never had a good manager, that's a pity because they're worth their weight in gold. The problem is that it's pretty difficult to find a person who has the necessary technical skills to be able to understand and contribute to a project along with the rest of the skill set that makes for effective management. Too often you end up with someone who's technically brilliant but deficient in everything else, or someone who might have some managerial chops, but no real knowledge about the technology or tools behind the project.
"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.
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
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.