Pro: My Car Broke Down and I Was Actually Happy about It

I guess I need to explain that a little more. I wasn't really happy that it broke down. I was on the way to Maine to teach the tai chi group in Farmington, so that sucked. And it was the clutch the completely died, so I knew it was going to be a few dollars to repair. But that was actually part of the silver lining. See, a couple of years ago, I read about Ramit Sethi's strategy for hedging fuel costs. The theory goes, if you are paying for something that goes up and down over the course of a year, you should find a way to even out the costs. This makes sense from a paycheck point of view, right? You take home the same amount of money each week, so you'll be in more predictable shape if your expenses work the same way. I adapted that strategy to create a car savings account. Looking back we realized we spent roughly the same amount of money on car-related expenses year to year, but they almost always came in spikes when something went wrong. To smooth out the spikes, I took a monthly average of those annual expenses and started putting it away automatically into a savings account each month. Now, when something breaks down, the money is already sitting there and I don't have to sweat a disruptive spike in our monthly expenses.

The dog has his own account too, for "random" vet visits that actually happen on a pretty predictable basis. And I guess that's the bigger lesson here. Looking back year over year, you start to see some clear patterns for stuff like this, even though the clutch dying or the dog eating something awful seems like a random occurrence. So, if you automate savings around these "random predictable" expenses, you save yourself a huge headache.

Con: I Want Automation Now

I get the "automation itch" whenever I'm starting a new project. The "automation itch" is the desire to put a system in place, which is ultimately a good thing, but it usually strikes prematurely. Getting the itch can be a major trap and I've slowly learned to recognize that it usually takes more time to set up an automated system early in a project than it takes to execute something manually. The best advice I've ever gotten here is "do it manually until you don't have enough hours in the day."

We went through this at Brookline Tai Chi with an online registration system for classes. In summer 2009, we added online registration and probably 1/3 of current students adopted it right away. What was striking was that close to 80% of new students took to the system. Those statistics are interesting, but probably more appropriate for a post about changing systems in a business....another time.

Flash forward to last week. This session, we got back to back cases of students who couldn't register online because of their unique situations. That means we need to rebuild the system to fit their situation, right?

Wrong. That was two cases out of how many? Let's say 200. 1% of registrations. Do you think we have time to do 1% by hand? Especially if you consider that doing 1% of registrations this way takes 10 minutes of admin time, compared to several hours of developer time to make the change, it's a no-brainer. Of course, there's one other important factor: systems changes always have to put the user experience front and center. It's never a good idea to argue to your customer that they should interact with your business a certain way because it's easier for some back-end reason. In this case though, to the students involved it looked like we were making a special exception for them, which they appreciated. So it worked out all around.

I think a year ago I would have panicked a little more about these two cases. Or I would have thought about how to tinker with the system first. This time though, my first thought was "2 out of how many?" and my second thought was how to create the best manual solution. Beware the automation itch!