I watched the video. The opinion of the former employee gels with more junior employees I’ve worked with in the past - typically the perspective of devs who aren’t privy to the decision-making process and lack the kind of context that’s needed to understand the costs and benefits to the choices made. Here are a few specific thoughts I had on the various topics mentioned in the video.

Contract workers are often treated quite badly in our industry, especially those in QA. Contractors are the first to be let go, get little or no benefits for working, and are generally hired on through shell companies in order to protect the actual employers from liability. It’s an unfortunate situation that’s arisen from our legal system and extends far beyond the game industry.

Disagreeing with a major design decision like art direction is not at all uncommon. Leadership takes the responsibility on that one. I will be the first to admit that I’ve had my share of times where I disagreed with leadership and was right, as well as my share of times where I was dead wrong. I look back at the latter as valuable learning experiences.

I can tell that the person being interviewed doesn’t really understand business because they’ll say something vague about “record breaking profits” at the corporate level, but no solid information at any level below that. It doesn’t matter that the overall company is profitable or not - each product that is developed still needs to justify its own existence via its accounting.

The pandemic, work from home, and return to office policies have affected the industry as a whole in many large ways. Publishing leadership sets the policy for the publisher, and studio leadership sets policy for the studio. My own publisher had different studios enact wildly different policies for work from home and return to office - one studio required all employees return to the office full time, while another only required two days per week.

It sounds like WayForward’s engineering team and workflow faced a lot of challenges they had a hard time overcoming. I don’t know whether this is because their team was shorthanded, lacked strong leadership, or just was always on the back foot and never able to stabilize due to a never-ending series fires that needed putting out. When everything is constantly on fire, it’s extraordinarily difficult to get ahead. Remember, all tasks get prioritized. Fixing crashes is more important than adding new features like multiplayer or new units - crashes stop other dev team members from working, so the effect is multiplicative. I suspect that this was the root problem that caused the rest of the development to get caught in the development hell it sounds like.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

• Short questions: Ask a Game Dev on Twitter
• Long questions: Ask a Game Dev on Tumblr
• Frequent Questions: The FAQ