The magic of small engineering teams

In a large org, small teams have no weight. Actually, we have wait - we have to wait for everything: devops resources, marketing resources, even infosec resources. We are too small to notice, not important enough to get quick attention (never mind that our small team's product is profitable).

> Startups ship more per person than big companies – everyone knows this. But how do you retain that advantage as you scale?

You can't! Not really. If you could, we would see companies doing it but...we don't (barring some yet undiscovered engineering process).

Everything you ship, by definition, has an ongoing maintenance cost. The more you ship, the higher your maintenance burden. Over years, this grows and grows. Output (as defined by "products shipped") per engineer must go down, because more and more engineers must be dedicated to maintenance work.

Now, we've gotten really good at disguising maintenance work as product work/shipping things. But it's not reality. Even this post makes this mistake by referring to "data warehouse" and "analytics" as "products". But customers don't care about your data warehouse or your job pipeline.

> Right now, for example, we're in the process of scaling support by moving our support engineers out of the customer success team and into a new customer comms team.

This is not product work. This is maintenance, and is a literal example of the type of thing that larger companies have to do just to maintain their existing products and contributes to lower product output per engineer.

Early stage everybody wears 10 hats, work is distributed and prioritized on a day to day basis.

Once you have dedicated people or teams for task domains then the whole thing shifts to having a need for bureaucracy.

You can slice the number of pizzas anyway you want, but imho once people have a “this is/isn’t my job” mentality (which again, is not a bad thing), you really need to focus on role boundaries and coordination. But the “startup” part is in the rear view.

"I have 1000 engineers and I can't get anything done!"

In the worst case the CEO solves this by doing lay offs. Been thinking about this problem for over a decade, making effective engineering organizations that can not only grow, but change shape is difficult, but can also be very rewarding when done successfully.

At 15 strong self-directed teams, you can have a few teams focused on the high level directives, and a few entropy repair teams that mostly self-manage.

The way to think about it is maybe like homeostasis. Self-directed product teams will implement new features, fix bugs, and generally keep the thing on track, but the efficiency drops off as the feedback mechanisms of talking to customers reaches equilibrium.

To mix metaphors, a leadership team creates a kind of current flow in that system. When you're small you can go to each of those teams and ensure that current flow is happening.

But at a larger size, that doesn't work. You have to engineer and carefully craft the feedback mechanisms the teams are working off of to induce that current. This is a hard problem, but it's where things like minimum attrition policies, OKRs, etc spring from: leadership trying to have a policy that induces current.

The reasons why small teams work is because the number of communication channels go down, and you spend less time simply talking about the work and actually doing the work.

It also feels rich to have a 47 person company tell you they've figured out the secret sauce of people management and team formation.

One thing the article didn't mention is how crucial it is for a team to have focus and to ruthlessly prioritize. It's easier for bigger teams to fall into the trap of doing "busy work" and people fighting for scope on their performance reviews. This is the worst possible outcome for company and employee where you have work driven by optics vs value.

Sharing is good, but as others have pointed out, folks publishing such things could use a bit more intellectual humility. At this point perhaps authors just expect others read it as opinionated anecdotes.

Typical thought leader dogma aside, using pizza as a metaphor for team size has always been silly to meaningless.

Startups can quickly change alignment to make the company work. They can throw more spaghetti at the wall to see when it's done.

> But how do you retain that advantage as you scale?

Once the company figures out what works, you'll want to put people and processes in place to keep it working. That means bureaucracy. That slows change. Intentionally.

In big commercial kitchens no one throws spaghetti at the wall. That's waste.

Of course you can keep splitting your teams when you are delivering a well defined product to customers. You could probably also have not split those teams. 50 people is trivial to manage, you could all meet in a room, should you have kept them geographically close. You may even have succeeded despite neutering those teams into triviality. You simply don't know.

Try doing something even slightly more complicated: Build a bridge. Or run a hospital. Or even a pension fund. Or just a software company with a lot of products. Those nice trim teams would quickly run into the brick wall of human communication.

That's the tough part of any organization. And we as a society needs to organize on large scale to get the important things done, unfortunately. Getting the easy things done is not enough.

Are they?

Apple revenue per engineer is $2.4M. It seems hard to beat.

They don't know how much pizza I can throw down, especially when the company is paying.

> Right now we're 47 people

I'm sorry, but you haven't solved scaling small teams.

Their product is a collection of micro products which is pretty unusually especially for a company at their stage and size