Captaincy frameworks: three ways to pick a captain
A durable explainer on how to pick a captain in fantasy cricket. Three frameworks, the conditions under which each is the better pick, and the common mistakes that quietly sink a side.
What a captain pick actually does
In most fantasy formats, the captain pick earns a multiplier on the points scored — typically 2x. The captain is therefore the single most-used decision in the team: a captain who scores 20 more than the alternative is worth 40 in fantasy points, which is more than the credit-allocation difference between any two players in the same slot.
Why the captain pick matters more than credit allocation
Credit allocation compounds through the team shape. A captain mistake is recoverable inside the same fixture; a credit-allocation mistake cascades through the rest of the contest.
The floor framework
The floor framework prioritises the player with the highest expected score at low variance — usually a top-order anchor with a settled role. The framework is anchored to the role hierarchy on the team page: a player who has batted at slot 3 or 4 in the last four consecutive matches is the floor-framework default.
The framework underperforms the ceiling framework only when the conditions read is unusually clear (a flat surface with short boundaries for a powerplay specialist, or a slow surface with heavy square boundaries for a wrist-spinner). The floor framework is the desk's default in close contests because the conditions read is rarely unusually clear.
The ceiling framework
The ceiling framework prioritises the player with the highest upside — usually a powerplay or death-overs specialist. The framework is anchored to the matchup read: a powerplay specialist against a team with a weak new-ball attack, or a death-overs specialist against a team with a strong death-overs batting lineup.
The framework underperforms the floor framework when the matchup read is wrong — when the conditions read is uncertain, or when the opposition's weakness is less pronounced than the desk assumed. The ceiling framework is a higher-variance bet than the floor framework; the desk uses it only when the conditions read is unusually clear.
The matchup framework
The matchup framework prioritises the player whose role is best suited to the specific opposition's bowling or batting pattern. The framework can produce either a floor-style pick (a top-order anchor against a weak new-ball attack) or a ceiling-style pick (a powerplay specialist against a team that has historically leaked boundaries in the powerplay).
The framework is the most context-dependent of the three. It requires a specific matchup read on the opposition's strengths and weaknesses, and the read has to be anchored to evidence — head-to-head fixtures in the same format and venue category. The desk's working rule is to use the matchup framework only when the matchup read is supported by at least three data points.
When to switch frameworks
The default is the floor framework. The switch to the ceiling framework is justified when the conditions read is unusually clear — the desk's working threshold is a 70%+ confidence in the conditions read, which usually requires a recent pattern of conditions matches the model. The switch to the matchup framework is justified when the opposition has a specific weakness that the head-to-head evidence supports.
Why we don't switch often
Most fixtures do not meet the threshold for switching frameworks. The floor framework is the default because it underperforms the alternatives only in conditions-read-clarity scenarios, which are rare in a typical fixture week.
Common captain-case mistakes
| Mistake | Cost | Working rule |
|---|---|---|
| Chasing last match's top scorer | Medium | Wait for two consecutive matches before upgrading a player |
| Over-stacking captain + vice-captain | High | Never captain + vice-captain from the same team |
| Picking on reputation rather than role | High | Filter on role first, form second |
| Ignoring the conditions read | High | If conditions read is unusually clear, switch to ceiling |
| Picking on ownership use alone | Medium | Ownership use is a separate axis; high use is only useful if role is settled |
The desk's working rule
If you would not lock the same player in as captain in two out of three similar fixtures, the role is not settled enough for the floor framework. Switch to the ceiling framework only when the conditions read is unusually clear; switch to the matchup framework only when the opposition weakness is supported by at least three data points.
Worked example: a floor-framework captain pick
A worked example for the floor framework: a top-order anchor in the chasing side who has batted at slot 3 in the last four matches, against an opposition whose new-ball attack has been reliably tight in the last three fixtures. The captain-case table names the anchor as the conservative case; the aggressive case is a powerplay specialist in the same side, banked on a flat surface with short square boundaries. The conditions read is not unusually clear, so the desk's default is the conservative case.
The worked example is hypothetical — it is not a real team the desk has picked, and it does not represent a recommendation. The aim is for the reader to see how the framework handles a non-trivial input: a top-order anchor with a settled role, an opposition with a reliable new-ball attack, and conditions that are not unusually clear.
Worked example: a ceiling-framework captain pick
A worked example for the ceiling framework: a powerplay specialist in the chasing side against an opposition that has leaked boundaries in the powerplay across the last three fixtures, on a flat surface with short square boundaries. The conditions read is unusually clear (the surface is flat, the opposition has a known weakness, the boundary geometry favours powerplay hitting). The captain-case table names the powerplay specialist as the aggressive case; the conservative case is the top-order anchor, but the desk's working rule is to default to the aggressive case when the conditions read meets the threshold.
Again, the worked example is hypothetical — it is not a real team the desk has picked, and it does not represent a recommendation. The aim is to show how the framework handles a non-trivial input: a powerplay specialist with a settled role, an opposition with a known weakness, and conditions that are unusually clear.
What if all three frameworks produce different picks?
Default to the floor framework. If two frameworks produce the same pick, use the third framework to stress-test the choice; if all three produce different picks, the conditions read is not clear enough to switch from the floor.
How do I know if the conditions read is unusually clear?
The desk's working threshold is a 70%+ confidence, which usually requires a recent pattern of conditions matches the model. Below that threshold, default to the floor framework.