In this piece, I would like to draw some parallels between Roguelikes and agency software project delivery. These two domains share similar challenges and similar paths to victory.

The term “Roguelike” refers to games that share elements in common with a game from 1980 called Rogue. Here is a summary of what makes a Roguelike a Roguelike:

• Gameplay consists of moving through a network of encounters where you fight battles or make choices in response to random events, and gain loot or attributes that make you stronger.
• When you die in a Roguelike, you start from the very beginning of the game. Each playthrough is called a “run.”
• The room network, or “tree” is randomized each time you play, so no two runs are ever the same.

Roguelikes go way back in video game history, but here is a list of some well-received Roguelike games from the last decade:

{{Table}}

The “Type” column refers to whether the game can be slowed down to your own pace (strategic), or whether it involves dexterity, or “twitchy” gaming skills (action).

Getting good at a Roguelike involves learning the mechanics of the game, appraising a progression of chaotic scenarios, and making enough correct decisions to pass the final check: the boss encounter. Running a software project is the same, except the boss is the project launch.

One of the “furies” we mentioned earlier - Randomness - will usually be the first to come to the party. Go to the next room - what do we have? A free weapon floating in space? A client who’s a great partner and places their trust in us? Or did spiders eat our ship’s pilot? Did someone involved in the project resign? Or is this when we meet that other fury - Scarcity: you lose 25 gold, or 10 scrap, or X amount of project funding.

Did a pandemic happen?

I make this comparison, but randomness is obviously easier to manage in a Roguelike game than in real life. That spiders-eat-your-pilot scenario? Pro FTL tip - don’t ever go down to the planet for whatever the reward is, unless you’re ok with starting over. Except, if it’s the second room you’ve encountered, go for it, because abandoning the run means nothing. What I mean is, in a Roguelike game, there’s only so many of those random scenarios. If you’ve played the game and encountered it already, you know exactly what the possible outcomes are. You can get pretty good at navigating them.

I think this comfort with randomness in a game can encourage comfort in real-life randomness. I would argue that good video games provide some of the same comforts as religious rituals. For Jews and Christians, celebrating the Sabbath is about rest, food and comfort. By contrast, the ritual represents the terrifying and the incomprehensible: the act of God creating the universe. Practice of a ritual gives people a way of reckoning with the difficult matter that the ritual was created to represent. In-game RNG can be a comforting microcosm of the vast web of random possibilities that may come into play the rest of life, or as agencies and their clients work through a project.

In Roguelike games, players must optimize the way they accrue and spend various resources. In FTL, this resource is called scrap; in Slay the Spire it is gold, and so on. Occasionally, players will come to shop nodes in the room tree where they can purchase helpful items with gold, or scrap. It’s incredibly important that when you get to one of these store nodes, you have enough money to get something good. In Slay the Spire, this usually means avoiding store nodes until you have enough gold to purchase a powerful relic. In FTL, where movement is non-linear, this might mean circling a store node so that you accrue more scrap before visiting. Either way: spend your money wisely when you get to a store in a Roguelike!

In software projects, just as in Roguelikes, Scarcity will hound you every inch of the way. Scarcity wears many forms: scarcity of budget, scarcity of time, or scarcity of trust. There are ways to accrue these resources, and ways to spend them - and just like in a Roguelike, you may be able to see the points where you’ll need to spend them a bit in advance, which will let you plan. Does your team foresee that a change order will be required to get more budget? You can put some extra effort into impressing your client with good demos, etc, so that you’ll have more good will at the point where you ask for the change order.

You can also help to make sure that your team is spending budget and time on the right things. Sometimes agency leads have unique leverage by virtue of their position as outsiders to their clients’ organization. Thus, they can persuade against things like overcomplication, or building difficult, low-value features that in the long run will delay the launch and cause problems for everyone.

Despite there being Randomness and Scarcity, both Roguelikes and software projects are games of skill. While a top-notch Slay the Spire streamer will sometimes lose, they still win a thousand percent more than average, competent players. What makes the experts lose? Sometimes they blame RNG, like we were just discussing. Often though, they realize that they made a mistake.

Enter Entropy, the third fury. Entropy pushes our endeavors, incrementally but inexorably, towards dissolution. In the realms of Roguelikes and software projects, Entropy’s currency is mistakes.

When I say to people “mistakes in our industry are costly,” I often laugh. After all, we are in the marketing business. Our stakes might be profits lost due to downtime, or perhaps “decreased engagement.” But still, making the wrong call at an important decision point in a software development project can be nasty. The problem can lie dormant for a while as you architect on top of it, and then rear its head once it’s too late to restructure.

Roguelike games define themselves in making you pay for mistakes. In Hades, you could fail to dodge one large attack and suddenly it changes your whole strategy: now you need to focus your efforts on getting health, and you won’t get strong enough to beat the next boss. And in Slay the Spire, failing to draft a card that would cement your endgame, or conversely, drafting that card too early for it to be useful, can be the undoing of your run.

But as you play a given Roguelike more and more, you will learn to overpower entropy. Maybe in your first ten runs, you found your health chipped away by small encounters, and you couldn’t get past the second mini-boss. Then, on that eleventh try, you beat them. This same process may happen for the next segment of the game leading up to the third mini-boss, and so on - but as you play, you feel yourself chipping away, rather than being chipped-away at. Eventually, you beat the game.

Hades especially tries to make players see that mistakes are opportunities. The game casts Sisyphus not as a tortured soul but as an eternal optimist giving you moral support for trying to escape the Greek underworld, as do many others amongst the cast of characters. Did you fail because of a bad dodge or a bonehead room choice? It’s ok - you get an opportunity to tackle an entertaining variant of the same problem space again - you can reprise your mistakes. Roguelike game design sinks or floats based on whether at the end of a run, the player has some understanding of what went wrong and feels excited to refine, or try a new strategy.

Entropy hates strategy, and he works to make sure strategies do not materialize, or hold together for long. Often, Entropy works through his lieutenant Temptation. In Slay the Spire, the game plays a devious trick where it offers you cards that might be very good, but are wrong for a given point in the game, or wrong for the overall strategy of your deck. Drafting the wrong cards in this way can tank your run. You can see something similar in software development. At any given point, there will be voices asking you to work faster and plan less. And here’s the catch - these voices are not always wrong. In Slay the Spire, sometimes it is actually better to choose a card that is just “raw value” rather than contributing to a particular strategy. You will lose early if you pass up raw value. Watch out for this kind of hubris: that clients will allow your team to stew over plans for long periods of time without showing progress.

Mastering a Roguelike such as Slay the Spire sharpens your ability to see past temptation and balance long term vs short term success. This kind of discernment is required to deliver a software project or website successfully.

In real life, failure comes in different sizes and forms. The type of professional failure that I fear most is when something big and important that I am working on, often for a long time, doesn’t launch - doesn’t pass that final check. This kind of failure is actually pretty rare, because in professional projects, one cannot decide to restart when major flaws come to light. There is always too much at stake, so teams come together and push past the difficulties, and usually find a way to put together a launch.

Everyone has different tastes, but for me this pattern of long group struggle followed by victory is rewarding and motivating. But it is also exhausting - and every once in a while, you really do “lose the run.” One of the furies - Entropy, Scarcity or Randomness - bites off a big enough chunk to where a launch just never happens.

Another way to put it is that in software projects, failure is not clean. You or your team can commit mistakes that in a Slay the Spire run would send you promptly back to the beginning - yet still in the professional world, your run continues, your team still responsible. This is not to say that playing a Roguelike game is about perfection, or making zero mistakes. It’s more that Roguelikes hook players by offering a dual incentive: win, and you feel accomplished, or fail, and you get the reward of being able to wipe the slate clean. In contrast, the wiping of the slate is something you only get after a painful, drawn-out failure of a software project.

When one has invested in a professional project and it fails, it does not feel like a reward, or an opportunity, despite the business books that encourage us to see it as such. I actually think the business books are right to some degree, but no one with any ethics is going to feel even mostly good about the waste and other consequences that come from a project failure. Still, I think failing in a Roguelike teaches us about closure. All endeavors end at some point. It is easy to assign closure when they end in victory, harder in defeat, but still necessary. Playing a Roguelike game won’t give you an epiphany about professional failure. It’s more that these games establish rituals in which failure is one of many phases, and players realize that planning, playing, failing and winning is a cycle. In real life projects, the game lasts a lot longer, but the phases still start, end and change.

I’ve come to believe that failure is neither a Fury, nor a friend. Like Victory, Failure is a marker between things - a resting point before the next run.