Why Building Software Is Like Leading an MMO Raid

A few years ago, if you'd told me that thousands of hours leading MMO raids would end up helping me build software products, I'd have laughed.

Today I'm not so sure.

I've spent years leading raids in games like Star Wars Galaxies and Star Wars: The Old Republic. What surprised me is how often the same lessons show up when building software.

The technology changes.

The tools change.

The jargon changes.

But the principles?

Not so much.

After building products, leading teams, surviving deployments, and spending more hours than I'd care to admit staring at architecture diagrams, I've realised that software development and MMO raid leadership have far more in common than most people think.

---

Most Wipes Are Self-Inflicted

One of the first lessons every raid leader learns is this:

Most wipes are self-inflicted.

Not every wipe.

Not all wipes.

But most of them.

The boss usually isn't the problem.

The raid wipes because:

• Somebody got greedy
• Somebody ignored the mechanic
• Somebody panicked
• Somebody thought they could improvise

Software projects are exactly the same.

Most projects don't fail because the technology was impossible.

They fail because:

• Requirements weren't clear
• Priorities kept changing
• Validation was skipped
• Scope grew uncontrollably
• Assumptions went unchallenged

The technology rarely kills the project.

The team usually does.

---

Don't Pull Extra Mobs

This one has become a genuine software development philosophy for me.

Every MMO player knows this moment.

The group is making steady progress.

Everything is under control.

Then somebody says:

"While we're here..."

Five minutes later you're fighting three extra packs, the healer is out of resources, and half the raid is dead.

Software development has exactly the same trap.

You're implementing a reporting feature.

Someone says:

"While we're here, we could also..."

Then suddenly you're discussing:

• New dashboards
• New permissions
• Notifications
• Analytics
• Exports
• AI summaries

Congratulations.

You just pulled extra mobs.

One of the most useful questions I've learned to ask is:

Does this solve the problem we're trying to solve right now?

If the answer is no, it probably belongs in the backlog.

Finish the current fight first.

---

Do The Mechanic

Every raid eventually has that player.

The one topping the damage charts.

The one doing incredible numbers.

The one who dies first because they ignored the mechanic.

The mechanic doesn't care how talented you are.

It doesn't care how much damage you're doing.

If you don't do the mechanic, you're dead.

Software projects have mechanics too.

Things like:

• Architecture reviews
• Testing
• QA
• Security checks
• Deployment validation

Nobody gets excited about them.

Everybody wants to write code.

But the mechanic still needs to be done.

The teams that survive long term are usually the ones that respect the boring parts.

---

Don't Stand In Fire

Another timeless lesson.

There is always fire.

Sometimes it's literal fire.

Sometimes it's:

• Hardcoded secrets
• Direct production database edits
• Skipping tests
• Ignoring warnings
• Undocumented architecture

Everybody knows it's dangerous.

People still stand in it.

Repeatedly.

The lesson is simple:

If something has already burned you three times, stop standing there.

---

The DPS Meter Lies

One of the most underrated lessons from raid leadership.

The highest DPS player is not always the most valuable player.

Sometimes the most valuable person is:

• The healer who prevented a wipe
• The player handling mechanics
• The person explaining strategy
• The one spotting problems before they happen

Software teams work the same way.

The most commits don't necessarily create the most value.

The engineer who prevents a production outage may contribute more than the person who writes thousands of lines of code.

The person who simplifies a system may create more value than the person who adds five new features.

Not all contributions show up on the meter.

---

Wait For Loot

This might be my favourite lesson.

The boss dies.

Everyone gets excited.

Then the raid leader says:

"Wait. Don't loot yet."

Usually because:

• Loot rules aren't set
• Someone is still running back
• A screenshot is needed
• Something still needs checking

Good raid leaders don't sprint to the next boss the moment the current one dies.

They stop.

Review.

Recover.

Then move on.

Software projects should do exactly the same.

A feature ships.

Great.

Now:

• Test it
• Monitor it
• Validate it
• Learn from it

Only then start the next thing.

Too many teams treat deployment as the finish line.

It's usually the start of the learning phase.

---

The DPS Hero Is Usually The First To Die

Every raid has one.

The player convinced they're the main character.

The one who thinks mechanics are for everyone else.

The one who says:

"I've got this."

Thirty seconds later they're face down on the floor.

Software projects have these moments too.

The engineer who insists:

• Documentation is unnecessary
• Testing is optional
• Architecture reviews are bureaucracy
• Deployment checklists are for other people

Often ends up discovering why those things existed in the first place.

Usually in production.

Usually on a Friday.

---

The Boss Usually Isn't The Problem

This is probably the biggest lesson of all.

Most of the time, the boss isn't what kills you.

It's everything around the boss.

The lack of planning.

The lack of coordination.

The avoidable mistakes.

The unnecessary complexity.

Software projects are no different.

The technology challenge is often only a small part of the problem.

The bigger challenge is usually:

• Focus
• Discipline
• Prioritisation
• Communication

The boring stuff.

The raid-leader stuff.

---

Don't Touch Anything, I Forgot To Set Random

If you've ever led a raid, you've probably said something like:

"Don't loot yet. I forgot to set random."

Everyone freezes.

Nobody touches anything.

Because everyone understands that a tiny process mistake can create a much larger problem.

Software has these moments too.

They're usually disguised as:

"Don't deploy yet."

"Don't restart that."

"Don't touch production."

"Wait, I forgot to update the environment variables."

The principle is the same.

Slow down.

Verify.

Then proceed.

---

The Best Raid Leaders Aren't The Best Players

This took me years to understand.

The best raid leaders aren't necessarily:

• The most skilled
• The best geared
• The highest DPS

They're usually the people who:

• Stay calm
• Keep everyone focused
• Prioritise correctly
• Reduce unnecessary chaos

The same is true in software.

The best technical leaders aren't always the smartest people in the room.

They're often the people who stop the team from creating problems for themselves.

---

Final Thoughts

After years of leading raids and building software, I've ended up with a surprisingly simple development framework:

Do the mechanic.

Don't stand in fire.

Wait for loot.

Don't pull extra mobs.

Most wipes are self-inflicted.

It's not a bad framework for software development.

And honestly, it's probably saved me more projects than some of the formal methodologies I've used over the years.

Although it's admittedly harder to explain during architecture reviews.

Then again...

The longer I build software, the more I think good architecture and good raid leadership are really the same thing.

Reduce unnecessary chaos.

Focus on the current objective.

And for the love of all that is holy...

Don't pull extra mobs.