In my previous post, Working Hard, or Hardly Working?, I mentioned how it was possible to tell the wheat from the chaff by observing.  Alistair Cockburn rightly suggested that the manner of observing that I suggested was more appropriate for a team leader than for upper management.  Yes, he’s quite right about that.  He had in mind a Vice President who, when told that the development team had estimated something would take two weeks, asked him,

How can I tell if it really should take that long, or they’re just padding to make their life easier?

How would you answer that question?Alistair says he had no answer.  I have a question.  What does “should” mean?

At one level, it’s a tautology.  If they’ve already done the work and it took two weeks, then “bearing in mind that there are many factors of which I am unaware, since the event has already occurred, it is obvious that” this work should have taken two weeks.

Or it’s a self-fulfilling prophecy.  For these developers in this situation, it’s going to take at least two weeks if they’ve decided that.

Now it could be they’ve estimated poorly, and they’ll deliver it in one week to everyone’s surprise.  So it shouldn’t take that long and it didn’t.  If there’s padding, it’s probably to prevent disappointment rather than to avoid work, else they’d have stretched the work out for the full two weeks.  You’re likely to see this behavior where estimates are treated as commitments.  You’re also likely to see this when developers have become accustomed to such treatment elsewhere.

It could be that some other set of developers could easily do this work in one week, but the best that this set can do is two weeks.  Does that mean this set of developers should be able to do it in one week?  Should they have the experience with this sort of problem, with this language, or the skills to work faster?

It could be that these developers could do the work in one week if it weren’t for all the impediments in the environment.  Maybe the computers are old and slow and have too little memory.  Maybe there are delays waiting for information or confirmation or projects on which this one depends.  The developers should be able to do it in one week, but due to circumstances beyond their control they can’t.  Should the circumstances be different?

It could be that these developers could do the work in one week, but they think it implies other work that isn’t part of what’s being asked of them.  If it were discovered that they thought this extra work were part of the request, then they could be disabused of this notion and complete the work in one week.  But it’s not discovered, so the developers do some unwanted speculative work and it takes two weeks.  Should they have noticed and done it in one week by doing just what was wanted?

It could be the developers feel that they’re treated poorly.  They feel demoralized and it’s hard to get out of bed to come to work, much less to focus on the work they have to do.  If they weren’t so depressed and disorganized, perhaps they could get it done in a week or less.  But everything seems so hopeless to them that it actually takes two weeks.  Should they be able to shake off their depression and get it done more quickly?

It could be the developers are lazy SOBs who are out to do as little work as possible while drawing their salary.  They take frequent coffee breaks where they talk about sports.  When at their desks, they spend hours playing Quake or surfing random websites.  Should they work harder on the company’s business when on the clock?

These are all quite different scenarios.  The world “should” seems to mean very different things in each of them.

Should someone who has risen to the level of VP be about to tell the difference between these scenarios?  Well, of course.  But this use of “should” has as many meanings as the one concerning the developers.

Should she have some comparable experience to use as a sanity check?  This would also be nice.  But maybe it’s a new industry.  And given all the possible situations listed above, how can she now if it’s comparable?

Should she take the time to talk with each developer, one on one, to learn how they view their work and the company?  If the question is important to her, then I think this is the way to go.  Having these conversations can, if handled well, contribute to mutual trust.  And the very wording in the question indicates to me that in this situation, trust is not as strong as it might be.

But the direct benefit is insight.  Some of the questions in my head would be

• What is it about this job that makes it take two weeks?
• How sure are you that it will take two weeks?  What are the chances it might take one week?  Or three weeks?
• What are the unknowns about this work?
• What similar work has been done by this team?  How long did that take?  How does this work differ?

I might not ask these questions directly, but instead talk with each developer until the answers seemed clear to me (or that the answer would never be clear).  If Ms. VP hasn’t practiced this, she might benefit from something like the Unearthing the Data You Need session I attended at AYE 2008.

And, if it really is just a case of a goldbricking team, then it’s unlikely that all of them are equally skilled at pulling the wool over our VP’s eyes.