In September 2015, Peter Seibel of Twitter wrote one of my favorite blog posts:

Peter was a technical lead on the Twitter Engineering Effective Group. His role at Twitter is not dissimilar to what I do at Adobe. The article talks about how Twitter handled technical debt (or didn’t) as the company grew. Many of the problems that Twitter encountered are similar to what Adobe is dealing with today. The Adobe Marketing Cloud is a conglomeration of many acquisitions; each of which came to us with its own data platform, data collection and data processing, plus their own style, culture and technical bias. We have a 1,000 flowers blooming.

We need a platform.

One of the many things I like about Peter’s blog, was his model for effectiveness. Engineering organizations have a common problem: how many people should be working directly on “the product” versus how many engineers should be working on “the platform”. The idea is that the platform will make product engineers more effective.

The model that Peter used was:

E = (Nt — Np)(1 + bNp^s)

where E is the total effectiveness, Nt is the total number of people, Np is the number of people working on platform projects, b is the effectiveness boost for the first platform member, and s is the scaling of the boost. The units for effectiveness are people. One person has an effectiveness of 1; 2 people have an effectiveness of 2 people, and so on.

It’s a good idea to get a feel for this equation. If no one is working on the platform (Np = 0), the effectiveness is Nt. This is exactly what you would expect: if you have Nt people working on the product, their effectiveness would be Nt. If no one is working on the product (Nt — Np) = 0, then the effectiveness is zero, which also makes sense. The (Nt — Np) term reflects the fact for every person working on the platform, the product effectiveness is reduced by that amount. The bNp^s term reflects the boost in effectiveness caused by the platform team. b is the percentage increase that a platform member increases the effectiveness of a product member. b = 0.02 means a single platform member will increase the effectiveness of a product member by 2%. A 2% improvement is modest, but small improvements in effectiveness add up. The Np^s reflect diminishing returns on adding more people to the platform team: every time you add someone to the platform team, the effectiveness boost is reduced. Peter argues for using s = 0.7, which seems reasonable.

This model is not complete, but it is helpful in understanding the dynamics of an organization. The results are heavily depended upon the values selected for b and s. If your platform team works on the wrong projects (b is small) or if your platform team has its own dysfunctions (s is small), then you are not going to see much effectiveness in having a platform team — and the model predicts this. If this is the state of your organization, then everyone should be working on the product and forget the platform.

Let’s take a look at how the model behaves for different organization sizes. For an organization of 10 people (Nt = 10, b = 0.02, s = 0.7), the effectiveness is

For an engineering group of ten people, moving engineers to a platform team makes little sense. Individual engineers will work on improving their own effectiveness. The product team is the platform team.

For an organization of 100 people (Nt =100, b = 0.02, s =0.7), things start to look different:

In this organization, having 3 people working on the platform team will increase the overall effectiveness of organization. This is very consist with what I’ve seen at Adobe. When teams get to about 100 people, a small group of engineers will start to work on infra-structure projects and small exploratory projects to improve identified problems. Again, there is no need for an official platform team.

For an organization of 1000 people (Nt =1000, b = 0.02, s = 0.7), the story is different:

By creating a platform team with 259 people, we can have an organization of 1,000 work with the effectiveness of 1,465 people.

By creating a platform team with 259 people, we can have an organization of 1,000 work with the effectiveness of 1,465 people.

In other words, for a larger organization, by having 25% of your engineers working on the platform, you will increase total organization effectiveness.

Note that the model is only a model. For a given organization, the values of b and s can be ambiguous, which makes it difficult to determine the optimal number of engineers that should be working on a platform team. Thus, the specific result of 259 engineers should be taken with some fuzziness.

As a company with engineering teams dedicated to multiple different products, Adobe tended to think of itself more as multiple 100 person developer teams. Each 100 person organization was happy to devote 3% of there engineers to common-good projects — as the model suggests. But, this approach only increased the total organization effectiveness by a modest 1% — also as the model suggests. This falls short of the optimal number for such a large organization.

You can also see why the creation of a platform team is so hard. Reassigning 25% of your engineers seems crazy from the perspective of a 100 person organization. The simple linear model suggests that reassigning 25% of your engineers would result in a ~17% DECREASE (100–25 + 25/3) in effectiveness. Plus, platform teams are more often than not created by reassigning headcount from existing teams, not hiring new engineers. No manager wants to give up productive engineers.

Here is a graph of the optimal platform team size as a function of the organization size:

As you can see, for large organizations, the optimal platform team becomes a simple ratio

Np optimal = (1 — s) Nt

It’s interesting that Np stops being dependent on b, the boost. But, this makes sense, because the effective boost of the first platform engineer becomes irrelevant when the organization gets large.

It’s also interesting to note that for very large organizations (Nt > 5000), the platform team itself will most likely need to be reorganized: the platform team will need its own platform team.

For organizations with more than 5000 engineers, the platform team needs its own platform team.

My next blog post will take Peter’s model a step further. Peter’s model is a static analysis: it looks at organization effectiveness once product and platform teams are working well together. In reality, it takes time to develop a platform team and realize the boost in effective. In my next post, I will add a temporal component to Peter’s model, and we will see the “Engineering Manager’s Dilemma”.