



Technology
"I Can’t Play with my Friends"
Why SBMM makes it so friends of different skill levels can’t play together (and how to fix it)
Author
Charlie Olson
Oct 3, 2025
SBMM = Skill-Based Matchmaking
MMR = Matchmaking-Rating (aka skill-rating, or sometimes “Elo”, or simply μ)
The disappointment is real. Lower-skill players party up with a higher-skill friend, end up playing in high-skill lobbies, getting destroyed, and not having fun.
Why can’t friends with different skill levels play together?
It doesn’t have to be this way, but why does it happen in the first place? Why can’t disparately-skilled friends play together? There’s a cascade of reasons, but it ultimately comes down to one or more of these conditions:
Party-skill is biased toward the highest-MMR player.
The team-balance criteria is oversimplified.
There aren’t enough players to choose from.
1. Party-skill is biased toward the highest-MMR player
Matchmakers do this in Ranked modes to prevent sandbagging / reverse-boosting. Weighting party skill in this way is necessary in competitive modes, but in casual matchmaking, it can take the fun out of playing together.
In Casual modes, games sometimes still bias parties toward higher MMR because players perform better — and more consistently — with friends. If MMR doesn’t adapt quickly (like with TrueSkill), then parties have a constant advantage at the expense of solo players.
In the most extreme case, the way biasing works is that everyone in the party assumes the maximum skill rating of the party. So, in a party of two players, one with 100 MMR and the other with 900 MMR, the matchmaker treats them both like 900 MMR players:

Fig. 1: extreme party-skill biasing
There are less extreme ways to model disparate party skill than simply taking the max (advanced Team and Party Modeling), but the motivating factors for including some bias are:
Players play better with their friends
Parties have less randomness in their performance
It’s easy to use a smurf account to deflate the party MMR for easier matches
I would argue that these factors are mostly unnecessary considerations in casual matchmaking. With the right approach to MMR and matchmaking, all of these issues can be mitigated without biasing the party MMR, but hang on, and we’ll get there.
2. The team-balance criteria is oversimplified
The easiest way to balance teams is to minimize the difference in total MMR between teams.
Most team-balancers work this way, even in AAA, because it’s a quick-and-easy condition to evaluate, and if matchmaking is reasonably tight, it usually leads to balanced matches.
Unfortunately, it leads to some terrible matches as well. If SBMM is loose — so there is a wide range of MMR within each match — this style of team-balancing will lead to the classic “hard carry” scenario, where an exceptional player is expected to carry bad teammates against an enemy squad of average players.
In the case of 900 MMR and 100 MMR in a party together, the hard carry scenario will become even worse with tight SBMM. With tight SBMM, matches will look something like this on average:

Fig. 2: “hard carry” scenario for the 900, with tight SBMM
Furthermore, if the party skill is also biased (condition #1), the opponents will be even stronger. Either way, the 100 will assuredly be the worst-performing player in the match on either team. Will casual players find this an enjoyable experience that they would like to return to? Probably not.
To prevent this scenario, the team-balancer should optimize for the difference in MMR distributions, not just the difference in total MMR.
An easy way to implement a better match-quality function then — if team MMR is already sorted — is to find matches that minimize the difference-of-sums plus the sum of the absolute errors between corresponding players:
Team 1 | Team 2 | Abs(Error) | |
---|---|---|---|
player 1 | 900 | 500 | 400 |
player 2 | 100 | 500 | 400 |
team sum | 1000 | 1000 | 0 |
total error | 800 |
Bad Match: both teams have 1000 MMR, but 800 error
Team 1 | Team 2 | Abs(Error) | |
---|---|---|---|
player 1 | 900 | 700 | 200 |
player 2 | 100 | 100 | 0 |
team sum | 1000 | 800 | 200 |
total error | 400 |
Still bad: Team 1 is OP, so 400 error
Team 1 | Team 2 | Abs(Error) | |
---|---|---|---|
player 1 | 900 | 800 | 100 |
player 2 | 100 | 200 | 100 |
team sum | 1000 | 1000 | 0 |
total error | 200 |
Pretty good: both teams have 1000 MMR, only 200 error
Team 1 | Team 2 | Abs(Error) | |
---|---|---|---|
player 1 | 900 | 900 | 0 |
player 2 | 100 | 100 | 0 |
team sum | 1000 | 1000 | 0 |
total error | 0 |
Perfect match
If teams have unequal player counts, this approach still works as long as the MMR system has a meaningful absolute zero. Every missing player just becomes a zero. So, with IVK Skill that will work, but with Elo or TrueSkill it will not. Without an absolute reference point, MMR systems cannot model unequal team sizes or non-linear relationships.
Minimizing the sum of the difference-in-means plus difference-in-deviations also works. Deviations can be Standard Deviation, or Mean Absolute Deviation. Or weighted variations of that, depending on how you want the team-balancer to manage the trade-off between matching the skill distribution vs matching the total strength.
Side note: if someone complains about SBMM because they “always get terrible teammates”, they are actually complaining about the lack of SBMM combined with naive team-balancing. If SBMM was stronger, there would be less of a gap between the best and worst players on their team.
3. There aren’t enough players to choose from
Unfortunately, a lot of matchmakers (if not most) have two distinct steps:
Assemble players for a match
Balance teams within the match
Step one tries to find players of similar skill, and step two tries to partition them into fair teams. This works fine when it’s all solo players and there aren’t a lot of considerations for team-composition (hero preference, role, etc), but in practice, step one filters out the diverse player skills needed for proper team-compositing.
Case in point, with a 900 MMR + 100 MMR party playing 2v2 (or full-stacks with any team size), there is only one way to arrange the teams, making the team-balancing step irrelevant.
What are the possible solutions then?
Test and reject (a lot of) matches whenever team-balance-quality isn’t good enough.
Inefficient and sub-optimal results.Build teams and matches simultaneously.
Requires a different approach to matchmaking.
The first option unnecessarily increases wait times for players, and still won’t guarantee good matches, but it’s the easiest approach for most matchmaking frameworks: bring players together based on skill, latency, controller type, language, etc, try to make teams, and finally discard the potential match if the teams won’t work well enough.
A better solution is to build teams and matches at the same time. Choose a player or party (a “ticket”) from the pool of all available tickets that will incrementally improve the match quality. In the 2v2 example, if 100 and 900 must be on a team together, the best incremental improvement would be either:
Another party with a similar mean and deviation
Likely requires extra wait timeA solo player near the min or max of the existing team
(then pick another solo player to match the deviation in the next iteration)
Only consider this option if it’s acceptable for your game to put solo players into high-skill-gap matches (it might not be)
IVK Match (our matchmaker) works this way. In each step, the matchmaker chooses the best available incremental improvement, with an optional rebalance as a last step.
This approach works well with a centralized, optimizing matchmaking service (like IVK Match). But, it’s also adaptable to old-school, distributed matchmakers — as long as each client makes very broad queries and selflessly evaluates how much they could improve every potential match. Still, client-side matchmaking is not recommended due to increased complexity, inefficiency, wait times, and unreliability.
MMR Matters
It’s inherently difficult to make good matches with players of disparate skill, but it becomes impossible for matchmakers built on shaky matchmaking ratings (MMR).