Many years ago, I read a book that (no exaggeration!) altered the course of my life: David Allen’s Getting Things Done.1 GTD changed how I approached my work and commitments: it made me more reliable and confident — two attributes that create a virtuous cycle. Paradoxically, my workflows became more structured and fluid. Rather, they became more fluid because they had structure. Constraints can set you free.
I’d tried other approaches to personal productivity before, but GTD clarified an important distinction: that between doing the work and doing what I call meta-work. Understanding this distinction — and learning to switch between the two modalities — boosted my effectiveness.
Doing the work is about producing something of value, especially to others. For example, you might be designing a navigation system for a digital platform. This might include interviewing stakeholders, capturing insights in a Google Doc, drawing a conceptual model, etc. It might also include meeting with the team to discuss all that stuff. At the end of the process, you’ve produced artifacts that create value for the organization. (E.g., engineers can go off build the thing.)
Doing meta-work is everything else you must do to make that work possible. This can include thinking about what must be done next, in what sequence, what materials or resources you’ll need, who you need to talk with, figuring out when they’re available, scheduling calls, etc.
Some aspects of meta-work are essentially project management. But it’s more than that. (For me, it includes honing my state of being; i.e., taking care of the Instrument.) I call it meta-work because it’s working on the work — and it applies to more than what we think of as “projects.” (Although GTD also helped clarify the distinction between projects and non-projects.) I don’t get paid to do meta-work, but the stuff I get paid for won’t happen without it.
Throughout my career, I’ve always made time for doing work — i.e., delivering “the goods.” It’s what I thought work was. So, I concentrated on mastering the tools (e.g., design applications) and conceptual models (e.g., information architecture) of my trade. Over time, I built processes and habits to help bring some predictability to the proceedings, but it was all somewhat ad-hoc, and I often had to put out fires.
After reading GTD, I realized I’d never set aside enough time for meta-work, nor had I consciously developed practices and tools to manage what I was doing. Meta-work was work — or rather, work wouldn’t happen effectively if I didn’t work on the work. Although it seems blindingly obvious in retrospect, at the time, it was a revelation for me.
GTD doesn’t require complicated tools. The essential components — inboxes, lists, and folders — can be digital, but they don’t have to be. You can practice GTD with a pen, paper, and filing cabinet, or with MS Outlook, or with software specifically designed for GTD. (Such as OmniFocus, which I use.) The approach is prescriptive at the conceptual level but open-ended when it comes to implementation.
But ultimately, the tools and even the methodology itself aren’t that important. It’s been a long time since I last practiced GTD precisely as described in the book. I eventually realized that some aspects of the approach worked better for me than others, so I adapted it to my needs.2
The critical insight here is that if you want to do great work — to make things that have real, lasting value for others (and yourself) — it’s not enough for you to master work. You must also master meta-work. They are different modalities that require different mindsets, practices, and tools. It behooves you to build meta-work competencies.