Hacker News Reader

Comment by magnusss | Hacker News Reader

As the manager of an IT organization, I explicitly use delay as a way to measure need. I usually sit on a purchase request until the requestor (sometime later) asks me, "Hey, what's up with that convenient but not essential thing I ordered last week?" Once I know they really need it enough to ask twice I will consider approving it.

View on HN

When you say "explicitly", do you mean you announce to the whole organization that this is your process? That in order for them to have something delivered they are required to request it twice? Are you actually telling people upfront that their first request will be effectively ignored? Or do you mean that you tell the org there's one version of the process but you are clear with yourself (and/or perhaps, your superiors) that you will actually carry out a second, undisclosed process.

Perhaps you're not filtering out requests on the basis of need, but on the ability of some individuals over others to figure out the unwritten rules and choose to play your game.

"Intentionally" would have been a better choice of word than "explicitly," as I use delay as a decision-making tactic rather than an official, published policy.

Yes, it is possible that people are gaming my tactic and I am optimizing for the wrong variable, but in practice that doesn't seem to happen.

And then there are two reasons and you failed to discern which it is. Either:

1) thing is not essential, you saved the cost

2) a workaround that is inconvenient or costly exists, compare costs

3) you just caused an opportunity cost

In other words, you're breaking the process. Unless you're a process engineer and track both causes and results diligently you should not do that. Ever.

Excellent analysis! I would modify #2 slightly, as a workaround might also be convenient and cheap.

Obviously one should use common sense to avoid adverse outcomes. Inexpensive productivity tools get approved more quickly, whereas upgrades to perfectly fine but previous generation laptops may take a week or so :-).

Often if the workaround is convenient and cheap and know of it, they won't bother calling support.

Then the role of some person should be to gather such tacit knowledge and convert it into a usable and transmittable form.

Now if they do not know about one, they probably should be informed. :)

I'll do this with support, if I respond too quickly then the issue becomes a conversation and the customer will become lazy. Adding a little delay forces them to think for themselves a bit more.

I've learned to do this with clients too.

Some of them would call or email me with some really important, not previously discussed thing that they absolutely needed to have (but really didn't). Where in the past I'd immediately take this request seriously and discuss how many hours/days of work this would reasonably take, I now often give them an unusually high indication at first. If the conversation continues and it becomes clear that they really do want/need said feature, I'll come up with a more realistic indication.

"Nevermind, I've fixed it"

Not an entirely new approach, coded since 1995 in Dilbert:

http://dilbert.com/strip/1995-07-28

http://dilbert.com/strip/1995-07-29

The "approved list" as a philosophy or state of mind remains one of the best approaches.

Reply on news.ycombinator.com