Leverage

5 + 5 = 10, right?

Congratulations, you just raised 20 million dollars.
What’d you wanna do? Rocket past your competitors, of course!
How’d you wanna do it? Let’s double the size of our development team so we can ship features faster!

Sounds good right? Now we have twice as many developers, we can ship out new features twice as fast as before and speed past our competitors!

BUT WAIT

The new guys don’t know how we work.
They don’t know where we’re going.
They don’t know why we do what we do.
So they don’t.
They come from different backgrounds and cultures.
Our current band of tight-knit developers who know each other by name, suddenly find themselves in an unfamiliar environment.
They don’t “fit in”.

As Jonathan Low put it best - 2x people usually mean 2x more problems.

Suddenly, you find yourself having to deal with constant merge conflicts.
Developer A was working on a new feature, and it turns out Developer C was too!
Developer B hates to use Typescript and instead wants to code in Elixir because its the “latest and greatest” thing he heard about.

Suddenly, 5 + 5 feels more like its equal to 4 rather than 10.

As you look back on your decision to double your team, you think
“Shit, why didn’t I know this might happen? What could I have done to prevent this?”

Which brings us to the next point:

It’s important to be well-read

Well, duh?
But actually, it’s not so simple.

Scaling shit is hard, but fortunately as Jonathan puts it “it’s no longer an unknown unknown problem”.

There is a ton of literature out there - from how to hire effectively and efficiently, how to pay your people fairly, especially those who have been around when you had very little resources, to how to design your development processes so that your team doesn’t do repeat work, how to architect your infrastructure so that you can support new features, and so on and so forth.

It’s extremely important to know about and understand the myriad of frameworks available.

But often, practice is different from theory.
For instance, salaries are supposedly confidential, as stated in employment contracts.
But the reality is that everyone knows everyone’s salary.

These are intricate details that are incredibly important, but they may not be so obvious in theory. So how do you deal with this?

You can either
a) learn from experience
Or, less painfully
b) learn from other people

Which brings us to the next point

Know when to get help

I defer to Eric Ries’s definition on what a startup is:
“A startup is a human institution designed to deliver a new product or service under conditions of extreme uncertainty”.

At its core, it’s a human institution.
Part of being human is NOT being all-knowing.

Sure, you can learn how to implement fair compensation and banding, or micro services architecture, or how to implement devOps.

But it takes TIME.
In any startup, you have two main resources - time and money.

It’s important to remember that you can “buy time” with money and vice versa.
It’s even more important to remember that you need to ALWAYS optimise for LEVERAGE.

If you can reap the benefits of these knowledge quicker, why wouldn’t you?
You just need to pay someone who knows what his doing!