A team that collectively works more hours than any other team has disproportionately higher chances of success.
Consider a typical 40 hour hackathon. Starting on Friday 5pm, and ending on Sunday 9am. With teams of 4 people.
Most typical teams would hack and sleep at their normal times.
- 5-10pm Fri = 5 hours
- 12am - 8am Sat sleep
- 9-10pm Sat = 13 hours
- 12am - 7am Sun sleep
- 7-9am Sun = 2 hours Hacking time total = 20/40 hours (50%)
Hence, average hackathon team = 20 x 4 members = 80 hours of total productivity hours
This is a rough estimate, yet already conservative. Realistically – most teams members would also have other minor commitments, take big breaks, and spend even less time hacking.
Every hour matters in such a short and intense hackathon duration. It’s similar to startups, where a week in startup time is not equivalent to a week in a corporate company.
Now consider, a team that collectively tries to go full hackathon mode. I.e. optimise to output as many productivity hours as possible. Here’s one possible schedule,
- 5pm Fri -9am Sat = 16 hours
- 9am - 5pm Sat sleep (8 hrs)
- 5pm Sat - 9am Sun = 16 hours Hacking time total = 32/40 hours (80%)
maximised hackathon team = 32 x 4 members = 128 hours of total productivity hours
Intense shit.
Insane even – when you break down the implications behind what’s happening.
This schedule implies:
- hack away at every waking hour and kill any other commitment
- to assure solid alertness and mental acuity during hacking hours by adjusting sleep schedule in advance to essentially be waking up at 5pm Fri
- 8 hour sleep at 9am - 5pm Sat, which messes up sleep schedule post-hackathon
Frankly, this is unachievable for the large majority of teams and people in general. I have never hacked with any team that could collectively achieve this.
For good reason too, most people would not see any reason or value in a hackathon to anything remotely close to this. The possible returns are often not perceived to be worth it.
For 30% more work hours in that hackathon, a team sacrifices having a sane sleep schedule before and after the hackathon, kills any other commitments, and takes on associated opportunity costs.
First, let's ask – why might a team or anyone in their right mind want to do something like this? What's the benefit?
-
Gain relative time advantage
- maximised team gets 60% more productivity time than most
- it’s not 30% more work hours from looking at how a maximised team hacks 32/40 hours (80%) compared to 20/40 hours (50%)
- it’s 80% / 50% = 160%
-
Result has disproportionate outcomes
- 60% more time doesn’t mean 60% more work is produced
- there is a synergistic effect within teams and in continuous momentum towards a project resulting in much greater that 60% better outcomes
context
I have many stories from hackathons and army about the effect of time on output. Both negative and positive.
Reflecting, it was in army that I experienced what’s possible when collectives especially maximise time output efficiently. We were often sleep deprived and operating in minimal conditions. Once we did a training exercise involving defending ground – digging trenches and sleeping about 4 hours over 3 days (I discovered it’s possible to sleep standing upright).
Coincidentally, I rediscovered its effectiveness in hackathons during the pandemic. I did virtual hackathons in the US while in Australia – resulting in many inverted timezones that led to a whacky sleep schedule. I would try to match my 3 teammates in living US time while being in Aussie time. If you invert the timezones on that ‘maximised’ schedule, it’s less far fetched to do.
Even as a single member of the team – I found that pushing my work hours could drastically position my team better. If I crafted the product usecases and scoped the features in advance, our next sync-up would be smoother. If I finished one more feature, I could then help another teammate finish theirs.
Obviously the mental acuity required for military tasks in the field and for building software products is completely different – but parallels exist, especially in the startup world.
note
- It’s impossible to convince anyone on your team to do anything like this if they are not aligned.
- And most people are not that hungry to win.
- It’s hard to convince anyone on your team to work more than they want to.
- Managing expectations beforehand is important, yet most people are bad at it.
Even if it’s just you applying this rather extreme strategy, disproportionate outcomes can still result.
Output Optimisation by Time, is a costly strategy to use. However, if the situation is worthwhile – it's powerful.
I think we already do this to some extent. When work has a busy period and overtime is common. When exam period hits. When your startup is about to die, or is thriving.