I spent a long time optimizing my productivity.

Task management systems, pomodoro timers, software—I tried it all.

Some of it helped. Most of it didn’t.

The reality is that our personal productivity is a muscle that is built over time. It’s also depends on a lot of other factors.

Our environment. Feeling pressure from others. Our energy levels. The amount of undivided, undisturbed time we have available.

I’ve come to accept this. And I look at productivity differently now.

In the modern world, solving your own productivity issues is a good start, but it won’t change your output by 10x, or 100x.

The only way to do that is to build a system. 

Systems are available to all of us. 

Programmers build systems. But writers do too when they publish on the internet. So does someone who publishes a video on YouTube. Or uses no-code tools to automate a process. Or records a podcast.

These things allow us to do something once and reach thousands of people.

There are all kinds of options for multiplying our output.

Focusing on developing our skills to better take advantage of these systems is the only real way to multiply our output. 

As humans, we are only capable of so much. There are only so many hours in the day, and we only have so much energy.

But if we build systems, we can produce at levels that would have been unthinkable just decades ago.

Systems are the only true way to multiply our productivity.

Nassim Taleb has shaped my thinking more than any other author.

Love him or hate him—his arrogance rubs many people the wrong way—his books have changed the way many people see the world.

One of the things he showed me is how poor we are at predictions.

We like to think we can predict things because it helps us understand the world, and make it seem less scary. 

It’s not a pleasant thought to think that much of the world might be random, and that our lives are unpredictable.

And so it's natural to believe experts when they predict an outcome. The weather for next week, or the stock market outlook, or climate change.

But the numbers don’t bear it out. Most predictions would be better  determined by a coin flip.

The reason we continue to believe our predictions is the story we construct afterwards. 

“If this had been slightly different, then the prediction would have been correct…” 

Those stories sound good, except they aren’t true. Keep a diary, and you’ll realize how much we infer afterwards that we didn’t know at the time. 

Our tendency to construct a story explaining things after the fact is called the narrative fallacy.

If we can't predict things, why do we plan? 

Some people argue that it’s better to have a poor plan than none at all. 

But the problem with plans is that we tend to believe them. We’re wired for it. 

We don’t deal well with probabilities and confidence levels, and so it’s difficult to convey that a plan only has 50% certainty. Or that we  don’t know what the certainty is. 

The reason it’s important to acknowledge that we can’t predict things is we can change how we act.

Instead of building a plan that will soon be irrelevant, we can accept the unpredictability and plan accordingly. 

This changes how we allocate resources, whether it's our personal time and money, or resources like team members and budget. 

It changes the frequency with which we update our plans, and revisit our initial assumptions.

And it moves us slightly closer to reality, even if that reality acknowledges that we don’t know.

We may not be able to change how good we are at predictions.

But we can change how confident we are, and make better decisions as a result.

I love working Saturdays.

Of course, I don’t love giving up the usual weekend activities: seeing friends, going to the market, getting outside.

But when I work on a Saturday, I know one thing: there won’t be any distractions.

Distractions matter because they derail my focus. Even the chance of a distraction is an opportunity for disruption, which is why a weekday without distractions isn’t the same.

"Flow" gets talked about a lot, though not many people know detailed definitions.

Flow by Mihaly Csikszentmihalyi is one of the most comprehensive books on the subject.

“The best moments usually occur when a person’s body or mind is stretched to its limits in a voluntary effort to accomplish something difficult and worthwhile.”

That makes sense. But what really defines flow is how you feel:

“…one acts with a deep but effortless involvement that removes from awareness the worries and frustrations of everyday life” and “…the sense of the duration of time is altered; hours pass by in minutes, and minutes can stretch out to seem like hours.”

We’ve all experienced a flow state at some point. 

For me, it often occurs while playing sports. Hockey, soccer, tennis—these sports need enough dedicated concentration that time slips by. You don’t think when you’re playing these sports, you just react. 

But it can also occur during work. Editing video, or photos, for example. 

Knowledge work can sometimes, given the right opportunity or problem. 

Digging deep into some research and writing, or building something—these typically trigger it for me. And of course it depends on your mood, concentration level, how rested you are, and many other factors. 

But flow states themselves generate happiness. They generate a deep sense of satisfaction in the work itself. It’s hard to finish a day where you spent time in a flow state with dissatisfaction.

Which is why it’s too bad that the modern workplace is so poorly constructed for flow states. 

And why I love to work on Saturdays.

I value one thing above all else in my work: learning.

Learning isn’t only about absorbing new knowledge. 

It is putting into practice that knowledge, and deliberate practice of new skills. 

Spending all your time reading and gaining new knowledge isn’t learning. It’s procrastination. 

In fact, the fastest way to learn is to start, and then learn things as needed. 

The only downside to this approach is you may not know all the options, so it’s sometimes useful to skim through an overview of things first. Then you’ll know when it’s time to go back to the learning material.

Balancing execution with learning can be difficult. 

Too much learning, and you’ll make no progress. 

Too much execution, and you’ll move forward much slower than if you’d stopped to think about what you’re working on. 

Execution in the wrong direction is bad. Grinding out work when a you could build a system isn’t efficient.

The fastest learning occurs when you have time and space to focus on one project. 

Enough empty blocks of time to concentrate, and enough freedom to switch back and forth between knowledge acquisition and application. 

A project is a great way to learn. You have a concrete end goal and a method of application. 

Projects fit well with the variety I like in my work too. I get bored doing the same thing over and over again.

New projects provide an opportunity for learning, but also for a change.

Whether it’s a new project, a new team, a new focus, or a new experiment, learning is always my top priority. 

It’s often why I choose to change jobs, or how I choose between them.

Learning above all else.

Learning is always my top priority when it comes to work.

Learning fast requires the time and flexibility to follow areas that are interesting. 

Take a couple steps forward, and then one back. Time for mistakes and self-correction.

In short, it requires autonomy—my second highest priority behind learning.

Autonomy does not mean no supervision. It doesn’t mean no manager or criticism or feedback. 

Feedback and criticism are key components of my first goal: learning.

Good managers and peers provide feedback and ask questions that help with learning. They’re crucial in making work enjoyable too.

Autonomy instead means the freedom to explore different areas. The freedom and encouragement to make mistakes and improve.

It means less micro-management, and more support. 

A key part of what I like to do—solve problems—involves choosing which problems to tackle first.

In tech and startups, where I like to work, there are too many problems to tackle at once. So choosing the right ones is critical. 

And to choose the right problems requires some autonomy too. 

It means periods of exploration for problem definition, data investigation, and proof-of-concepts. 

But not all will lead somewhere. That’s part of the process. And it requires autonomy to execute well.

Learning first. Autonomy second.

Two key components of the work I like most.