Lately, I’ve been thinking a lot about my position as a digital producer here at DevelopmentNow. I enjoy consuming a client’s complex systems and design decisions, then translating them to our developers, ensuring that the grand vision for a product meets both expectations and budget. I’ve also recently started playing a game of 5th Edition Dungeons & Dragons with my friends, with me as the Dungeon Master (DM), or Game Master (GM) in some circles. In this role, I’ve had a lot of fun researching a campaign setting to build my story, as well as working with my PCs to establish their goals, motivations, and how they fit into the world at large.

With both my producer tasks and DM duties occupying my mind at once, I’ve come to realize that my enjoyment from both my profession and this hobby stem from the same tree! Both have me researching deeply into a subject to better understand it, using what I’ve learned at a technical level to achieve creative solutions, and then plan towards an end goal while keeping current events within the production in mind.

Studying Information Systems and Business Logic

We even have death pinned down to a process

Whether the project starts from a pre-existing foundation or is being developed from the ground up, our Discovery process makes sure that we have a deep knowledge of the system at large, including the information within it, and how it affects those who interact with it. This means we’re usually asking questions like “How does this information originate?”, “What does someone (Business, User, etc.) do with it?”, “How does this fit the overall goal of the product?”, and so forth.

A producer’s role in this process requires coordinating and communicating with multiple teams to ensure that everyone has equal awareness and understanding of a project’s goals and how to achieve them. Producers use this knowledge of the system and the overall business goals to help remove blockers and provide oversight to teams.

For DMing in DnD – and any form of storytelling, honestly – you have to understand the rules of your world. This matters even if you choose to break those rules time-to-time for the sake of the adventure. This also goes for the rules of the system you’re playing within, such different editions of DnD or other roleplaying systems like Pathfinder. These rules save your PCs from having to relearn how to interact with the world moment to moment – constant rule reinterpretations can make it really hard for a committed player to stay invested in your story.

This is especially important when your PCs have all agreed to a common goal and have started acting upon it. You can help give direction on how the group can further their goals, providing they roll sufficiently. With this, you also get to add great plot considerations and developments to the game, like “How exactly can they go about cursing the land?”, “Who is cheering this group on, and who is trying to stop them?”, “How could someone manipulate the group to achieve their own ends?”

Bridging Creative and Technical Concepts

Product Owners, Designers, and Developers working as one powerful chimera

Product owners, designers, and developers can come into conflict when trying to interpret an abstract concept and translate it so they can all agree upon and understand. I like to compare well-written tasks/stories to a Rosetta Stone of sorts – there’s a section for each team to understand how a feature will be achieved. Product Owners get what business goals are met, designers get what experience is being implemented and how, and developers get API specs mapped and logic flows outlined.

A producer needs to maintain a stable, constant understanding of what is to be accomplished with every task/story. While they may need to shift the language and terminology they use when communicating across teams, something shouldn’t be lost in translation just because a creative term common for designers doesn’t have an exactly comparable term on a technical level for developers. The producer is the bridge between all players – communicating effectively across teams to maintain a stable, constant understanding of what is to be accomplished with every task/story.

Luckily, DnD provides a pretty good common ground by asking “How well did you roll (on your dice)?” This applies to the concept of Nat-1 or Nat-20, relating to what you rolled on a 20-side dice. If you roll a 1, it’s a Natural 1 (Nat-1), you’ve critically failed whatever you were trying to do, while a 20 (Nat-20) means you’ve critically succeeded. When these happen it’s usually a high point in the adventure, where a lot of flavor can be added into how well or poorly a PC just performed a task.

But while a good roll can be a definitive fail/success metric for a player’s actions, a DM will often need to be clever when trying to determine how to allow the PCs to do something risky or outrageous. That’s the nice thing of when you have a good understanding of the game rules and can compare them to world/story rules. You’re turning game rules into a creative experience, so people can focus on having fun in the adventure, and are on board with how to proceed. You wouldn’t think you’d need to have on hand rules and stats to determine how a player can perform a suplex on another player, but your PCs will surprise you.

Planning Ahead Using the Present as a Guide

So… Fist of Five from everybody on this orc ambush.

Project managers are always looking for ways to keep a team productive while maintaining a realistic course for completion. For those who employ agile and scrum methodologies, this is usually done by tracking completed point totals over a series of sprints. For a lot of our projects, we use this to set realistic point totals for future sprints. We adjust with each completed sprint, with the goal of seeing this value increase with each new sprint. Sprints for us last for 1-2 weeks, depending on what time is given to the project.

The advantage this has over waterfall-style development is that you can see how well a team is performing in real time. You can then make calls on how to adjust things, so that the project gets done on time and on budget, without the stress of waiting until the end to see how everything went. Often as a producer, my role is getting an idea from multiple teams on how they feel the project is going – what’s good, what’s bad, what can we do about it.

I do the same with the PCs in my game, so I can tell if I’m moving the plot in ways they find interesting and want to invest time into. This is because, the game – and again, maybe any form of storytelling – is not about forcing characters through a plot; disregarding their wants and desires. A good story is about the characters’ reactions to events as they unfold, and how they affect things through these reactions.

This doesn’t mean you have to completely abandon an aspect of your story just because the characters take a different route than you planned. If it’s important enough to you and the story you want to tell, it’s an opportunity to find a creative way to introduce it into the story. But like anything agile, you’ll need to be ready to pivot.

Conclusion

Having a hobby and being able to examine why you enjoy doing it can give some surprising insight on why you enjoy aspects of your professional career. You get to step out of a role and explore another side of things. You’ll get a better sense of what your strengths are, and as you get better at your hobby, you’ll find that the experience (XP) you gain from it will improve your work as well.