The problem with productivity advice is that it tends to assume that all tasks are created equally, and require the same approach. Topics like focus, discipline and Getting Things Done (GTD) best practices are considered to be universal; and while there are certainly some generalisable elements to these topics, it's much less than people discuss, in my experience.
Earlier today I read this essay by Andy Matuschak, which talks about how the approach he must take to research being incredibly different to the approach he had to take while working in industry.
In it, Matuschak writes:
Bill Thurston writes:
Mathematics is a process of staring hard enough with enough perseverance at the fog of muddle and confusion to eventually break through to improved clarity.
This description resonates more with my experience of design research than anything Getting Things Done has to say, valuable though it was in my past life.
Another point he makes in the same post is the idea that problem-solving is inherently more satisfying (and more likely to lead to progress) than viewing something as a task to be completed.
Another pattern has to do with my stance towards the work. I’m much more likely to flinch away from difficulty when I view my research problem as a task, as something to be accomplished. I’m much less likely to flinch away when I’m feeling intensely curious, when I truly want to understand something, when it’s a landscape to explore rather than a destination to reach. Happily, curiosity can be cultivated. And curiosity is much more likely than task-orientation to lead me to interesting ideas.
He also makes a point of the pace of work and the pace of life, and how your expectations for this can be very easily adapted based on how you're spending your time.
It’s possible to get a feel for this effect on very short time scales. If I find myself sucked into an hour-long Twitter binge, I’ll become noticeably more habituated to ultra-fast reward cycles. For hours afterwards, everything else will feel much slower, way less stimulating. I’ll suddenly need real willpower to read a book for a solid hour. The acute effect wears off after a few hours, but some fraction of it persists into the next day.
For me personally, I've also found that problem-solving requires a very different approach to admin-like tasks, such as replying to emails or managing invoicing. Some examples of things that have worked for me when being creative or solving problems:
- Blocking off time each day for creative/problem-solving work - this is typically work where it's easy to state the problem I'm looking to solve or the outcome, but it's harder to state exactly how I'm going to achieve it ahead of time. Instead, the process is more reactive
- Writing notes while working - I find the process of writing a log of what I'm working on to be helpful. For example, if I'm coding and working on implementing a specific feature, I find it helpful to write out a high-level overview of what I'm working towards, and then the steps I've already taken as I work. This might include any important links that might be useful to refer back to in the context of the task.
- Reducing the size of the problem - most problems consist of a lot of sub-problems to be solved. Taking the time to break a problem down ahead of time can save a lot of frustration when overwhelmed by the scale of a problem, which makes it harder to keep everything relevant to it in context at the same time.
- Understanding the problem better - related to the above, it's almost always a better idea to understand the problem better than you think you'll need to, to begin with. What matters most, and what are you optimising for? It's surprising how differently two people can interpret the same problem when stated at a high-level.
This is not to say that project management techniques can't be applied to engineering/creative problems, but it adds an overhead; one that becomes increasingly necessary as you add more people to a team, but often only adds friction when working independently, as I currently am.