Outcome over Process

For the past few weeks, I've been thinking about I can be more productive. In particular, I've been thinking about how I can eliminate waste to give myself time to work on things that matter.

These efforts have been partially successful. I've found ways to speed up code review with an agent and improve the turnaround time on communication. I've been spending less time waiting and more time working. But in the end, I don't feel that these performative actions have resulted in any real productivity gains. I realize now, that this was because I was focusing on the wrong thing.

I was focusing on the process of getting stuff done, instead of focusing on how to actually get that same stuff done.

As an aside: I found Mitchell Hashimoto's related blog post extremely stimulating. I recommend it to anyone trying to apply these agents to their real-world work.

For the past few weeks, between reading Butterick's Practical Typography and getting Harper 2.0 out the door, I've been reading The Effective Executive by Peter Drucker — at Matt's recommendation.

It's a fantastic book. It is well written, gives thorough reasoning, and provides case studies for each of its major points. I haven't quite finished it, but there are some great ideas from the first bit. Importantly, it has begin to reorient my thinking towards outcomes over process.

What Is "The Process"?

The "process" includes all the minutia required to deliver on the meaningful purpose of your job. For an accountant, that might involve tabulating data for the purpose of increasing efficiency in the business. For me, as the maintainer of Harper, my purpose is to help people communicate better using the written word.

My secondary purpose is to prove that the open source methodology is superior to the competition in accomplishing my primary objective.

For me, the process involves:

• Producing code.
• Reviewing code.
• Determining in which direction the project needs to move.

The "process" will look different for you. It is composed of the individual steps needed to deliver the final outcome.

Think About Where You're Going and Nothing Else

An occasional check-in on what the process itself looks like can be beneficial, but it should not be the focus of my attention. My attention should be on how to get things done and more importantly how to get my work in the hands of my users as fast as possible.

I've caught myself thinking about the process more than the outcome too many times. There are diminishing returns to that kind of practice, and they are approached fast.

Yes. I realize that this post is an example of the kind of thinking that I am criticizing. This will be the last one of its kind for some time.

According to Drucker, something strange happens in the brain when it focuses on outcomes rather than processes. Instead of thinking about how to make something "faster", it focuses on how to find shortcuts or brand-new approaches. In other words — when applied to outcomes — the brain becomes more flexible and therefore more effective.

I've seen this myself, but I've never been able to identify it so succinctly. It's why I strive to do at least one hard thing each day.

I'm looking forward to wrapping up Drucker's book and hopefully extracting more of his wisdom. In the meantime, I'm curious: have there been any instances where you felt you focused too much on the process or tooling and too little on the actual outcome?