In tech, tools evolve to be infrastructure
(2/30 of 30 daily writing pieces)
I have never ever ever have anyone respond to anything I write so quickly after I publish until yesterday’s post.
Which leads me to realize how technology when it’s executed well will eventually grow to be like infrastructure. There is a well-known analogy popularized by Steve Jobs comparing the personal computer as the bicycle for the mind. That is a tool perspective: seeing a specific technology as a tool. And the tool perspective will continue to be a useful perspective to understand and build technology for the foreseeable future.
However, as tools proliferate in our lives, complexity grows. And when complexity grows, we need to reduce that … with another tool! Or at least another feature of the existing tools you’re using. Either way, the complexity grows. This reinforcing cycle of tools and tool complexity pushes the evolution of new tools to be more deliberate in their design.
Hence, the emergence of tech platforms and ecosystems.
Substack tries to take away the complexity as much as they can
I banged out my first post in a jiffy. So today was the first time I seriously looked at substack’s settings page. And boy, was it long.
It
The account settings page is so long that they have a search bar (a search bar!) to help with finding the specific knob you want to turn to change some part of the substack account. Not to be confused with the account settings page is the post settings page. Which, frankly, is a lot shorter.
The phenomenon of having settings so long it has its own search bar is not new. Anyone who tries to fiddle with their Chrome browser encounters it as well. And yet all this complexity is safely kept out of sight. The system picks a conventional default and the beginner user happily goes forward unimpeded. And when the power user does feel the need to tweak them, they can find that fairly easily.
This balances the need for power in the tool, the reach of its power, and keeping things simple at the user experience level when directly interacting with the tool in the main use case.
In other words, this is like the infrastructure we interact with on a daily basis.
Think about hospitals, the police force, the roads, the intra-city transport system, and the various government agencies we interact with daily. We know for a fact that they are huge, complex machinery. And our experiences with them simply show us a tiny slice of what that machinery. Each interaction with these infrastructure agencies is (ideally!) optimized to be as simple and frictionless as possible. Every now and then, we need to do something thoroughly complex and then we get to see the guts of that complex machinery.
Build tech for utility needs
If you’re building tech for solving problems or addressing utility needs, it’s natural to think of them as tools. However, you cannot stop there if you’re succeeding. Eventually the growth will force your tool to behave more like the typical physical infrastructure we are used to in 21st century living. Your tech needs to grow its power and range overtime. Hiding away much of the complexity from the beginner users, without completely obscuring them from your power users. That’s an art.