“My initial reaction to the idea that continuous improvement begets enduring success was ‘makes sense, companies need to reinvent themselves if they want to stay on top for multiple decades and continuous improvement will do that for you’, but that underplays the importance of the point. An insatiable desire for everything to be the best it can be is key to getting to the top, not just to staying there.
Moreover, as the world changes faster and faster any other attitude is doomed to failure. A solution that’s perfect for today won’t stay perfect for very long, so unless you want to be usurped by someone who finds the solution that’s perfect for tomorrow, you’d better be continuously improving.
In the early days of a startup nothing is perfect, and oftentimes most everything is far from it. Customers might love the core product functionality, but there’s constant firefighting behind the scenes to keep everything working, make more sales, hire more people, raise more money etc. etc. Once again, relentless continuous improvement is the best route to success. Even when things are working really well the best founders aren’t happy – they’re asking themselves questions like ‘how can I grow faster?’, ‘how can I be more profitable?’ and ‘how can I make my customers love us more?’.”
Nic Brisbourne.
The headline to today’s blog seems completely obvious right? As the world changes faster and faster, there are less chances to create enduring advantage, so it also makes sense that an enduring advantage only comes from the ability to find new advantages.
Nic’s paragraph about the early days of a startup where nothing is perfect probably also reflects where OSS is up to. We’re so occupied on the firefighting, the tactical, the small improvements that we don’t always get to ask the big questions. The questions that hope to lead to significant, not just continual improvements.
For me, continual improvement means one thing – a feedback loop. But the thing I find interesting is that l have almost never seen feedback loops underpinning our process designs, our product functionality*, even our strategies.
* Note here that I am seeing it appear in our product development approaches (eg agile, dev0ps, etc) but not so often in our functionality within the products.