Life just got so complicated. I tried to fight back, to have less stuff to think about, but it's an endless onslaught of abstract microtasks. No wonder that white collars dream of a homestead
These systems try to force humans to disregard their unpredictable lives, and produce with the predictability of machines. It's not right.
I'm at my happiest when I wake up without an alarm, and work on what feels right until I feel done for the day. I let the most important stuff float to the top, instead of shaming myself into satisfying my past ambitions.
Aside: This title pattern rubs me the wrong way. The rise of this, the death of that. Half the time, it's either something happening in California, or in a very small twitter circle. The other half, it has not risen, or not fallen. Its a the "it was a dark and stormy night" of headlines.
I agree with you on all counts, and would like to elaborate a bit: I think obsession with todo lists mistake the product for the process. The goal of producing todo lists is to survey our responsibilities, rank them and break down goals and projects into chewable bits. Not to curate an ever growing list of ambitions.
Tangentially, I like to break down projects and tasks by cognitive load, not by expected duration. This, in my opinion, is also a fundamental misunderstanding in Agile project management. Wrangling about story points and deadlines is a way to press people to fall in line, it is designed and operated as a stressor. It's malicious in nature and consequences.
What should be done, I think, is breaking down things into bits that can be comfortably held in people's minds as a whole. Then people can attack it ergonomically for as long as necessary to get it done. Now. this creates complications because we have to accommodate for different levels of skill, experience, capacity etc. But a well composed team should have a nice combination of leadership and experience to tackle this.
The problem arises from trying to push down on labor costs and pressing software enthusiasts into becoming hired hands in a production line.
Though Gibbons' famous work comes in six volumes and covers more than a millenium of history, the rise of the Roman Empire was outside its scope. It was titled The History of the Decline and Fall of the Roman Empire.
I don't understand why there is a glorification of death or celebration of death.
I prefer to focus on the good and the light and birth and growth, not glee in dark expressions.
If you can make an economy where everyone has freedom to do what they want when they want, maybe the best and brightest could work on how to achieve this and utopia (I'm serious)
Just sharing my own experience, but the more time I've spent contemplating death the easier time I've had with it: Every beginning implies an end. Every birth and growth implies a decline and death. All coming-together results in eventual separation. Etc.
IMO there's nothing wrong with finding the beginnings more fun and enjoying the fun parts, but part of what prevents us from moving towards utopia is a blindness to the whole cycle, an unwillingness to engage in the difficulties of endings and change. This isn't to say we need to celebrate "the end" either, but just that in some sense, contentment _is_ utopia, and contentment requires making peace with both beginnings and ends.
>If you can make an economy where everyone has freedom to do what they want when they want, maybe the best and brightest could work on how to achieve this and utopia (I'm serious)
Who is going to scrub the toilets and change adult diapers in the meantime?
> Consider instead a system that externalizes work. Following the lead of software developers, we might use virtual task boards, where every task is represented by a card that specifies who is doing the work, and is pinned under a column indicating its status.
I read this whole thing just to find out it's an ad for Jira?
I still do things in a GTD-like way despite Jira because every epic/story/issue/task/subtask is always horribly underspecified when it's not written by another dev and I still need to keep track of that work.
Often there's some overlap of the work, but I dare not show those cards. The best I can do is give a story point estimate and say if it can be finished by this sprint. If not for some kind of personal productivity methodology where does that aspect of work go? Jira boards can lead to micromanagement in the wrong hands because the broader organization lacks the specificity and rigor of the devs. They simply don't understand the work they're describing well enough. Nothing has changed in at least the last 30 years from the perspective of the knowledge worker.
What will really change things is to stop promoting non-technical people into leadership roles when technical work is the core competency.
In sum, the article notes that in the industrial age all efficiency was essentially structural efficiency. In the information space that has become personal efficiency. The article suggests (via the example of Merlin Mann) that personal efficiency is potentially a losing battle, and suggests we should (in part) seek to offload some of this efficiency burden to be structural efficiency.
Hence, my take-away, the article discusses the tension of productivity as it comes from the organization and as it comes from the individual. Historically production line efficiency was gained by the organization optimizing how individuals perform. That has evolved to a technology and information space where it is _only_ the individual that can optimize their productivity.
The article essentially ponders the culture that this individual productivity pr0n has created. The mentions about Jira/Sprint style organization seemingly are thoughts & suggestions for how efficiency can in part be driven by the organization so that there is structural efficiency and not only individual efficiency.
There are a few examples as well of how personal efficiency can drive organization wide inefficiency (eg: blasting out an email with a question and demanding an immediate answer, efficient for one, and not efficient for the other).
One of the last sentences in the article summarizes this:
>> We must, in other words, acknowledge the futility of trying to tame our frenzied work lives all on our own, and instead ask, collectively, whether there’s a better way to get things done.
For me, GTD's biggest contribution was the focus on "Next Action". Which was mentioned exactly once in the article. I struggle with the perfect lists and I just can't get the Weekly Review figured out. But looking at some project and figuring out the exact Next Action (and sometimes associated Critical Path) is ridiculously valuable.
I've read a bunch of other productivity books. They have different ideas and approaches, but all of the practical ones seem to have this moment "and figure out the smallest, actionable thing you can actually do on that". But often, that bit is not front and center of the methodology. I suspect in the "3-day master course" for those techniques, they would actually practice such focus. David Allen just really put that front and center, explicitly.
Similarly, the Cognitive Behavior Therapy also uses this "Next Action" idea to get the person to move forward.
In that sense, I felt the article failed to truly look behind the curtain and just focused on a rise and fall of individual movement influencer. I did not see any mention of Lotus Notes (David Allen's own preferred solution), active GTD LinkedIn group, etc.
You know, I wonder if there's a way to make bug/task tracking systems like Jira show a "Next Action" view. Like, don't show me the list of bugs/tasks/burndown items I have assigned, don't tell me how many there are, don't show me any alerts, just show me the appropriate Next Action, based on whatever prioritization scheme my team is using, and don't even let me see the rest until I take some active step (including sleeping) on this one.
"Next Action" never worked for me because some things are only a few actions total, but others are hundreds and need to be done sequentially all before the end of next month. By looking only at next actions the difference wasn't clear enough.
Whereas weekly / monthly reviews work very well for me to see patterns in what works and what doesn't, see where I need to spend some time planning, etc.
But I do this in a "bullet journal" type of setup, not the "getting things done" method.
GTD has support for that with its "Project Support" documents, higher-level reviews, multiple Next Actions for same project, etc. I feel it does cover the situation, and you can still do it just when you run out of obvious things to do or stop for the day.
The "Next Action" is really just to ensure you know what actually can be done and when and not just have the project (e.g. "Buy car") as the action.
My one philosophical takeaway from GTD is the idea of offloading the record keeping and logistics of tasks to some slower external system.
This allows the "RAM" or faster context of your thinking to be focused entirely on what you're doing.
Every system built on top of this (including GTD itself) is just an interpretation of this core idea that GTD points to that have unique selling points.
For example, ticketing systems inspired by toyota-scrum-agile externalize work in a way so that you can debug bottlenecks. GTD itself focuses on capture and filtering. Newer "second brain" stuff focuses on the knowledge management itself.
These external systems tend to grow until they require a dedicated cabal of priests to manage them. Since these systems measures all "progress", individuals then become incentivized to align with the priests (or become one).
Eventually the finger that points to the moon becomes the moon itself. The system was intended to allow you to focus on The Important Thing but instead becomes The Important Thing itself.
I spoke to Cal for this article though I don't think he used much of our interview. I developed GTD software back in the first as Kinkless when became OmniFocus after I joined Omni for a year.
Today I don't use any "super specialized" tooling for task management. Intentionally. I don't like being wedded to any given app. My tools are Apple Reminders (universal for my family since we're all on Apple devices) and Obsidian (or really just plain text / markdown, accessed currently through obsidian).
Lots of thoughts about all this but in short there were some good ideas I took from GTD (universal capture being the biggest, but that's not really a GTD unique idea) but most of it I've jettisoned.
(my obsidian / markdown usage is basically "take notes, sometimes notes become projects, those projects automatically show up in a dashboard" and mixing notes, content, and tasks organically)
I'd love to see a blog post about your apple reminders/obsidian setup (or whatever details you'd be willing to provide). I'm currently trying to get an apple reminders + obsidian setup up and running myself!
I love seeing all the comments in this thread talking about things they use from GTD. I also extracted a ton of useful tips, tricks, and concepts from GTD that are now just part of my working life. Thinking through concrete next actions, having an inbox to throw things everything, having dedicated time to process through my inbox and think through priorities, putting anything involving time on my calendar (including "tickler" reminders to think about and take action). One time I showed a friend the GTD book. She opened it to a random page, read for a moment, and said "oh! I can use this technique!" and she incorporated it.
It seems the article's claim is that GTD takes an individual approach whereas it might be more fruitful to take a systemic approach — why is GTD needed in the first place (tons of ad-hoc tasks generated by others for you) and is there a way to obviate the need for it upstream? I'm pretty sympathetic to this argument. We humans can stretch our capacity for cognitive work quite far, but I think almost everyone has had the experience of overload when our natural human limits are stretched for too long.
I think if the author wanted to develop this argument he wouldn't have stopped with suggesting a limp theoretical proposal but done an empirical investigation of organizations that already did what he was proposing and how it went a la Frederic Laloux's brilliant "Reinventing Organizations". Or maybe just build the software and studied how organizations used it. Maybe Newport did some of that in his books, I'm not sure.
Quite a lot of this resonated. A long way through though:-
> What if you began each morning with a status meeting in which your team confronts its task board? A plan could then be made about which handful of things each person would tackle that day.
Maybe it's the kind of software I work on (non-web), seems a bit unreal to expect developers to deliver a "handful" of non-trival things per day. Fastest thing is generally (which fits with higher up the article) ask for one thing to do done, and to leave the developer alone (at least, until they miss a milestone - and even those need to be appropriately set).
I feel most of the time these "Productivity tips and tricks" are like the "lifehacks" for the work like, they're more trouble than their worth some 99% of time
The current fad is Notion and all the minor templates for productivity guided people (the ones that need to follow their morning schedule with minute precision)
I found GTD to be revolutionary for me at that time, at my age then. His statement, "You can't do projects, you can only do actions related to projects" was very useful to me -- unstuck me many times from analysis paralysis.
New SOPs are forced stimulation...a shared hallucination of sorts. I get the impression they resonate with the ADHD crowd, who need novel ways to motivate themselves to do the same boring shit every 5-10 years.
(Or, project managers who need a way to define work output in the face of engineers that have learned how to game the old system.)
> "project managers who need a way to define work output in the face of engineers that have learned how to game the old system"
I think there's an enormous difference between a) an individual task tracker maintained by you, only for you, of tasks you'll work on...
...vs b) an agile task board or whatever for a (corporate) group, where there is often ongoing lack of clarity about task definition, prerequisites, acceptance criteria, as you say people may be trying to game it to make their individual productivity metrics look better (or at least to defend their apparent productivity from being damaged by the aforementioned group pitfalls). Really these can be two quite different animals.
With a), you should have pretty good clarity about what the implied 'Next Action' is for each task, whereas with b), it may require group discussion, prioritizing, meetings, etc., sometimes even hiring or outsourcing.
Readit News
Life just got so complicated. I tried to fight back, to have less stuff to think about, but it's an endless onslaught of abstract microtasks. No wonder that white collars dream of a homestead
These systems try to force humans to disregard their unpredictable lives, and produce with the predictability of machines. It's not right.
I'm at my happiest when I wake up without an alarm, and work on what feels right until I feel done for the day. I let the most important stuff float to the top, instead of shaming myself into satisfying my past ambitions.
Aside: This title pattern rubs me the wrong way. The rise of this, the death of that. Half the time, it's either something happening in California, or in a very small twitter circle. The other half, it has not risen, or not fallen. Its a the "it was a dark and stormy night" of headlines.
Tangentially, I like to break down projects and tasks by cognitive load, not by expected duration. This, in my opinion, is also a fundamental misunderstanding in Agile project management. Wrangling about story points and deadlines is a way to press people to fall in line, it is designed and operated as a stressor. It's malicious in nature and consequences.
What should be done, I think, is breaking down things into bits that can be comfortably held in people's minds as a whole. Then people can attack it ergonomically for as long as necessary to get it done. Now. this creates complications because we have to accommodate for different levels of skill, experience, capacity etc. But a well composed team should have a nice combination of leadership and experience to tackle this.
The problem arises from trying to push down on labor costs and pressing software enthusiasts into becoming hired hands in a production line.
I prefer to focus on the good and the light and birth and growth, not glee in dark expressions.
If you can make an economy where everyone has freedom to do what they want when they want, maybe the best and brightest could work on how to achieve this and utopia (I'm serious)
IMO there's nothing wrong with finding the beginnings more fun and enjoying the fun parts, but part of what prevents us from moving towards utopia is a blindness to the whole cycle, an unwillingness to engage in the difficulties of endings and change. This isn't to say we need to celebrate "the end" either, but just that in some sense, contentment _is_ utopia, and contentment requires making peace with both beginnings and ends.
Who is going to scrub the toilets and change adult diapers in the meantime?
I read this whole thing just to find out it's an ad for Jira?
I still do things in a GTD-like way despite Jira because every epic/story/issue/task/subtask is always horribly underspecified when it's not written by another dev and I still need to keep track of that work.
Often there's some overlap of the work, but I dare not show those cards. The best I can do is give a story point estimate and say if it can be finished by this sprint. If not for some kind of personal productivity methodology where does that aspect of work go? Jira boards can lead to micromanagement in the wrong hands because the broader organization lacks the specificity and rigor of the devs. They simply don't understand the work they're describing well enough. Nothing has changed in at least the last 30 years from the perspective of the knowledge worker.
What will really change things is to stop promoting non-technical people into leadership roles when technical work is the core competency.
Hence, my take-away, the article discusses the tension of productivity as it comes from the organization and as it comes from the individual. Historically production line efficiency was gained by the organization optimizing how individuals perform. That has evolved to a technology and information space where it is _only_ the individual that can optimize their productivity.
The article essentially ponders the culture that this individual productivity pr0n has created. The mentions about Jira/Sprint style organization seemingly are thoughts & suggestions for how efficiency can in part be driven by the organization so that there is structural efficiency and not only individual efficiency.
There are a few examples as well of how personal efficiency can drive organization wide inefficiency (eg: blasting out an email with a question and demanding an immediate answer, efficient for one, and not efficient for the other).
One of the last sentences in the article summarizes this:
>> We must, in other words, acknowledge the futility of trying to tame our frenzied work lives all on our own, and instead ask, collectively, whether there’s a better way to get things done.
For me, GTD's biggest contribution was the focus on "Next Action". Which was mentioned exactly once in the article. I struggle with the perfect lists and I just can't get the Weekly Review figured out. But looking at some project and figuring out the exact Next Action (and sometimes associated Critical Path) is ridiculously valuable.
I've read a bunch of other productivity books. They have different ideas and approaches, but all of the practical ones seem to have this moment "and figure out the smallest, actionable thing you can actually do on that". But often, that bit is not front and center of the methodology. I suspect in the "3-day master course" for those techniques, they would actually practice such focus. David Allen just really put that front and center, explicitly.
Similarly, the Cognitive Behavior Therapy also uses this "Next Action" idea to get the person to move forward.
In that sense, I felt the article failed to truly look behind the curtain and just focused on a rise and fall of individual movement influencer. I did not see any mention of Lotus Notes (David Allen's own preferred solution), active GTD LinkedIn group, etc.
"Next Action" never worked for me because some things are only a few actions total, but others are hundreds and need to be done sequentially all before the end of next month. By looking only at next actions the difference wasn't clear enough.
Whereas weekly / monthly reviews work very well for me to see patterns in what works and what doesn't, see where I need to spend some time planning, etc.
But I do this in a "bullet journal" type of setup, not the "getting things done" method.
The "Next Action" is really just to ensure you know what actually can be done and when and not just have the project (e.g. "Buy car") as the action.
This allows the "RAM" or faster context of your thinking to be focused entirely on what you're doing.
Every system built on top of this (including GTD itself) is just an interpretation of this core idea that GTD points to that have unique selling points.
For example, ticketing systems inspired by toyota-scrum-agile externalize work in a way so that you can debug bottlenecks. GTD itself focuses on capture and filtering. Newer "second brain" stuff focuses on the knowledge management itself.
These external systems tend to grow until they require a dedicated cabal of priests to manage them. Since these systems measures all "progress", individuals then become incentivized to align with the priests (or become one).
Eventually the finger that points to the moon becomes the moon itself. The system was intended to allow you to focus on The Important Thing but instead becomes The Important Thing itself.
Today I don't use any "super specialized" tooling for task management. Intentionally. I don't like being wedded to any given app. My tools are Apple Reminders (universal for my family since we're all on Apple devices) and Obsidian (or really just plain text / markdown, accessed currently through obsidian).
Lots of thoughts about all this but in short there were some good ideas I took from GTD (universal capture being the biggest, but that's not really a GTD unique idea) but most of it I've jettisoned.
(my obsidian / markdown usage is basically "take notes, sometimes notes become projects, those projects automatically show up in a dashboard" and mixing notes, content, and tasks organically)
Can't believe that it's now 17 years ago!
It seems the article's claim is that GTD takes an individual approach whereas it might be more fruitful to take a systemic approach — why is GTD needed in the first place (tons of ad-hoc tasks generated by others for you) and is there a way to obviate the need for it upstream? I'm pretty sympathetic to this argument. We humans can stretch our capacity for cognitive work quite far, but I think almost everyone has had the experience of overload when our natural human limits are stretched for too long.
I think if the author wanted to develop this argument he wouldn't have stopped with suggesting a limp theoretical proposal but done an empirical investigation of organizations that already did what he was proposing and how it went a la Frederic Laloux's brilliant "Reinventing Organizations". Or maybe just build the software and studied how organizations used it. Maybe Newport did some of that in his books, I'm not sure.
> What if you began each morning with a status meeting in which your team confronts its task board? A plan could then be made about which handful of things each person would tackle that day.
Maybe it's the kind of software I work on (non-web), seems a bit unreal to expect developers to deliver a "handful" of non-trival things per day. Fastest thing is generally (which fits with higher up the article) ask for one thing to do done, and to leave the developer alone (at least, until they miss a milestone - and even those need to be appropriately set).
The current fad is Notion and all the minor templates for productivity guided people (the ones that need to follow their morning schedule with minute precision)
Incidentally, I enjoyed implementing it via "The Secret Weapon" https://thesecretweapon.org
(Or, project managers who need a way to define work output in the face of engineers that have learned how to game the old system.)
> "project managers who need a way to define work output in the face of engineers that have learned how to game the old system"
I think there's an enormous difference between a) an individual task tracker maintained by you, only for you, of tasks you'll work on...
...vs b) an agile task board or whatever for a (corporate) group, where there is often ongoing lack of clarity about task definition, prerequisites, acceptance criteria, as you say people may be trying to game it to make their individual productivity metrics look better (or at least to defend their apparent productivity from being damaged by the aforementioned group pitfalls). Really these can be two quite different animals.
With a), you should have pretty good clarity about what the implied 'Next Action' is for each task, whereas with b), it may require group discussion, prioritizing, meetings, etc., sometimes even hiring or outsourcing.