Systems Are Good, Actually

Hey y’all — when I grew my team from 5 people to 25 in under a year, it was chaotic to say the least.

It felt like someone new was joining every week, and keeping things organized for them felt like a fool’s errand for two reasons:

1. The company was changing so quickly that any documentation would be outdated in weeks

2. There was simply way too much to do

But not having enough operational structure ended up causing confusion, extra work, and was occasionally a drag on morale for everyone.

It’s recently been argued rather convincingly that, for the first time in 20 years or so, Silicon Valley should consider moving on from “move fast and break things.”

I’d extend that idea to not just the care that goes into the product you share with users, but also the care that goes into the company you share with your employees.

This week I’m sharing how and why you should now consider spending more time on internal processes earlier on than you might think.

Systems Are Good, Actually

Why It’s Never Mattered Before

Ok that’s an exaggeration but it’s true that, for most startups, it just hasn’t historically been rational to invest in building out robust structure around the different parts of the business.

This includes anything from:

1. Documentation of your codebase (if you’re building software)

2. Step-by-step guides for team members on how to do various operational or growth-related processes

3. …you get the idea.

Even new-hire guides tend to be pretty bare bones.

This isn’t because these things inherently don’t matter, but rather because things change so quickly at a startup that they become outdated before they’re done.

And so, if you do invest in them, you’re either delivering something you know won’t matter in a short period of time or spending so much time keeping them updated that you lose time from doing the things that would actually propel the business forward.

It’s been a losing choice.

For years you’ve been better off focusing on your customers, growth, product, and embracing the chaos on the systems side of things while working with people who are ok with a bumpy ride.

Hence the dominance of “move fast and break things.”

What’s Changed?

Not a lot of people saw this coming, but AI is changing this paradigm.

Software was perceived as a moat for a long time because:

1. It took a long time to build

2. It required specialized skills

Over the last 20 years, both of these have been gradually disappearing.

First, the amount of software engineers has dramatically increased and it’s become one of the more popular college majors.

Second, no-code tools have reduced the time it takes to get simple businesses off the ground. No-coders aren’t writing code (in most cases) but they’ve been reducing the reliance on code.

However, like most things, we’re seeing the destruction of this moat go from gradual to sudden right now.

New tools like Cursor, Replit, v0 and others are actually bringing the time that it takes to build functional software down to something that’s shockingly fast (here’s an example).

While, at the same time, remote work and companies like Athena have dramatically opened up the labor pool for software engineering work to people all around the world.

By the end of the decade, software will be a commodity (and hopefully entirely personalized, and on-demand).

Why That Impacts Systems-Building

That means brand, craft, taste, and emotional resonance will matter a lot more to users (and not just in consumer tech).

But it can, and should, also mean a different approach internally at your companies.

Yes, you’ll want to take advantage of the fact that you can build MVPs to get user feedback much more quickly — that’s great.

But you can actually do that so much more quickly that you can be more balanced about how you allocate that extra time you just got back.

And there are now AI tools (like Guidde, coincidentally) to help you create and document those systems with considerable less effort as well.

In this scenario you not only have more time but also maintaining systems, processes, and documentation takes considerably less time than it did before.

It’s not that there are diminishing returns to working on growing the business or talking to users, it’s just that you now can reduce the unforced errors that are inevitable when moving fast and breaking things to a notable degree.

This will speed you up on a net basis, and for many startups will make the time investment worthwhile (especially because your team will likely appreciate it and be less stressed).

And nothing’s higher leverage than your team.

💡 How I Can Help

🚀 Advertise in my newsletter to get in front of 60,000+ founders.