I recently read a pretty interesting piece by Peter Siebel, currently running Twitter’s Engineering Effectiveness group.

Let a 1,000 Flowers Bloom. Then Rip 999 of Them Out By The Roots

I’ve found Peter’s premise to be quite interesting:

As an industry we, for the most part, know how to scale up our software. […]We also know how to scale up our organizations, putting in the necessary management structures to allow thousands of people to work together more or less efficiently.

On the other hand, I’d argue that we don’t really yet have a good handle on how to scale that area that exists at the intersection of engineering and human organization. […] And, worse, it often seems that we don’t even understand the importance of scaling it as we go from that first line of code to thousands of engineers working on millions of lines of code.

Peter’s pieces consists of two main parts. The first part is a play-by-play history of Twitter’s code base and development methodologies which highlights the key areas where focus on “engineering effectiveness” would have helped.

The second part decomposes “engineering effectiveness” to three main areas:

1. Reduction of tech debt first where it tends to accumulate the most (tooling) and then elsewhere in the code base
2. Help in the dissemination of good practices (around code reviews, design docs, testing, etc.) and the reduction of bad practices
3. Building tools which help engineers do their job better

In that second part Peter also suggests a model to determine the optimal level of investment in “engineering effectiveness” (ee):

Where “E” is total effectiveness (which we’re trying to maximize), “eng” is the total engineering headcount, “ee” is the engineering effectiveness group headcount, “b” is the boost that the first engineering effectiveness headcount brings to the rest of the engineering team and “s” is the scaling impact that each add’l engineering effectiveness headcount contributes (0<s<1 since we should assume diminishing returns).

Assuming b=0.02 (2% effectiveness boost) and s=0.7, for a total engineering headcount of 10, 100, 1000 and 10000, he gets an optimal ee headcount of 0, 2, 255, and 3773 respectively.   As the engineering org scales, a larger portion of the total headcount should be dedicated to making the rest of the engineering org more effective, with ~100 engineers being the inflection point of making the investment worthwhile (for these b and s values).

Another important aspect here is in providing guidance on the type of initiatives that such organizations should take on: breadth very quickly trumps depth – making 1000 engineers 2% more effective, has a much greater overall impact, than making 10 engineers 50% more effective.

This model is particularly interesting since it can easily be generalized for any other group whose mission is to help a larger part of the org be more effective. These support groups, in companies that are wise enough to have them,  tend to be staffed and funded based on a fixed headcount ratio to the total headcount of the org they support. Peter’s analysis suggests that when those organizations scale significantly, the traditional approach will lead to under-investment. Adopting this more refined methodology and having a thoughtful conversation about the appropriate “s” and “b” values for the particular use case, will likely lead to a better outcome.