Game Outcomes
In a previous post, I looked at how to create successful teams, and looked at the Game Outcomes project as a useful formulation.
Some of these points are about avoiding negatives and that’s what I want to focus on here.
The most important indicators for success from the Game Outcomes project are:
- Great game development teams have a clear, shared vision of the game design and the development plan and an infectious enthusiasm for that vision.
- Great game development teams carefully manage the risks to the design vision and the development plan.
- Members of great game development teams buy into the decisions that are made.
- Great game development teams avoid crunch (overtime).
- Great gamedev teams build an environment where it’s safe to take a risk and stick your neck out to say what needs to be said.
- Great gamedev teams do everything they can to minimize turnover and avoid changing the team composition except for growing it when needed. This includes avoiding disruptive re-organizations as much as possible.
- Great gamedev teams resolve interpersonal conflicts swiftly and professionally.
- Great gamedev teams have a clearly-defined mission statement and/or set of values, which they genuinely buy into and believe in. This matters FAR more than you might think.
- Great gamedev teams keep the feedback loop going strong. No one should go too long without receiving feedback on their work.
- Great gamedev teams celebrate novel ideas, even if they don’t achieve their intended result. All team members need the freedom to fail, especially creative ones.
Confounding factors
Overtime and crunch
Deadlines are good, to a point. It helps focus. With a clear goal and a timebox it’s much easier to discard sandbags and maintain motivation. Many personal productivity schemes rely on setting yourself deadlines.
When those deadlines are too restrictive however the product will suffer. Teams will work late and produce lower quality work. They will cut corners. If time is fixed then either scope or quality or both need to be cut.
Unplanned or persistent overtime is a critical bug and needs to be prioritized as such. There’s no such thing as completely bug-free, but you should always be aiming for zero.
Mono-cultures and silos
Cross-functional teams make better decisions faster. That’s a lesson I learned the hard way. The consumer of the API should sit in the same room as the producer. Even better, at the same desk, or in the same chair.
It’s not just technology silos that cause problems. If your team is a straight cis able-bodied English-speaking white male silo, or functionally equivalent to one, then it will fail at every interface with someone outside that group. Widening your team doesn’t stop those failures, but if you manage the team properly, the failures are fixed within the team (with the goal of fixing them before the code is written) rather than experienced by consumers.
Diverse teams are also more creative.
Inter-personal conflict
Teams don’t shy away from conflict. Open discussion, even a heated one, clears the air rather than letting micro-vexations and micro-aggressions become the norm and harm the team, one papercut at a time.
Successful teams solve disagreements in the open. People first, then process after, to remind everyone of decisions made.
Punishment driven development
Feedback is great. Tracking progress is useful. But please be sure you are tracking the right thing.
I can’t say this any better than Louise Elliot, who talks about all the ways measuring the wrong thing can seriously affect a team. Video is below, but you can also listen to her talking about Punishment Driven Development on the .Net Rocks podcast, if that’s more your style.
Are you unsuccessful?
What dysfunctions have you seen in your teams now or in the past? How have you fixed them, or how will you?
Top comments (0)