|||
Gli ambienti di pensiero integrato
Just a quick note of gratitude. Antonio Dini has generously translated my article “Obsidian, Roam, and the rise of Integrated Thinking Environments—what they are, what they do, and what’s next” into Italian. Exciting!
Thanks, Antonio. I hope Italian readers find the concept useful.
In Getting Things Done, a “next action” is a specific idea. Morten Røvik defines it like so:
a physical, visible action, somebody can see you do, that you can do in one sitting and where you have everything you need.
A project is any outcome that needs you to complete more than one next action to realize it.
In the past, when thinking about a project, I generally planned out next action_s_. I tried to think of everything all of the time, robustly listing out the tasks it would take to get a project from start to finish. Naturally, this leads to impressive lists of things to do. It’s a great way to feel busy. But is it a great way to be productive?
In the past year, I’ve come to realize that this “what are my next action_s_?” habit is probably bad practice. These next action_s_ lists are both a deterrent to actually getting things done, and they’re a waste of time to boot.
They deter productivity because—at least for me—these lists were often intimidating. The project “publish paper” would end up having a half-dozen mini-projects embedded inside it, each with dozens of tasks (and possibly other sub-projects). Pulling up these lists easily overwhelmed me, and the resulting anxiety was always tough to deal with.
Perhaps worse than being intimidating, though, is that these lists of next action_s_ were never as useful as I thought they’d be. In knowledge innovation, what you do later depends on what you do next. Projects change over time—especially big projects. You can guess at what the work will look like, but you will probably be wrong. At least, I was often wrong. As a result, the time I spent planning too far ahead was often a waste.1
What’s the takeaway? Take away the plural!
I am going to try not to worry about next action_s_. Instead, for any given project, I will only identify one thing: what the next action is. There’s only one. Once I decide what that is, I can do it, and then decide what the next action is after that. This incrementalism will make it easier to engage with the big, messy work I’m doing, and it will prevent me from wasting time with premature optimization.
It is important to differentiate between project planning and checklists, here. For example, most scientific articles have the following sections: Introduction, Methods, Results, Discussion. So, you could create a “Write paper” project with the next actions “Write Introduction,” “Write Methods,” “Write Results,” and “Write Discussion.” But this isn’t actually a useful action list: it’s a checklist. You’re pattern-matching a template against what you’ve done to make sure you did everything you’re supposed to do. It can be handy to have checklists, but they don’t really support knowledge innovation, because it isn’t surprising or unexpected for you to do those four tasks. The work of knowledge innovation is, of course, figuring out what to write in those four sections. That’s the real task. Moreover, you can’t figure out what you’re going to write in one until you have some sense of what you’ll write in the others! So, this sequential approach to writing is ill-advised. The real next action is probably something like “Identify key contributions of paper.” Once you know what those will be, you can go from there.↩︎
Intuition is really just confident, logical thinking.
i saw someone say that note titles should be like API names (from @davestridsr on the Obsidian Discord)
An app adds an API when its developers want other developers to be able to extend and work with the app’s functions, e.g., to develop other features or to let services interact with one another.
Some “good” features of an API in software development might be that the API is: (1) deep (you can get at as many functions of the underlying app as are useful), (2) expressive (you can fine-tune interactions between your extension and the app), and (3) intuitive (by looking at an API function’s title and parameters, it’s pretty easy to guess what it allows you to do).
Andy’s saying that a good note title fits those parameters too. The metaphor goes: you “extend” an atomic evergreen note by invoking its title in a new note. By doing so (and if done right), you can grasp the details of that note easily while, at the same time, you can reinterpret it in its new context.
Welcome to Axle.
I probably don’t need two blogs, but I have found myself hesitating to publish a variety of ideas on Fulcra because I wasn’t sure that those who read that blog for the systems/design thinking or social change focus would care about my thoughts on productivity, practice, and personal development.
So that’s what this place is for.
While my writing on Fulcra will (continue to) explore how the world changes, Axle is about how we change. In particular, I’m interested in “augmenting cognition”: how information systems and systemic design can help us think, do, and be better. I’ll also be writing about the different techniques and tools I use in my own work, as well as publishing resources that you might find useful.
What’s in the name? Well, while Fulcra emphasizes the search for leverage points in complex systems change, Axle is centred on the core of that change. That’s us—the people driving it. We try our best to amplify the forces of the world in order to shift something that matters to us. We roll with our changing worlds—and we are also in constant motion (and transformation) ourselves.
Welcome!