My Most Productive Work Ethic
Work to prevent future work first, get things done later
Most people seem to think of productivity as task efficiency. Popular methods like the Ivy Lee method aim to prioritize task lists and help decide which tasks should be done or delegated, while others aim to increase the efficiency of completing a single task or given task list.
These methods work great for short-term, straightforward goals, yet everyone seems to miss the elephant in the room for bigger projects or goals.
I found that considerable unnecessary work load is actually self-generated by lack of critical evaluation on the creation of tasks. This may sound obvious, but preventing tasks altogether results in greater productivity gain than any task completion recipe can ever provide.
My main notion is that few people seem to evaluate or question the contents of tasks in relation to the end goal and instead just attempt to get their things done asap, thereby missing opportunities to prevent future work. This is why I felt like sharing my preferred workflow of reaching goals.
Tasks are not goals
To understand what I mean by preventing work, it is useful to make a clear distinction between tasks and goals.
A goal is something set a-priori, and originates from some need or desire. For example: “Having a treehouse” can be a goal (one could argue there’s some higher philosophical goal but I’m not going into that for now).
The first thing to realize is that there’s a million ways to realize a treehouse. My first task (A) may be to decide on buying a catalog treehouse or to build one from scratch myself. It’s easy to see that my future tasks (B and C) are going to be substantially different, depending on what I choose.
Note that it is crucial to fully comprehend the goal. If, for example, the goal is “Building a treehouse”, it’s less likely that the catalog treehouse will fulfil my desire. That having said, finding the true need or desire is often the most difficult part.
“You are not a todo list” — Robert Poynton
The reason that I want to make this distinction clear, is that we humans tend to lose sight of (long-term) goals especially under pressure, thereby confusing tasks for being goals at some point.
It is also important to remember that you are not a todo list. Tasks are always subservient to goals, not the other way around.
The other path
I particularly love (and work on) product & technology development, but this workflow is applicable to reaching virtually any goal.
While the usual constraints of time and costs apply pressure on getting things done, I continually spend a significant portion of my time not actually getting things done. Instead, I evaluate my tasks and work to find better ways such that my future tasks are easier or obsolete.
This feels counter-productive at the time of doing it, because there are no guarantees of finding a better way. Off course, there is a point of just getting things done, but this should be much later than you’re initially comfortable with, especially under pressure.
“Most time and money can be saved not by getting things done fast, but by pausing often to critically evaluate if there is a better way to reach the goal.”
Sometimes I hear people say something along the lines of “let’s just get this done, so we can move on”. If you ask me, this is mostly just pressure-induced tunnel vision. Ironically, most time and money can be saved not by getting things done fast, but by pausing often to critically evaluate if there is a better way to reach the goal.
A personal example where I did not apply this yet: In the early days of our start-up (an automated video highlights & analytics tool for amateur sports), my time was spent creating the product sort of on-the-fly and maintaining it for one pilot customer. With significant pressure from investors to rollout to next customers, my time was scarce and often I had to choose between quick fixes or scalable solutions.
While the goal had always been to have a scalable solution, I lost sight of this due to external pressure. New customers and maintenance tasks were deemed more urgent, and given priority over working on scalability. I recall it didn’t feel right at the time, but we went for it anyway to “keep up the pace”.
Before I knew it, countless hours that could have been spent improving the product, were lost to the inefficiency of new rollouts and maintenance. The rippling effect on cost and progress were huge, almost halting the pace we intended to maintain.
The point is what I had learned from this experience. Because although we made it out alright in the end, I since base my path much more on what tasks lie ahead, not allowing pressure to turn tasks into goals.
Sunk cost and time
Sadly, I cannot oversee everything nor can I predict the future. As a result, I sometimes overlook or underestimate what turn out to be massive tasks. Somewhat unfortunate, but that’s just part of life.
When this happens, I have to decide between grinding through that massive task or finding a better way. Since the better way typically involves doing rework, this decision can be difficult when there is large sunk cost involved.
Although sunk cost should be irrelevant to future plans, there’s a caveat to such rework: problems appear easier from afar than up close. In the case of the illustration, you must be confident that the effort of tasks (D+E) is less than task (C). It is therefore useful to regularly include both historic and future tasks during evaluation.
In my experience, if rework allows for significant simplification of your product, process or reaching your goal, it’s worth it. However, if it only promises a different path, you will probably overlook something and it’s not worth it. An ethos or aim that I personally use here, is: less, but better.
A recent personal example where I did apply this: We were trying to get a robot arm design manufacturable for volume production. For those unfamiliar with hardware design: not everything that is designed using CAD software, is manufacturable in reality.
There was one part of the design that consisted of seven separate parts, some of which needed to be match-drilled while the whole thing had to be glued and bolted together within incredibly tight tolerances.
Rather than immediately diving into solving the problem, I evaluated what it would take to solve this in terms of future tasks. As you might imagine, this would have been quite complicated, requiring a multitude of custom machines and assembly steps, not to mention the compound chance of something going wrong.
I realized the best option was to push back on the design team, and spent my time with the team to find a better design. We ended up redesigning the seven parts into one single part. The redesign cost about two weeks, but prevented months of future work, while significantly reducing overall manufacturing cost and risk.
Together with a number of fundamental principles, this approach works really well for me, and I aspire that this article will at least make you think.
I would like to end this article with a less abstract, more practical takeaway. Therefore, below here I’ve written some questions I ask myself when evaluating my task lists:
- What can I do today to have less things to worry about in the future?
- What can I do to make my future work simpler, easier and/or faster?
- Is there a way to prevent doing the next task(s) while still reaching the goal?
- Which past decision should I reconsider to make work all future work easier?
- Will future-me be damning or thanking today-me for this decision or path?