Balaji Srinivasan asks in a Twitter thread why we’re not far more productive given the technology available. Here I collect the five possible explanations he mentions.
- The Great Distraction.
All the productivity we gained has been frittered away on equal-and-opposite distractions like social media, games, etc. - The Great Dissipation.
The productivity has been dissipated on things like forms, compliance, process, etc. - The Great Divergence.
The productivity is here, it’s just only harnessed by the indistractable few. - The Great Dilemma.
The productivity has been burned in bizarre ways that require line-by-line “profiling” of everything. - The Great Dumbness.
The productivity is here, we’ve just made dumb decisions in the West while others have harnessed it.
If I had to choose one of the five, I’d lean toward The Great Dissipation, inventing new tasks to absorb new capacity. This is what happened with the introduction of household appliances. Instead of spending less time doing laundry, for example, we do laundry more often.
Maybe we’re seeing that technological bottlenecks were not as important as we thought.
For example, it’s easier to write a novel using Microsoft Word than using a manual typewriter, but not that much easier. MS Word makes the physical work easier, but most of the effort is mental. (And while moving from Smith Corona 1950 to Word 95 is a big improvement, moving from Word 95 to Word 365 isn’t.)
Technology calls our bluff. Improvements in technology show us that technology wasn’t the obstacle that we thought it was.
The Great Divide: When management and shareholders objectives were more aligned, worker and shareholder objective alignment was forgotten. Productivity comes from workers, not managers. Productivity-> more pay works, productivity-> head count reduction does not.
“… The productivity has been dissipated on things like forms, compliance, process, etc..”
Dissipation. My experience as well.
While more toys (distraction) and other divergence is real, it’s the parasitic administrivia at all levels that takes a toll.
Working in IT used to be pretty damn cool — intersection of Engineering and tinkering and modeling and crafting. I’m sure that’s still out there for some, but the field is awash with process marketers and agilespeak and high finance and software stack “new toy” advertisers, it’s become less fun, more of a technological puppet show.
It’s a Red Queen effect–efficiency improvements eventually just speed up the treadmill.
My experience has been a combination of “The Great Dissipation” and “The Great Dilemma.” The meta-artifacts required to be productive stifle the actual productive output.
If I was asked to organize a filing cabinet, I’m asked to create estimates/tickets/documentation…which require a separate filing cabinet, until my work revolves more around organizing the latter than actually making progress on the original task.
@Ross: I’m largely free from administrivia since I have my own small business, but occasionally I get sucked in to a client’s bureaucracy.
I did some work as a sub- sub- subcontractor to the US government once, and I’d say the ratio of overhead to productive work was about 20 to 1.
Meetings. So. Many. Meetings.
The meetings get to be so frequent that it becomes impossible to prepare for them, not just to come up to speed, but to be ready to contribute. Which results in endless, wandering meetings with insignificant gains. The loss of productivity is astounding.
At one employer I simply stopped attending meetings which failed to meet some simple criteria:
1. A clearly stated goal (purpose).
2. An achievable goal (deliverables).
3. Adequate notice (for preparation).
4. Considerate scheduling (for rest of work day).
5. Appropriate duration (short and sweet rocks).
6. Required preparation (reading list, etc.).
That last one is most important: A meeting needing no preparation doesn’t need to happen! There are important exceptions, such as for social reasons: Awards (and other recognition), major announcements, and general team cohesion. Such social meetings should be marked by also including a meal, to ensure informality and collegiality.
My most hated meeting “excuse” is for “status updates”. To me, that’s a glaring mark of incompetent management. Unless, of course, such meetings **primarily** serve to aid team cohesion, to get folks together and get each of them talking, to introduce new team members. I like scrums and standups: Quick and to the point, setting shared short-term goals, raising issues, letting everyone know what everyone else is working on.
The times I was (briefly) in management, I used a simple meeting rubric: When considering calling a meeting, I’d first add up the work-hour costs and balanced it against the value of the goal. Generally, I would realize I needed either a smaller meeting, or a bigger goal.
Overwork. Find me a study showing that working longer hours produces more productivity. There are so many studies showing that productivity drops as hours increase beyond a certain point. Numerous companies and the entire country of Iceland studied four day work weeks with shorter overall hours and found that productivity goes up.
I will also second the meetings as a cause. Specifically, Agile. Here is how to change a light bulb with Agile. You cannot simply change the light bulb this upsets management. Someone has to take the time to create a user story to change the light bulb. Then, the story has to be groomed where people who know nothing about, or are only vaguely aware of the effort, estimate points for changing the light bulb. Then, there has to be a planning meeting to schedule when the light bulb will be changed. Then, in the sprint where the story has been pulled in an engineer has to go to daily standups wherein the engineer will state that previously he/she did their job and today they will do their job and change the light bulb. Then, another standup to say he/she changed the light bulb. Then, the story goes to QA who files three bugs: 1) that the light is not energy efficient, 2) it is too bright and needs a dimmer switch even though a dimmer switch never existed previously, and 3) they threw a rock at the light bulb and it broke which is a critical bug and must fixed. Then, the engineer has to meet informally with the product manager to agree that the bulb is of the correct type and bug one can be cancelled. The engineer then installs a dimmer switch and a metal shroud around the light bulb so that if someone (who in their right mind?) throws a rock the bulb will not break. QA then files a new bug that the shroud casts shadows. The engineer then has to construct a plexiglass shield for the bulb. All during this someone is spending time updating the user story. Then, there is a demo meeting. Then, a retrospective meeting where there is discussion about what went well and not so well about changing the light bulb. Finally, the light bulb is changed in an Agile manner.
Now, there is another meeting to discuss why the team is not productive enough.
People spend dramatically less time doing laundry today than 100+ years ago, despite wearing far more changes of clothes. Doing laundry used to take many hours of full-focus effort. Now it takes a couple hours for a machine while the overseeing human can do something else in parallel.
If you have never lived somewhere where most people wash their clothes by hand, or never washed all of your own clothes for a few months, it’s a bit hard to imagine.
I’m not sure about laundry in particular, but I’ve seen studies that show the overall time spent on housekeeping hasn’t changed much for generations.
I recall when studying Econ in college, regarding preferences I think, that once a certain income level is reached most people opt out of working more. I think it was billed as leisure vs work preference or something like that. So increasing productivity just means people don’t have to work as much to have the time/resources to pursue “fun” activities. I think the cunundrum is coming from the question of who is valuing the increased productivity. If it is the individual then higher productivity means less work to achieve the same level of leisure. Whereas, if judged from the business management side then higher productivity means lower labor costs for the same output. But economically that frees up available labor to work elsewhere thus making other businesses financially viable. Increased productivity should show up in a wider range businesses or more narrowly focussed businesses (specialization) due to this labor effect.
This also reminds me of a study that showed as cars got safer people just drove faster and took more risks which countered the increase in safety to a degree. One professor joked that if we really wanted safer driving (not cars) we should put a dagger sticking out from the steering wheel. People would be VERY careful and pay attention while driving but it is not known if that would be a net gain — one false move and you’d be dead!
“Technology calls our bluff. Improvements in technology show us that technology wasn’t the obstacle that we thought it was.” True dat!
I might add another time suck:
The Great Perfectionism. With industrial grade document and presentation tools, “good enough” is no longer good enough. So we rewrite, reformat, tweak, illustrate, and animate everything in sight. Forgetting that sometimes you can’t polish a turd.
A little of #2 and a little of #4, but they are both off the mark.
The position that most American businesses are in (doubtless elsewhere as well, but I confine myself to what I have directly observed) is that business processes evolved reactively, mostly by the addition of special cases, for years to decades. That evolution was not documented and the successful execution of the processes depended upon individual expertise and informal, nondeterministic heuristics.
Machines can’t do that. In order to automate such processes, they must first be analyzed as found, then they must be simplified, typically very drastically, and made deterministic so that they can be implemented in software. If they are not made deterministic, they cannot be implemented at all, and if they are not simplified, the code is not maintainable.
This is why there is no gain, and often a large loss, of productivity. It doesn’t matter how fast you get the wrong answer. Wrong answers have to be rolled back and researched. After a time, the effort to research them is abandoned, and the effort to roll them back becomes the successor of the original problem of undocumented knowledge and heuristics.