Plan Analysis Revisited: The Power of Laziness

On my blog Plan Analysis: Smart Deliverables, someone posted the comment:
    Bob, great article, and I agree with most of it, but I have one comment. It seems to me that working your team to one date while promising externally another date could cause your team to be somewhat lax about the early date since they have some built in slip time. So how do you motivate your team in this sort of situation? In my experience human nature is to procrastinate right up until the drop dead date.
I was going to reply in a comment, but found my reply was big enough for a post.

The author of the comment notes that "human nature is to procrastinate right up until the drop dead date". This underscores a fundamental principle which I believe drives all human (and more specifically, engineering) action: people are lazy. To take it one step further, in another blog I pointed out that every engineer I've ever met falls into one of two categories: smart and lazy, or just plain lazy.

The key to successful leadership is harnessing that laziness, and using it for good. Or at the very least, using it for your own profit. But how?

Well, consider that every day we engineers get up, some of us shower, and we all go off to work. Work seems to be the antithesis of laziness, but it really isn't. We know that if we don't go to work, life would be harder. Harder? What could be harder than sitting in an air-conditioned office, in a comfy swivel chair, surfing the web and drinking Diet Coke all day? Lots of things. If we don't go to work as engineers, we'd have to get a real job, where they make you work and sweat and get callouses. Laziness motivates us to work.

And laziness drivers us to exhert a minimal of effort, which, when you think about it, is good for business. The less effort we spend at each task, the more efficient we are.

Back to the original question... How do you motivate a team to deliver earlier than the absolute latest minute? Appeal to their laziness; show them that if they fail to deliver on time, it will mean more (and harder) work for them in the long run. Let's take an example...

Some years back I was leading a project that included a significant change to a Solaris device driver to support new hardware. The plan was to include the driver rewrite in Solaris 9 since the new hardware would be ready to ship about three months after Solaris 9 is first released. The schedule was tight -- Solaris 9 locks down about three months before it ships, so we had to have the driver done six months before the hardware was product-ready. The responsible engineer was in a panic, and couldn't understand why I wasn't. I explained to him...

If we fail to make the Solaris 9 cutoff, we could include the driver in the first quarterly update of Solaris 9 which will ship at about the same time the hardware is ready. New features are allowed at the early part of an update release, so moving to an update release meant we'd have an extra two to three more months for development and testing. But with that option comes a lot more work: in order to ship in an update release you have to do more testing on your own, fill out more forms, write more reports, do presentations to committees, and request approvals from review boards. Releasing the software in an update release would give him more time, but would take a lot more work.

And if for some reason we couldn't make the quarterly update, we could always release an unbundled patch. But releasing patches outside of the quarterly release process means even more work: more committees and review boards, and you become responsible for doing regression testing on every platform that could possibly be affected by the patch. It's a huge amount of work, but it would buy as an extra month or two.

So, I wasn't worried at all about shipping the software in time to support the hardware; the only question was how much work we'd have to do. The longer we took meant more and more work. The easiest thing to do would be to get the software done early, in time for Solaris 9. The laziest thing to do would be to work fast and hard.

Obviously, every person is motivated slightly differently, and every person responds to pressure differently. One key skill in a project leader is knowing the people, and understanding how they tick. From there you can find the way to motivate them. I think it was Don Rumsfeld who said, "Leadership is by consent, not command," and Eisenhower said, "Leadership is the art of getting someone else to do something you want done because he wants to do it." In the end, you have to find the best way to motivate each person, that is, the best way to appeal to their sense of laziness. Show them that working hard and meeting your early deadlines is the laziest thing they can possibly do.


Post a Comment:
Comments are closed for this entry.

Bob Hueston


« August 2016