Minecraft, learning and the patterns we keep repeating on Projects

I've spent decades working on major infrastructure projects. It took my kids' favourite video game to show me what good learning environments may actually look like.

About me

At work, my team at Kaleido help me to experiment, explore and develop how AI can benefit projects to improve performance and outcomes with innovation at it's core. However, by nature, I'm deeply creative and always curious about what we can learn from other industries, so I developed this newsletter to share my learning journey with others.

About this article

In a previous article I explored "What if Duolingo Was Built for Projects?" and how it could improve learning and capability on projects. This one continues with the theme of gamification but this time explores how we adults might learn something meaningful from a kids game.

Just to be clear, this article isn't a deep dive into tech - I don't think I've even mentioned AI anywhere! It's more about what we humans on projects can learn from how games have been designed and developed for the greater good.

Setting the scene

I've watched my kids play Minecraft for years. At some point I stopped half-watching and started actually paying attention because something about the way they were operating caught my eye. I started to notice their instinctive risk assessment before nightfall. Their resource planning. The way each failed approach got treated as information rather than defeat.

What I found really interesting was the quiet, self-directed problem-solving that no one had actually taught them. I then found myself reflecting on all of the professional project and risk management training that never quite produced this for me. In fact, most of my education if I'm being honest!

That thought has stayed with me for a long time because the problems I keep encountering and observing on major infrastructure programmes don't instinctively feel like problems of knowledge. For example, the risks nobody raises until it's too late, the baselines set before scope is stable, the teams permanently firefighting and never quite understanding why.

I think people know the frameworks, they've done the training and acquired knowledge but something else seems to be missing. I'm not sure a kids game has all the answers but I do think gamification done in this way might offer up some interesting questions for us to explore. That's why I wrote this article, hoping for a little inspiration!

What the game appears to be built on

Before we dive into the mechanics, let's look at the underlying philosophy. Minecraft seems to have been built on a principle that I think a lot of professional project training doesn't appear to offer or exploit effectively:

The environment can be the teacher, not just the instructor. There's no tutorial and people learn by doing. By testing, failing, adjusting, trying again. Every insight the player gains is discovered rather than delivered, and because you earned it, you own it differently.

There's also something interesting about how the game handles failure. You lose your items when you die, but not your world, your base, or what you figured out before you got there. Stakes are calibrated high enough that decisions feel real, low enough that experimentation feels possible.

It feels like this approach is intentional in the game's design. What's interesting for me is recognising the gap between a game that seems to have stumbled onto it for entertainment and an industry that perhaps hasn't quite nailed it effectively enough to land the impact it desperately needs.

I've been on programmes that seemed to get this exactly backwards. High enough stakes that nobody raised anything. Low enough accountability that nothing changed when they didn't! Does that sound familiar to you too?

Eight mechanics. Eight things that made me think.

1. No tutorial — what we might actually learn from being thrown in

As a consultant, I've regularly joined major infrastructure programmes midway through delivery. My first week involved wading through a stack of documents including the programme plan/schedule, the risk management framework, the governance structure, and of course constantly repeating the cringeworthy mandatory training (ironically the only default training imposed by most companies!).

I read most of it but not sure how much of it actually landed. Without the context of the work itself, a lot of it felt like learning a language before you've visited the country.

In those first few weeks, what I actually learned, that was actually useful, came from sitting in meetings, watching how decisions got made, noticing whose opinion shifted things and whose didn't. The informal learning and the kind of stuff nobody had written down.

Minecraft does something I've found hard to replicate in any formal training I've had. You punch a tree not because someone told you to, but because you wondered whether the world responds to you. It does - immediately and unambiguously. That feedback loop (action, consequence and adjustment) might be how learning actually works at a deeper level than we usually acknowledge.

Cognitive scientists call it the generation effect which is where information you produce yourself tends to be retained far better than information you receive. I very much doubt whether a document library creates that!

2. The day/night cycle — the risk everyone could see coming

Ten minutes of daylight. Seven minutes of night. The game seems to be calibrated to give you just enough time to prepare if you work with purpose and not enough if you don't.

The first time you get caught out in the dark, it feels unfair. The second time, you start to suspect the night was always coming, and you just didn't take it seriously enough at midday. By the third time, something shifts and you're building before you're anywhere near needing to. The threat has become a planning horizon.

Have you ever sat in a risk review where the project team identified something significant and agreed to monitor it? Three months later, it escalated. In the post-mortem, someone says "we could see this coming". Perhaps most people in that room knew it too. Maybe something about the structure of the situation meant that knowing it wasn't enough — the framing, the pace, the unspoken rule about what was safe to say.

The day/night cycle, in some way, seems to handle this because the consequence is built into the environment rather than explained by an instructor. That distinction feels really important.

3. The crafting tree — why you actually can't skip steps

Diamond armour requires diamonds ➔ Diamonds require an iron pickaxe ➔ An iron pickaxe requires iron ore and a furnace ➔ The furnace requires cobblestone ➔ The cobblestone requires a wooden pickaxe ➔ The wooden pickaxe requires wood ➔ The wood requires you to start at the beginning, with your bare hands on a tree.

You cannot skip steps, not because a rule prohibits it but because the inputs don't exist yet.

It's common sense on projects that you can't set a cost baseline before scope is stable. It's almost always a policy argument and someone explains the dependency. Someone else then decides the programme needs a number anyway. Six months later, when the baseline is wrong, there's genuine surprise in the room. This feels like the polar opposite!

What's interesting about Minecraft isn't just that the dependency exists, it's that it feels undeniable. The game simply won't make the armour if you haven't built the pickaxe, with no appeal, no workaround, no senior decision that can override it — the dependency isn't procedural, it's structural.

My suspicion is that the problem isn't visibility because most people can see the dependency clearly enough. It's that on projects we've made them negotiable, and once something is negotiable, the pressure to override it usually wins eventually. Making dependencies structural rather than procedural might be the harder and more useful ambition on projects.

4. Survival Mode vs Creative Mode — what safe training environments might be missing

"Creative Mode" gives you infinite resources, no threat, no consequence. "Survival Mode" means every resource costs effort, every decision has an opportunity cost, and the environment will kill you if you stop paying attention. Same game. Fundamentally different experience.

For me at least, almost all formal project training feels like Creative Mode. That's not necessarily a criticism as there might be good reasons for it. However, it does mean you make decisions without consequence. You produce answers knowing there's no night coming. The case study can't actually hurt you.

Then people arrive on a live programme and something shifts. The mental models they built in training start to feel inadequate — not obviously wrong, but somehow not quite enough. They've not been tested under real conditions. I've noticed this in myself as much as in anyone I've worked with. There's a version of competence that only reveals its limits under pressure, and most professional project learning programmes never quite create the pressure needed to surface that.

I don't think the question is whether the training content is right but whether there's a way to design the transition more deliberately — graduated exposure to real stakes, supervised live participation, environments that are genuinely costly but not catastrophic.

5. Redstone — what it might mean to see the system

Redstone is the game's logic layer. Wire carries signal. Lever creates signal. Piston responds to signal. Individually, each component is simple but players combine them into remarkable complexity — automated systems, logic gates, even computers built inside the game from first principles.

As a risk professional, with a keen interest in cause and effect, what I find interesting is the kind of thinking it seems to develop: not just what happened, but which signal triggered which response, and what does that mean for everything downstream?

Players who spend time with Redstone seem to stop being surprised by things that were always going to happen.

I'm not quite sure how much of that instinct can be taught in a conventional sense. On projects, the compensation event ("unexpected change") backlog that arrives on every major programme seems to shock the commercial team every time — in retrospect, the signals were usually there. The risk that escalated into a crisis because three smaller things amplified each other. Whether you see those patterns coming might depend less on what frameworks you know and more on whether you've spent time thinking in systems rather than events. Redstone might be one way to practise that.

6. Death as calibration — what failure culture actually produces

In Minecraft, death is designed to sting without being terminal. You lose your items. Your world persists. Your knowledge persists. You "respawn" back into life. Experienced players tend to talk about their deaths analytically — where it happened, what they'd been carrying, what they'd do differently. There's no shame in it — death is just information.

I've worked in programme environments where raising a "red" felt like a career risk, where people worked out quickly that "amber" was safer. Where the post-mortem was more concerned with attributing blame than learning. The project continued. The person who'd raised the problem early quietly wished they hadn't!

I don't think the people who designed those project environments wanted that outcome and suspect they didn't fully see it. However, the incentive structure produces a culture regardless of what anyone intended and the culture that emerges is probably a more honest signal about how the organisation actually works than anything written on the wall.

In Minecraft, avoiding the problem is usually what gets you killed. Surfacing it, however uncomfortable, tends to be the better move. That's a different relationship with risk than the one most programme cultures seem to reward.

My instinct is that it starts with leadership behaviour. For example, people at the top of a programme are still treating bad news as a performance problem. Creating the conditions where the right behaviour is more likely might be something organisations can actually work on, even if it's slower and harder than updating a risk register.

7. Procedurally generated worlds — what case studies might not be teaching us

Every Minecraft world is generated from a unique "seed". Same rules, different terrain, every time. You can't navigate it by memorising solutions from the last world. You can only get better at applying principles somewhere you've never been.

Project case studies attempt to teach specific solutions in specific terrains. They're useful, and I've definitely learned something from them, but they have a particular failure mode. The professional who learned their craft on a civils-heavy NEC programme and carries that mental model into a complex systems integration programme is, in some sense, running a walkthrough for the wrong world.

The crafting recipes are the same in every world. Wood always makes a pickaxe. The principle transfers but the specific solution from last time often doesn't. I'm not sure we're always honest about that distinction, about which part of our expertise is recipe and which part is map-memory for terrain we won't see again. Good project learning probably needs to be more deliberate about building adaptive capacity rather than reproducing solutions from a specific context and hoping they travel.

8. The inventory constraint — 36 slots, and what that might mean for attention

You get 36 inventory slots. Every item occupies one, regardless of value. Every expedition requires genuine choices — what to carry, what to leave, what this particular trip actually needs. Players who don't manage this end up over-encumbered, making poor trades, occasionally dying because they couldn't act when it mattered.

I think about this whenever I look at a programme RAID logs (Risk, Assumptions, Issues and Dependencies) with hundreds of risks on it! Or when I watch project leadership teams sit through a two-hour review attempting to navigate a mass of reporting content. There's something that feels like attention in that room, but I'm not sure it is. Human working memory has real limits, perhaps a small handful of things it can hold in genuine active attention at once.

Many situations I've come across don't seem to account for that. They grow, things get added, but the question of what anyone can genuinely hold and act on doesn't tend to get asked. The consequence, I suspect, is the same as in the game — not dramatic failure, but a slow drift towards the loudest signal rather than the most important, and a gradual loss of the ability to tell the difference.

What I think this might mean

When I try to draw this together, I arrive at about five things — though I'd hold them tentatively, because mapping a video game onto professional development is a move with obvious limits.

1. Consequence probably needs to be immediate enough to feel connected to the decision: The feedback loop in most project learning is months or years long. By the time you find out whether the decision was right, it's hard to reconstruct what you knew when you made it, let alone what you were feeling. Something important gets lost in that gap.
2. Complexity might need to be earned rather than front-loaded: The game introduces Redstone only after you've spent time with stone tools. There's often a lot handed to people on projects early with complexity that probably takes months to make sense of. I wonder whether the struggle to absorb it gets read as a capability problem when it might just be a design one.
3. The project environment might need to do more of the teaching: Minecraft never explains that you need food. It makes you die slowly if you ignore it. I don't know how to fully replicate that in a development programme but I'm sceptical of approaches that move all the learning into content, strip it of context and then expect it to transfer back.
4. Failure probably needs to be survivable enough that people will risk it: When failure is rare and catastrophic and politically charged, people stop taking the risks that might surface it. The culture you get is the one your incentive structure produces which may or may not be the one you wanted.
5. Agency might matter more than we tend to assume: In Minecraft, you build what you decide to build. In most project learning, the programme is someone else's. Self-Determination Theory suggests that makes a real difference — not to whether people complete the learning, but to whether they internalise it. Compliance without internalisation is a particular kind of failure that's quite hard to see until it matters.

I want to be clear about what I'm not arguing. I'm not saying that the content of what we teach is the main problem. The content is often fine but the question may be whether the architecture is.

Minecraft seems to have figured out something about learning environments that project professional development has been trying to design deliberately for decades, with mixed results.

Unfortunately, I'm not offering a blueprint, silver bullet or solution but here's what I'd actually suggest, for anyone responsible for developing project capability in their organisation:

• Stop asking whether the training content is good enough. It probably is.
• Start asking whether the learning environment has consequence, progressive complexity, and genuine agency built into it — not as features of the programme design, but as structural properties of how people are developed over time.
• That means less classroom, more supervised live exposure.
• It means creating the conditions where failure is survivable and analytically useful rather than politically charged.
• It means being honest about the difference between knowing a framework and having actually used it under pressure, and designing development pathways that close that gap deliberately rather than leaving it to chance.

None of that is easy, and none of it is quick but I think it's closer to the right problem than most of what gets discussed when organisations talk about building project capability.

The architecture is the thing and until we take the architecture as seriously as we take the content, I suspect we'll keep having the same conversations — on projects, and in the rooms where we try to prepare people for them.