My preferred philosophy of operation1 for getting stuff done has three requirements and two assumptions.

First of all let me share what I visualise when I’m trying to get a project going, design something or generally do some work. I start by imagining there’s is some perfect solution that exists. Then comes the crisis of confidence because I have no idea what that solution is and I’m terrible at my job but let’s quickly skip over that.

Next, because our opening position is likely so far from this perfect solution2 that, despite not knowing exactly where the solution is, we can start going in the right direction with a little intuition. There will be low hanging fruit, prior art or a prototype to try out.

Then you accelerate with this solution, working quickly. However the speed of progress carries momentum. You’ll only notice you’re over-fitting, over-engineering, complicating the solution, once you passed perfect in the rear view mirror and things start breaking a bit.

image

But that’s fine. You sense things are getting worse, not better. Further from the goal than closer, and you turn. A new decision. Experiment two based on the learning from the first. Now with that new heading the foot goes back on the gas and you speed away.

Again you overshoot, but less and you can correct earlier. You have a feel for the problem space, you now know the customers. You hone in3 and correct again. Growing closer to perfect until the effort isn’t worth the delta and you call it done. You’ve discovered and hit a near-perfect solution and you did it at pace.

Three requirements

  1. Make decisions quickly. You need a rough, directionally correct, step towards something better. You shouldn’t sweat making the perfect designs, just start heading in the right direction as soon as possible, don’t burn too much time.
  2. You need to accelerate. Get your experiments to fail quickly, learn where perfect is quicker by seeing it go whooshing past as you overshoot. Timidly tiptoeing around waiting for a eureka moment doesn’t get things done.
  3. Course correct often. You need to be paying attention to feedback to know when you should repeat the loop and make your next decision quickly. Keep humble, take input, throw away the first pancake and get on with the next experiment.

Two assumptions

Assume that future you (or your future team) has both agency and competence. Back yourself to handle the future problems of going fast. Don’t make it foolproof4, yet. It’s unlikely the overshooting will land you further from the goal than where you started and you will learn things along the way. Worry too much about getting it right the first time and you don’t leave time to experiment.

The second assumption is that the work can absorb errors. If your domain of choice is say drug-discovery, then trying a bunch of stuff out at pace and dealing with the resulting casualties maybe isn’t the best approach.

But the main thing is the pretty graph, because that’s the thing which lives in my head rent free.

Notes

  1. A modus operandi in so much as it is more a habit or bias than conscience choice. However, that latin makes me sound like a serial killer so in the footnotes it goes. ↩

  2. Often a blank page, where writing any old rubbish is still a step in the right direction and builds momentum. ↩

  3. This whole thing is well trodden ground in control systems. It’s called damped oscillation. You can play with some neat graphs with interactive sliders here. ↩

  4. I’ve found the best way to save money, time and sanity on making a bunch of stuff foolproof is to not work with fools. ↩