Order of Operations
Each year, I try to set some kind of a theme for the work I’m doing.
I don’t mean the BAU (Business As Usual) stuff, like day to day activities that pay my bills or feed my family. I’m talking about everything else you do when you want to improve your lot in life. I’m a weirdo, so I like to have a theme surrounding that particular year (and that particular set of goals and true norths for the year).
One year was all about picking my battles. I found myself constantly overfilling my weekly project plate, so I wanted to modify my style and bite off only what I could chew for a while. In a short phrase, it was to do fewer things, but with greater consequence.
Previous themes have included aiming better before firing, taking care to add more positive value without adding negative—like a doctor’s do no harm, and this year’s reminder to protect my time. After all, we only get a certain amount of time in a given day; all other resources can be expanded and grown and created from scratch if need be.
Inside of the current overarching goal to protect my available time (and bandwidth), I’ve noticed that certain tasks have outsized benefits for other agenda items. Those tasks should generally be done first whenever possible. I mean, duh! Of course you want to set the first domino up… well, first.
Setting up dominos to fall isn’t a terrible analogy, but it’s also like I have to build the other dominos in real time once the first one starts falling. Even still, without that first one dropping, it’s going to be really tough to get the others going.
So, that’s the first thing: the order of operations really matters. I spend almost as much time considering this order as I do executing tasks, and that can bother some folks. Remember, though: it’s ready, then aim, and finally, fire. We should probably all spend more time on the aiming and readying phases, and waste fewer bullets.
Other people think it’s time to act right now, and I often think it’s time to think some more.
Second, I really hate doing the same work over and over again, especially if it doesn’t serve a purpose toward my vision. This goes back to the fish f*cker who lives inside me, where passion departs and I’m left feeling like I really, really don’t care about whatever this thing is in front of me. “This thing” was the coolest thing I could imagine last year, but it is now time for me to move on. Done with fish.
I get a thrill out of taking something as far as I can, fueled by that initial passion. As far as I can tell, there is only one source for that sort of premium rocket fuel that makes you do crazy things, and it is that initial burst of enthusiasm that comes with the idea that you might be able to master something.
This has led me to some interesting strategies to reclaim my time over the years. If I’m still using the analogy of dominos, that means being careful enough in the set up phase so that I only have to push one domino over in real time, and the rest sort of take care of themselves.
You can’t mind everything all at once, but you can certainly save yourself a great deal of work if you can set it and forget it. Maybe you can build something now that will help you with another project—if the tools of the trade haven’t been built yet, you’re the builder. This really applies to anything software related; one problem often provides a solution to many problems.
Even in the physical world of building and managing things, you have to build a foundation to a house before you can build the walls or roof. There’s almost always an order that makes the most sense, that reduces the total amount of work to be done with careful planning.
The order of operations isn’t the only thing to consider when trying to do more things with less overall effort, but it’s a big one.