The book I’m currently dedicating my time to is E-Myth Revisited by Michael E. Gerber. So far at least for me it has not disappointed the reviewer recommendations. While the tone and storytelling takes a bit of getting used to, it quickly establishes a very familiar archetype “technician” and explains how each of us are multi-faceted creatures or as I like to say - we tend to wear a multitude of different hats. And of course the trap of working in the business instead of on it.

However I don’t want to talk about starting a fresh new business (I’m not there yet in my own journey) - rather I want to explore how the book nudges the reader to consider the need to become an engineer or designer of systems to unlock the true potential of their business, and how well this maps to the topic of AI adoption challenges for enterprises that are very far from startup scale. The first one is obvious - AI being the buzzword of the year several years in the row now is treated as the one thing that is just needed with the right tools and the right prompts and it’s going to magically make things faster, especially if a lot of the institutional knowledge is fuzzy and in the heads of key stakeholders. Repeatable pipelines, guardrails and outcome checks that are automated, and a somewhat organized pattern and process for capturing knowledge/instructions and work is needed. The go-to RAG is just one of the technical solutions that’s dead in the water if the organization can’t define its systems.

Speaking of processes, even the best engineers can get lost in prompts, skills, plugins and workflows without standardized work to guide process improvement loops. Just like it serves as a “fly-by-wire” for technician-turned-manager it helps scaling AI through architected autonomy. Industry knowledge helps technicians to maintain control, but only based on the “system” they’ve learned or organization hearsay which may lack important nuance, details or conventions that are obvious to people in the business, but derail attempts at improving automation outcomes unless employees, people that actually do the work are interviewed and their practices/know-how captured.

Lastly and maybe most importantly technicians love the craft of the custom built - the bespoke hammer, the unique repair. This inherently limits the scale that can be managed. With the abundance of tools that churn out custom solutions with relative ease it’s too easy to get carried away and forget the benefits of doing proper engineering. Enterprise automation requires transition to a modern digital assembly line (just like the book calls for Franchise prototype). While unique in its own right for each customer’s context, it should bear the same traits - standardization of architecture, reusable templating skills, automated and deterministic quality gates and beyond that - standardizing processes. Besides this standardization of work and solutions leads to more manageable mental models that hide less surprises and where deviation from established practices is more visible.

The takeaway seems to be that we are given such powerful tools that have been crafted over the course of decades (lean, theory of constraints, agile), that given the new possibilities to create things out of “thin air” and a prompt we should first apply these powers in shaping/engineering and documenting systems of business rather than heading head-first into the thick of doing the work.