Why your team size is irrelevant

When you work on software helping other software engineers, you end up having an excellent understanding of your craft. At Mergify, we talk to a dozen engineering teams every month, putting us in a pretty good position to understand their problems. This also gives us an average picture of what is an engineering team.

We've grown to learn that there's a discrepancy between what engineers think the Mergify typical users are and who they are in reality. There's also a disparity in the pain points raised by the teams we interviewed — and you'll understand why in a few lines.

That's why I'd like to dig into all of that to clear things out a little.

The Typical team using Mergify

For most people, the typical team using Mergify is a team of 50-100 engineers working on a joint project, throwing hundreds of pull requests every day at their CI, deploying tens time per second while high-fiving at every pull request being merged.

Alright. Does this map to reality?

No. The engineering team we talk to might be as big as 1,000 engineers, but they all work in different repositories and pieces of code. Most teams are, on average, made of a few engineers, from one to 50-100 to for the biggest ones — usually teams working on a mono-repository but on different services.

Though, rather than trusting our guts, we can query our data. For every repository where Mergify is enabled, we track the number of active users — meaning the number of users that made interactions with a repository.

Here are the numbers:

Average: 4.2
Max: 1969

First, half of the repositories have less than two active users. They likely are repositories with shallow activity because they are in maintenance mode. We all have repositories like that.

Only 10% of the repositories have more than seven active users. Only 1% of the repositories has more than 51 active users — and one over a thousand repositories goes above 169 users.

If we dig a bit into the data and remove the extreme, meaning the top 1‰ and the lower 50%, we get a histogram that looks like this.

The repartition looks far from what most people would expect. A substantial part of repositories are under 35 active users, and as we've seen above, 90% of the repositories have under seven active users.

This is where there's a significant misalignment between the value Mergify brings to engineering teams and the idea a lot of engineers have on it.

Let me explain.

Understanding the Key Differentiator

Like I just showed, many engineers think it does not apply to them when they hear about pull request automation and merge queues because they are "too small to see the utility."

The truth is, like many teams, we've been using Mergify with a group of 2 since the beginning, and I've been using it (like many open source projects) on a repository with only one contributor. Crazy.

The team size is not the critical differentiator between Mergify users and non-users.

But then, what is it?

Your Journey Towards Continuous Deployment

The critical differentiator is where the team is on its path to continuous integration and deployment. Let me explain.

Imagine the extreme: a team with no testing and no code review policy. You'd push to the main branch whenever you feel like it, and then you'd deploy by hand (wow, that reminds me of the first company I worked at 😆). Then in such a case, is there any value in automating pull requests? No. There is not even a value in using pull requests. 🤦

Then, imagine the other extreme: a team with an efficient testing policy, clear code review rules based on different criteria (language, domain), automated deployment after a merge, etc. What's the missing piece in that case? Automation. You'd miss a lot not using automation: you could automate review assignment, CI triggering, get safeness by updating pull requests before the merge (so you don't merge outdated pull requests), prioritizing merges (using merge queues), saving CI time (by using speculative checks or batching), automatic merge when CI is finished, etc.

This is where resides the critical differentiator: where your team is on its journey towards continuous and automated deployment.

That being said, this odyssey is not a straight line. There is no absolute, and there's a full spectrum of acceptable states. Every team has different needs, and while the ultimate goal ought to be the same, we acknowledge that the path to reach the ultimate ambition is not going to be identical for every team. We're all on-going to make different trade-offs.

Some teams will have to fix their flaky tests first. Some teams will have to automate their deployment. Some other teams may have to rethink their code review process.

But wherever you are on that path, there is a place for Mergify to shine and lift you to the next stage.

What if we still think we're too small?

There's no good argument to go against more automation. As we already wrote in the past:

The interests from automation compound at a high rate and give software companies a competitive advantage and better margins than their contenders.

The sooner you understand this and focus on your core problem, remove friction from the rest of your engineering activities, and better your company.

And if your excuse is budget, we have a startup program that can give you access to Mergify for free. 😉