Making Live Poker Faster: Shot Clock

A suggestion that has been put forward by a number of players is to introduce so called shot clocks that limit the time a player has to make a decision. Whilst a good idea in theory there are many negative externalities of this potential ruling. If a player has 30 seconds to make every decision or heaven forbid 60 seconds then players are likely to use a large amount of this time even when faced with simple decisions. Not taking the relevant time could provide a timing tell to opponents and so many will be loathe to make quick decisions.

Should a person have the same amount of time to make a decision when the first to act compared to facing a bet for their tournament life? Should a player in the first hand of a tournament have the same time limit when on the final table in a tournament of over 5,000 entrants?

The clear answer to both of these questions should hopefully be no. This leads us to create a situation dependent shot clock. Shot clocks could start at 20 seconds until the average stack reaches 50bb, it could then increase when the average stack is down to 40bb and so on.

A situation dependent shot clock would be a fantastic way of preventing slow play but would be extremely difficult to implement. Players would need to be made aware at all times what the shot clock is and new players would be under even more pressure as they would have to factor this in as they play their first tournament.

We could end up driving away the players that we are trying to encourage in the first place by adding even more external pressures that for experienced players would seem trivial but for newer players can be intimidating.

The implementation of a shot clock is like using a bomb to kill a fly, it is an unwieldy blunt force that has far reaching implications and can cause untold damage to the game we love. So probably not the best route to take!

Advantages:

Guaranteed time limit on each player’s action

Disadvantages:

Blunt instrument that would require situation dependent rules which creates implementation issues

Non-intuitive so adds pressure to inexperienced players