[Business Process] Software is Eating the World
Today's software engineers are business conductors
Way back in 2011, Marc Andreessen published the now-famous WSJ op-ed entitled “software is eating the world”. It was a prescient piece, basically all of which came true over the intervening decade and a half since then. Even as the most red blooded hardware guy you’ll find - I can assure you that software has made a massive impact on businesses and people around the world. This has been certainly enabled by hardware, and there have been serious hardware advances over that time: orders of magnitude improvement in chips, smartphones, self-landing rockets, EVs, batteries, etc.
So, is the software dominance over? No, but its meaning is shifting: software is no longer a linear user input/output function, but instead, at corporations, software is a baseline layer to execute business processes. The engine that powers those business processes - AI - isn’t the differentiated, or I’d argue, hard part anymore.
I’ve noticed this more now than ever at Base Power. We have a really operationally intensive business: from high volume direct to customer sales, to high volume manufacturing and distribution, to onboarding through multiple regulatory steps such as utility interconnections and retail energy enrollments. Throughout the last ~2.5 years, we have chosen to take on a decent amount of the development of software that supports these functions internally. We started by stitching together off the shelf software (oftentimes with Zapier automations), only to find out that the labyrinth of Zaps was hard to maintain and observe. A more recent, concerted effort on business process software has yielded solid results, although we have a long way to go.
Software engineers are turning into business process engineers. They are more architecting the framework of the software from the outside in rather than building it from the inside out. They are like the conductor of an orchestra as opposed to the one playing the violin. As companies think about hiring and training software engineers, they should spend more time on business acumen and technical scrappiness than syntax-level understanding. The best software engineers I’ve worked with have these very skills: they are curious and sensitive to operational business requirements, and importantly have intuition on what to build more than just how to build it.
All of this is not to say that the big old corporate software providers: SAP, Oracle, Dassault Systems, Microsoft will win the day. Likely in fact, the opposite. As companies adopt the aforementioned way of thinking, hiring employees, and training software engineers, they will begin to build more and more of their internal systems in house. Most “good” modern companies/large startups (such as SpaceX, Tesla, Rivian, Ramp, Anduril) have gone the route of building their own systems for manufacturing, inventory management, and customer flows. My view is that this continues, and begins to also happen at the larger older companies such as GM and Boeing, who realize that homegrown software is both easier to build and more efficacious in the era of AI than it was previously.


Love this!
The conductor analogy is spot on. Software engineers are increasingly orchestrating business processes rather than just wrting code. Your Base Power example ilustrates this perfectly, the Zapier maze you described is a common trap for companies trying to automate without thinking systematically. The shift toward inhouse systems at companies like SpaceX and Ramp makes sense when you consider that off the shelf solutions cant adapt quickly enough to unique operational needs.