The hackathon mindset
As many other tech companies my employeer also arranges a couple of them per
year. During this year’s hackathon I had one of those aha! moments, where things
fall into place and you see something from a different perspective and with a
better and stronger understanding. My aha! moment was about how we, humans, are
terrible at measuring the effort involved in anything that takes more than a few
days and how that affects our work. Let me give you an example.
In the hackathon we are given two or three days to build and show something.
Because we only have a handful of working hours to do some research, code and
present, we first collect the work to be done and prioritize it. And, at least
in my experience, we make “hard calls” pretty quickly and without second
thoughts. We prioritize ruthlessly. And, also in my experience, hackathon teams
tend to make the right calls when cutting scope and focusing on what really
matters.
So why are we apparently so effective during the hackathon but we miss the mark
in our day to day activities? In my humble opinion it’s because we, humans,
really suck at comprehending time. If you ask me “how long is it going to take
to build feature X?”, I’ll go do my duty of decomposing it into big blocks,
estimating each, to finally give you an estimate. A wrong estimate.
Anyone who has estimated some work at least a few times, knows that the further
ahead one plans the less accurate the estimates are. You can add a massive
buffer to not miss the deadline, but at what cost?. What matters is that we were
slow building something for our users to use.
Things would be different if instead you asked me “how long is it going to take
to build feature X?” and then added “but you only have 1 week”[1][2]. After
recovering from the shock, it would be clear to me that to build something
resembling X I would have to drop things (functionality, scale, dx, etc.) and I
would make those calls without second guessing my decision. It would be clear to
me that it’s impossible to do otherwise, the tough time constraints would
squeeze out the “maybe”s and the “we need this” (when we don’t) and the “let me
find the perfect solution” tendencies.
I now realize that most of my planning and estimating mistakes are caused by
myself, because I trick me into believing that I can do much more than what’s
realistically possible in some amount of time T. And that happens because I
can’t comprehend what weeks or months worth of effort really are. When I reduce
the time I have, it’s crystal clear that many things have to be dropped[3] and
we need to ruthlessly prioritize.
This ruthless prioritization of work to be done is what I call the “hackathon
mindset”
By writing this I’m not saying that I would apply this mindset constantly. I
don’t think it’s the only “tool” that we should use. It’s a good mindset to get
projects started, collect feedback early and do several iterations like this.
But after a while there must be time to reflect on what has been learned,
revisit the direction/goal, improve the quality of code that’s foundational for
what comes next, do technical or customer research, etc. We run to get first to
the market, we slow down to secure that position.
The estimation error is exponential. Each day added to a plan increase the estimation error because more unknown unknowns can happen ↩︎
I’m using 1 week here as an example. It could be a bit more, but not more than 2 weeks. ↩︎
If you have 0 idea where to start this won’t work in any way. You have to have done some research about the topic and understand what type of work to be done to at least know what things can be left out. So that’s a requirement, but you can apply the same mindset when doing research. ↩︎