Mike's Weblog

Chasing Ambiguity

This is a small, but effective, technique I've used when leading larger software projects (although it might well apply to most disciplines of engineering). Put simply: given two tasks of equal priority, choose the most ambiguous one.

Why? Well the ambiguous one is most likely to spawn off new tasks, and for planning purposes it's way better to know about those earlier than later. Sometimes it's something simple like "we need to refactor our library first to deal with this new problem", but sometimes it's something more complicated like "we need to talk with team foo to have them load a new key for us, which will take 4 months to validate and roll out".

It sounds almost almost blitheringly obvious when said out loud, but I find explicitly chasing down ambiguity in the planning phase leads to better results and happier teams.