The E-Myth Revisited

Whether building a business or a team, it’s better to be systems-dependent than people-dependent.

To highlight the difference, the author asks a probing question. If you wanted to sell this business, what is the other side buying? In other words, could this business operate without you?

Reframing this question is useful for Senior Engineers and Tech Leads. Ownership of a codebase, system, and product are important. But you need to ruthlessly attack dependencies on you.

If you’re the go-to person for all things $PRODUCT_AREA, you’ve effectively eliminated yourself from promotion consideration. You’re too valuable where you are.

Part of being a technical leader is teaching others and building systems so that you are not the limiting factor to team success, nor limited in your own growth.

Most businesses are started by technicians. For instance, developers who want to start a software company or consultancy. Most start their business because they’re great at their technical skill.

Once the business venture is started, they work in the business – continuing to write code and build systems and do all the technical things they know and love.

They often fail to work on the business.

I should know. I started a software company that failed. On that journey, I should have spent more time working on the business and outsourcing the actual development.

But I loved doing the development, so that felt like a non-starter.

This book provides a good perspective for developers who want to venture out on their own or with a partner.

When you’re part of a small business (like a startup) roles are highly fluid. In this environment, traditional org charts don’t make much sense.

Rather than draw your org chart as it stands today, draw what it will look like when your organization has achieved its mission. When it has achieved full potential.

Then add your name to all of the appropriate boxes. That’s effectively how many jobs you have and what everyone is depending on you for.

The author presents the model case of McDonald’s – a highly systematized organization that operates on low skill labor.

While McDonald’s represents an extreme example, the same principle applies to knowledge work including software engineering.

For instance, today on your team deploying code may require a senior engineer – someone to run the deployment from their machine and possessing the capability to fix a botched deployment.

Then you automate deployments. Now less skilled engineers can deploy to production, likely with both increased quality and decreased cost. You’ve created leverage.

But that’s the obvious part. Here’s the subtle and more interesting byproduct.

Leverage also opens opportunities for more skilled employees to take on right-size challenges, those just beyond their current comfort zone and skill level.

That senior engineer previously executing and babysitting the deployment can now work on more interesting and even higher leverage problems, ones that if solved will open up new opportunities for your business and customers.