Scotty Time: A guilty indulgence?

Date 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?
Prices of Answers

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".

10 Responses to “Scotty Time: A guilty indulgence?”

  1. Pamela Howell said:

    I would absolutely *love* to see some decent time-estimates for the basic sysadmin tasks, per platform. We'd have measurability! I mean, I'm sure we do...but it'd be great to have these estimates put together for a baseline reference point somewhere. Do these measures exist? I think they should.
    ---p

  2. chewyfruitloop said:

    i actually bought time management for sysadmins. every time i sit down to read it i either fall asleep or get pounced on by the kids.
    when i bought Secure Coding: Principles and Practices, it took 2 weeks in sri lanka for me to get through it.

  3. John M said:

    I would NOT like to see time estimates for tasks.

    1. Accountability. Who would create these estimates? How many times have we started a task, only to find that we need to insert steps/ perform a prerequisite task to complete the original task?

    2. Supervisors/Managers would use the task estimates for performance standards, and attempt to reduce the estimates in house to make themselves/their departments/section/area look better. Employee reviews would soon incorporate these estimates, and eventually our jobs will be reviewed as to how many tasks were completed, as versus how many tasks were performed well.

    I have seen this type of process in other industries (the automotive industry uses time based billing, and Dealerships rate their techinicians on how much business (money made from billable hours).

    We work in a skills based environment... the better skills we have, the better we can accomplish our tasks, and better our customers/users are served.

  4. AJ L. said:

    I am in complete agreement with John M.

    There are so many variables that can occur I would never want to see someone publish "time estimates for tasks". The thought of it scares me. There are to many managers/supervisors out there that would use these estimates as a "bible" of how long everything should take and if you don't meet that time estimate.....well we all know how well that will go.

    Besides....how would I be able to keep my rep as a miracle worker? lol

  5. Ian said:

    I'm with John M as well. It's really close to measuring a developers productivity based on lines of code and bugs squashed or a tech support representative's productivity based on closed tickets. It makes for people working towards those benchmarks, rather than actually doing the job.

  6. Pamela Howell said:

    I am not a freak into managing every moment of a developer or sysadmin's time...I would just like to *see* some measurements from different environments to know what it takes, about, to do each task.

    The arguments you guys are giving are akin to those given by the doctors/nurses/hospitals who refuse to use checklists for procedures, on the grounds that they are professionals and well-trained, when in fact even the most professional hospitals now use checklists to make sure everyone gets every step, every time (especially important in fields like infectious disease control).

    I'm just saying, if we had some idea about the time estimates for basic tasks, say like resetting a password in {whatever} environment, we could all think about it more clearly and try to understand why it differs in different environments (different o/s, different installation size/type/style). It just might make understanding the tasks at hand a bit easier.

    I was not particularly advocating a published list of benchmarks, although I do fully understand how management anywhere might easily wish to jump on something like that and use it to all of our detriments.

    Might I propose a secret study? ;->

  7. David Schoen said:

    I think there are way too many variables to get any sensible values for something even as "simple" as resetting a password....

    Assuming we just look at the technical side (i.e. no work done confirming the user is who they claim they are) for resetting a password you have a diverse range of possible OSes, programs with individual auth mechanisms, backend auth modules and unique procedures.

    Unique procedures are things like unique glitches I've worked with that resulted in me having to clear certain forms of cache on a few servers before the user could login, the amount of time would alter with the number of servers and the fact that this was unique to our system.

    More often than not (at least on stuff I've worked on), many components are ad hoc and it's not possible to "simply" reset one password at a time. I have force the password to propagate in to the right systems, this takes time. I also work on client hosted and locally hosted systems, resetting a password on a local cluster can be trivial (using cluster ssh) compared with attempting to do it on client hosted cluster that usually involves some form of RDP + PuTTY hops to get to.

    I'm all for measuring how long the task is taking at any given organisation, assuming it's actually consistent, but don't try to define some figure like "it takes 2 minutes to reset a password on Windows". Is that in an environment where I'm required to re-authenticate as a higher privileged user before altering other users? What about in newer/older versions of Windows?

    Chuck all the other combinations, and it becomes ridiculous.

    Just my 2 cents.

  8. John M said:

    @Pamela Howell:
    I think that you are confusing the issue of following a set of procedures for the performance of a Task, or set of Tasks, to creating a set of values in relation to the duration of the performance of that task.

    My argument is that creating a set of values based on the duration of a task is setting up a enviroment that management could use to evaluate a employees performance.

    As David stated, there are unique procedures that are required for unique Tasks. Some of those tasks require prerequisites that must be accomplished before the original task can begin.

    So, how do you evaluate, or set up a standard value for that task? Define a value based on the task alone, or include the prerequisites?

  9. AJ L. said:

    I can def. see the need at times to have some kind of idea of how long something should take. And maybe it wouldn't have to be negative. This information could help in proving that another person is needed because "x" amount of admins have "y" amount of duties and it takes "z" amount of time to get it all done.

    But then again, how many managers that don't have a real understanding of how we get things done will use these estimates against us. We all know that it's great if you meet the estimated time of getting something done, and it's even better when you beat that time. But what about if it takes longer? Well then managements jumping around like crazy asking "Why is this taking so long?"

    Like Matt & I agreed earlier it really would have to be on a per company basis pending your companies architecture.

  10. Planet Network Management Highlights – Week 43 - Openxtra Tech Teapot said:

    […] Scotty Time: A guilty indulgence? […]

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

*