Every once in a while you come across a term that captures what you want to convey – and one that caught my eye recently was “pain-free progress”.
It was made in the context of physical pain but I think we should be able to use it when talking about software as well.
There’s a big disconnect in the way programmers see the world and the way managers see the world.
Programmers build what you want – give them a specification of what’s required and they’ll make something that does that.
The problem is that if you ask people what they want, you might end up with a long list of requirements.
But is it what they need?
This approach often results in programs that do what they’ve been asked to do but struggle if they’re presented with something outside what they’re designed for.
Managers, on the other hand, are usually just tired.
What they need is for the thing to work and make sense.
I’ve found that when you’re building or selecting software tools to help manage an aspect of operations the first version you create is the one that helps you learn what is really needed.
You’ve got two options from there.
One is to build on what you’ve made – add more functionality and features.
The other is to strip back – what is useful and what isn’t? How can you reduce the number of things that are going on so that what’s needed is done more simply and reliably?
The second approach, I think, is closer to my idea of pain-free progress.
Ironically, the leaner your system, the less it does, the more flexible and reliable it usually turns out to be.
Handcrafted insight 