From point A to point B.
If you're looking to optimise a process, either for efficiency or effectiveness, you're better off just starting with the simplest possible approach, in the sense that complexity usually masks underlying problems rather than solving them.
For example, I wouldn't add multiple automation tools before understanding a core workflow thoroughly.
Because doing so creates artificial dependencies and workarounds that become almost permanent fixtures in the system, making future changes more difficult to implement.
In such a case, I'm not optimizing at all but rather just adding layers of complication.
And this is coming from a realization that the path between two points is rarely a straight line in practice, and usually the clearest path emerges after you've walked it once or twice, maybe thrice.
I think in hindsight, realizations are basically obvious truths that were hidden in plain sight all along, waiting for us to gain enough context to see them.
Another example could be personal investment strategy. Do you create elaborate spreadsheets tracking dozens of metrics or establish a consistent saving habit and a basic index fund approach with automatic contributions?
Needless to say, I've heard of stories of people who create sophisticated investment algorithms while fairly new on their investment journey.
Between both examples, it's obvious that simplicity beats complexity when you're still learning the true nature of a problem.
What's not so obvious is when to embrace complexity once simplicity has taken you as far as it can.
Which is usually when you've mastered the fundamentals and hit genuine limitations with your current approach, and this is where I tend to struggle, in the sense that I would either stick with simple approaches for too long out of comfort, or jump to complex solutions too quickly, thanks to impatience.
The journey from point A to point B isn't necessarily about the destination, although that does matter significantly. If it weren't for the destination, then we might as well wander aimlessly without purpose.
What matters equally, if not more, is what you learn during the journey and how those lessons transform your approach to similar situations in the future.
For me, it's one of those paradoxes that the fastest way forward always requires slowing down first, then taking time to understand fundamentals to later accelerate progress in the long run.
Looking back at processes I've optimized over the years, my first attempt was almost always over engineered.
Partly because of my eagerness to create something impressive rather than something effective.
I think this is the case for most people, why not try our hand at building something complex and sophisticated, even though simplicity would serve us better?
That said, It's still tempting to anticipate every possible edge case and build solutions that account for all of them.
The main drawback however, is a difficult to maintain and adjustable system/framework, especially when new information comes to light.
Iterative improvement—starting with a minimal viable process and refining it based on actual experience—yields better results than trying to design the perfect system from the outset.
Also, learning to distinguish between essential and non-essential complexity is arguably the most valuable skill in optimization.
Some complexity is unavoidable and serves a purpose, for example, maintaining separate investment accounts for retirement, emergency funds and other necessities.
Other complexity is just noise that distracts from the core goal. Examples here could include tracking every market fluctuation daily/weekly.
For the most part, the latter can be easily confused for the former, just as busyness tends to be mistaken for productivity.
Is diversification an unavoidable complexity or just an excuse for lack of conviction, btw?
Thanks for reading!! Share your thoughts below on the comments.
