“Most systems deal with complexity by adding more – more systems, more measures, more internal meetings, more units, more custom products, more unique processes, more new initiatives, more coordinators at the interfaces, and on and on. Our belief is that for more companies, the antidote to escalating complexity – and to the greater distance between management and the reality at the front line – is simplification, creating greater focus and liberating energy.”
Chris Zook and James Allen, in their book, “Repeatability.”
The quote above comes from a book that describes how the most successful organisations in the world have repeatability woven into their business models. It may be a quote about organisations, but it perfectly describes OSS projects don’t you think?
Another quote from the book is as follows, “In the complicated and constantly evolving world of business, keeping your business simple can be and will be a tremendously important competitive advantage. If you engineer your organisation so simplicity can triumph and reign supreme, your competitors will wonder what hit them. Even more importantly, customers will love being the centre of attention.”
Do you agree with Zook and Allen? Do you think that simplicity can be a competitive advantage? If so, why?
I do tend to agree with them. I also believe that it will take an entirely different way of thinking by everyone in your organisation. An entirely less brilliant way.
For example, when defining a list of requirements for our latest OSS, do we have a tendency to think of a scenario and immediately start thinking of all the “what ifs” that could occur? Do we also have a tendency to assume, “this ‘what if’ scenario could definitely happen,” but not actually take the time to investigate and confirm its likelihood? I’ll be honest here and say that I’ve been guilty of this, as have too many past OSS project colleagues for me to count.
Does it make sense that if you truly investigate each requirement and confirm whether it really is important (ie it fits within the 80% of the Pareto Principle), rather than assuming, then you will cut down on the downstream effort (ie to design, to test, to build data sets, to deliver, to maintain, etc)? So many of us just don’t begin to think about what the downstream impact will eventuate from our brilliance (in being able to identify boundary cases).
Less brilliant, but brilliant in its simplicity.