Outcome over Process

For the past few weeks, I’ve been think­ing about I can be more pro­duc­tive. In par­tic­u­lar, I’ve been think­ing about how I can elim­i­nate waste to give my­self time to work on things that mat­ter.

These ef­forts have been par­tially suc­cess­ful. I’ve found ways to speed up code re­view with an agent and im­prove the turn­around time on com­mu­ni­ca­tion. I’ve been spend­ing less time wait­ing and more time work­ing. But in the end, I don’t feel that these per­for­ma­tive ac­tions have re­sulted in any real pro­duc­tiv­ity gains. I re­al­ize now, that this was be­cause I was fo­cus­ing on the wrong thing.

I was fo­cus­ing on the process of get­ting stuff done, in­stead of fo­cus­ing on how to ac­tu­ally get that same stuff done.

As an aside: I found Mitchell Hashimoto’s re­lated blog post ex­tremely stim­u­lat­ing. I rec­om­mend it to any­one try­ing to ap­ply these agents to their real-world work.

For the past few weeks, be­tween read­ing Butterick’s Practical Typography and get­ting Harper 2.0 out the door, I’ve been read­ing The Effective Executive by Peter Drucker — at Matt’s rec­om­men­da­tion.

It’s a fan­tas­tic book. It is well writ­ten, gives thor­ough rea­son­ing, and pro­vides case stud­ies for each of its ma­jor points. I haven’t quite fin­ished it, but there are some great ideas from the first bit. Im­por­tantly, it has be­gin to re­ori­ent my think­ing to­wards out­comes over process.

What Is “The Process”?

The “process” in­cludes all the minu­tia re­quired to de­liver on the mean­ing­ful pur­pose of your job. For an ac­coun­tant, that might in­volve tab­u­lat­ing data for the pur­pose of in­creas­ing ef­fi­ciency in the busi­ness. For me, as the main­tainer of Harper, my pur­pose is to help peo­ple com­mu­ni­cate bet­ter us­ing the writ­ten word.

My sec­ondary pur­pose is to prove that the open source method­ol­ogy is su­pe­rior to the com­pe­ti­tion in ac­com­plish­ing my pri­mary ob­jec­tive.

For me, the process in­volves:

• Producing code.
• Reviewing code.
• Determining in which di­rec­tion the pro­ject needs to move.

The “process” will look dif­fer­ent for you. It is com­posed of the in­di­vid­ual steps needed to de­liver the fi­nal out­come.

Think About Where You’re Going and Nothing Else

An oc­ca­sional check-in on what the process it­self looks like can be ben­e­fi­cial, but it should not be the fo­cus of my at­ten­tion. My at­ten­tion should be on how to get things done and more im­por­tantly how to get my work in the hands of my users as fast as pos­si­ble.

I’ve caught my­self think­ing about the process more than the out­come too many times. There are di­min­ish­ing re­turns to that kind of prac­tice, and they are ap­proached fast.

Yes. I re­al­ize that this post is an ex­am­ple of the kind of think­ing that I am crit­i­ciz­ing. This will be the last one of its kind for some time.

According to Drucker, some­thing strange hap­pens in the brain when it fo­cuses on out­comes rather than processes. In­stead of think­ing about how to make some­thing “faster”, it fo­cuses on how to find short­cuts or brand-new ap­proaches. In other words — when ap­plied to out­comes — the brain be­comes more flex­i­ble and there­fore more ef­fec­tive.

I’ve seen this my­self, but I’ve never been able to iden­tify it so suc­cinctly. It’s why I strive to do at least one hard thing each day.

I’m look­ing for­ward to wrap­ping up Drucker’s book and hope­fully ex­tract­ing more of his wis­dom. In the mean­time, I’m cu­ri­ous: have there been any in­stances where you felt you fo­cused too much on the process or tool­ing and too lit­tle on the ac­tual out­come?