Updated: Jan 16
Aside from just being an entertaining and informative talk which uses poker as a great metaphor/example for things we see in IT, my three great take-aways were these:
Using the cynefin framework to identify/be explicit about what problem you're solving:
Obvious: We know the problem and just have to apply best practice to fix it (e.g. just install something)
Complicated: Cause and effect are related and understood, but by a domain expert (e.g. speak to an accountant when building accounting software)
Complex: Cause and effect are related, but in retrospect (we accidentally built something useful in a way not intended)
Chaos: Cause and effect are not correlated and it's best to just act (get out of a burning house)
The idea is that it doesn't matter what area you're in, but just to identify where you are and act accordingly.
Created by Kent Beck, the explore, expand, extract idea is about identifying where you are in your projects: when to make lots of small little bets or experiments, when to bet big, and then upon those successes to stabilise and be more risk averse.
This was perhaps my favourite take-away. I'm currently undertaking a business analytics course at Imperial College: "From Data to Decisions", which is perhaps why this point in Mark's talk resonated so much with me.
When starting a project (or any endeavour), decide up-front what success looks like, and then act with intention. It's easy in retrospect to say "x went well" or "y turned out OK", but did that happen because of something we did, or did we just get lucky? Or conversely, if it didn't go well, how does that score with our Bayesian inference? Are there lessons to be learned, or did the law of large numbers just not fall in our favour?
I'm tempted here to get side-tracked into OKRs, but that would almost certainly blow my random references quota for this blog entry.