The "3 Times" Rule

I like breaking new ground. Making new things is exciting and engaging, sometimes it's challenging, but it's generally rewarding and fun.

What I don't like is doing the same thing more than once, particularly when it's because somebody couldn't be bothered articulating what they wanted properly. Usually taking a zero-assumption approach and asking a couple of carefully worded questions will avoid this.

But sometimes it's a long and involved task that just keeps landing on your desk. That's the reason I developed the "3 Times" rule (actually I might have stolen it from my brother-in-law).

• The First time you have to do the task, it's an adhoc task.


• The Second time you have to do the task, it's still adhoc, it's just an anomaly.


• The Third time you have to do the task, it's likely you'll have to do it again, so build a tool, or automate all the parts that you can.

Let me clarify that I'm not talking about doing something three times because somebody made a mistake. I'm talking about running the same process on three different sets of data on three separate occasions.

This approach seems to work especially well with reports. Often it only takes a little more effort to throw the results into a webpage that the user can access on their own. The great thing about this approach is that the user feels empowered, and the task doesn't land on your desk again.