October 20, 2009
I'm a little behind on my posting. I meant for this to go up yesterday, but I didn't write it until now, so I have no one to blame but myself.
A few days ago, Tom Limoncelli posted an interesting tidbit of information. Train schedules in New York City are deliberately misleading, but only a little bit. The idea is that if the train always leaves one minute late, the number of people who can catch the train goes up, and so does their satisfaction level of "just catching" the train. This is a form of social engineering that really has its benefits. There's little to no downside, and the upside is an increased happiness in the affected parties. Definitely a net win.
In his blog entry, Tom likens this to the customer server / engineering axiom that you should under-promise but over-deliver. Leave on time like you say you will, and people who are marginally late miss the train. Delay for a minute, and you get a lot more thankful people.
Bob Plankers, of the Lone Sysadmin, wrote an entry in response which also has a solid foundation in real life. Essentially, Bob says that we need to stop acting like Scotty, who (in)famously padded his time estimates so as to appear a hero to the crew. In the real world, Bob says, people catch on and start to anticipate falsely padded estimates. It's pretty easy to follow this to its logical conclusion, where some day it really does take you that long to build the quoted system, or reverse the polarity on the transwarp inducer. And when that happens,
Captain Kirk your customer is going to be very unhappy.
Fortunately, I think it's possible to reconcile the under-promise / over-deliver stance which makes people happy against realistic estimates we give the people who rely on us. I think the secret lies in the last sentence of the New York Times article that Tom referenced in his post.
Missing the train would have meant a half-hour wait for Mr. Riddle, who deemed the secret minute policy “pretty cool.”
“But I’d still try to get there on time,” he added. “You never know"
As Bob mentioned, "People aren’t dumb". This is very true. They catch on, but fortunately, I think they're also grateful of what they consider extra effort to help them out.
I'm as guilty as anyone of using "Scotty Time", where I inflate my time estimates, but as I mentioned in my comment on Bob's blog, I do it not out of the desire to be a miracle worker, but more out of an uncertainty of the time the particular task will require. I do so many one-offs and the like that I typically only have a vague idea of the time it will take. And of course, any crises occurring through the course of the work only increases the time to completion.
So how do we decide between accuracy and comfort? Each of us has to decide on a case by case basis, but fortunately it's not an either/or kind of choice. I make my decisions based on how well I know the task at hand. Newer, unfamiliar tasks get more time. You know your infrastructure better than I do. If there's a frequent cause of tardiness in projects, attempt to determine how much that will affect your task at hand.
In Tom's book, Time Management for System Administrators, he advocates spending less time on tasks that the users believe take little effort. This includes things like password resets, permission changes, and things of that nature. This is good, as long as the users expectations are realistic. Unfortunately, while Bob's right that people aren't idiots, they also aren't familiar with the sausage factory, so to speak. They aren't familiar with what we accomplish behind the scenes to make things run as smoothly as they (hopefully) do, but it involves a lot of work, and some things that should be simple just aren't. The users have no way of knowing which tasks appear-simple-because-they-are and which tasks appear-simple-yet-are-complex except our ability to communicate the anticipated time to finish their request.
This is the primary reason that we have to be honest, or at least consistent, in our time allocation. Maybe we need something like this, but with denominations in time instead of money?
The point is that we need to be consistent in our estimates, weighing each task against its importance both to us and to the person requesting it. The trains run a minute late, but it's as much across the board as possible, and it's done for the benefit of the passengers, not the conductors. Put your users first, and they'll show as much gratitude as the running commuters who "just caught it".