Why Mainframe Work Should Feel Like a Good Game

I was talking to a mainframer the other day—let’s call him Dave.

Dave has been in this business for longer than some of his teammates have been alive. He remembers punch cards. He remembers when someone accidentally deleted a dataset and nearly took down the entire payroll system. He remembers when the only way to debug a problem was printing out thousands of lines of logs and physically flipping through them.

But most importantly, Dave remembers when work was fun.

Not because it was easy. Not because the pressure wasn’t there. But because even when things went wrong—even when everything broke spectacularly—there was a sense of engagement, challenge, and camaraderie that made it all worth it.

And for some reason, that conversation reminded me of a podcast I had recently listened to, where Mark Rosewater, head designer for Magic: The Gathering, talked about how great game design makes losing fun.

It’s an odd idea, at first. How do you make losing fun? Isn’t losing… just losing? But as I listened, I realized he was talking about something far bigger than games.

He was talking about engagement, resilience, and motivation. And suddenly, it clicked:

The best mainframe teams—the ones people actually want to be in—operate a lot like a well-designed game.

Because if work feels like a grind—like an endless, monotonous task where mistakes are punished, progress is invisible, and bureaucracy kills momentum—then people disengage. They stop caring. They start counting down the days until retirement, or worse, they leave before they ever get a chance to see why this job can be so great. 

But when work feels like a challenge worth taking on, where even the hardest problems are engaging, where failure isn’t the end but part of the process, where there’s a sense of camaraderie and creativity—that’s when people stay.

That’s when they care. That’s when, even at 2 AM in the middle of an outage, they’re still invested in what they do.

So what makes the difference?

Let People Play the Game

The best part of a game is playing it—not watching someone else have all the fun.

Dave still remembers his first real project, back when he was the junior guy on the team. His manager handed him a corrupted dataset and said.....“Fix it.”

No training course. No step-by-step guide. Just figure it out.

It was terrifying. It was frustrating. But it was also the moment he fell in love with this work. Because every minute spent hunting through hex dumps and error logs, every mistake, every wrong turn—all of it was progress. He was playing the game, learning by doing, not just watching someone else do it.

But these days? He sees too many junior engineers stuck on the sidelines.

“Watch and learn for now.”

“We’ll let you handle real systems later.”

“Read the documentation first, then we’ll see if you’re ready.”

By the time they finally get to touch the system, they’re already halfway out the door.

The best teams—the ones that keep their people—don’t treat mainframe work like an exclusive club where only the senior folks get to actually do stuff.

They throw people in. They let them struggle (but support them when needed). They give them real work, real responsibilities, and real opportunities to mess up and learn.

Because people don’t fall in love with work by watching.

They fall in love by doing.

Keep the Work Moving

You ever played a game that just drags on forever?

A round that should’ve been ten minutes stretches into an hour. You’re stuck waiting for the next move, watching the same slow, predictable patterns repeat.

That’s what a bureaucratic team feels like.

Dave still remembers the old days, when his team needed to roll out a new feature.

Someone had an idea—maybe an automation script to speed up a process, or a tweak to a job that would cut down processing time. They’d write it, test it, review it over a quick discussion, and deploy it within a few days. If it worked, great. If it didn’t, they’d roll it back and try again.

Today? That same feature would take months.

First, there’d be a pre-meeting to discuss whether the idea aligns with company objectives. Then, a second "stakeholder alignment" meeting to get input from leadership. 

Then, a formal proposal that needs to be submitted, reviewed, and approved by at least four different teams.

Then, a change request process to schedule the actual implementation.

Then, maybe— just maybe—if nothing else gets in the way, the team actually gets to build and deploy it.

And some people have the nerve to call this “Agile.”

Somewhere along the way, the idea of “move fast, iterate, and adapt” turned into “schedule a meeting to discuss whether we should schedule another meeting.”

By the time a feature finally makes it to production, the spark of innovation is gone. The person who had the idea stopped caring months ago. And the process that was supposed to make everything more efficient has turned into its own miniature waterfall nightmare.

Games are designed to flow, to create a sense of progress, movement, and urgency. Great teams do the same.

They trust their people to make good decisions. They move fast when fast is needed. They don’t bury simple improvements in layers of red tape.

Because nothing kills enthusiasm like waiting.

Why This Matters

Mainframes don’t make mainframers stay. Other mainframers do.

So how’s your team doing? Are they playing the game, or just watching from the sidelines? Are they making real progress, or stuck in an endless cycle of meetings? Are they engaged, challenged, and enjoying the work—or just counting the days until they leave?

A great team isn’t just one that gets things done. It’s one that makes people want to stay, grow, and play the game for years to come.

Written by Henri Kuiper