Engagement, accountability and decisions

Revolutionary thought: people who don’t care, develop worse games. People who don’t feel responsible, care less. People that don’t make decisions, don’t feel responsible. 

Symptoms

Agile based methodologies put a lot of emphasis on dev teams taking ownership over their process but also small product-related decisions. They assume that people who are experts in their own, narrow field, are the best people to decide how to implement required features and provide value to the end user. In game dev, it’s even more important: there is no client that can make definitive decisions about the shape of the product. Instead, the whole experience is a result of work of specialists from many different fields. Designers, programmers, artists, QA: they all have to provide their expertise to make the game fun in all aspects. They also know best what tools and what workflow they need to accomplish these goals. 

Most studios claim to work in some form of agile framework. I call it bs. In almost all dev studios I’ve worked with, there was some magical source of decisions coming from above. Infuriating devs and sucking all engagement and fun from the creative process. And the more petty and unimportant for the final product these decisions are, the more frustrated people become. Let me give you some examples.

• In studio X I was part of a big R&D project, lasting for several months. Team of roughly 10 people. At the end, we started preparing conclusions and findings from the research. To our surprise, we found out one day, that our producer already compiled his version of the project outcome, drew his own conclusions and presented it to the rest of the company. We weren’t happy. 

• In one team, technical artists established a workflow with programmers to produce some type of features. It was born of necessity, came up completely naturally and was working fine. At some point, a producer who was supervising this team, decided that this flow should be different to improve “transparency”. He came up with new types of tasks in jira, a few additional meetings a week and a whole new, complicated process. Artists lost direct contact with programmers, instead of quick 5 min talks all communication went through jira and additional acceptance steps. Production time doubled. 

• Another team wanted to use a different tool for managing internal documentation. They researched several options, chose one of them. When they presented it to the management team, they found out that they can’t use it, because the studio already paid for the solution they were using and other departments would also have to switch. So devs quickly stopped fighting against the inconvenient tool and just ignored documentation altogether. Not good.

• Not enough? Several times I’ve seen POs that would come to every sprint planning and basically assign tasks to all the team members, one by one. Always completely resetting the state of the current tracking board. Very soon, the team gets so apathetic and indifferent, that they would just ask for as little as possible, often close tasks that are half done and lose any sense of ownership. They know that even if they bring up some tech debt related issue or other side problems, they will get lower priority than what PO already has in mind.

• In one studio, a game director would sometimes decide to change design assumptions about features that were already in progress. Basically resetting several days or weeks of work for a few people, that agreed on the best course of action. I know this example is a bit extreme but it’s real and I heard about very similar cases in different studios. Guess how devs feel in such a situation? 

Reading these examples you can easily say “Oh, you certainly shouldn’t do THIS”. But the issues can be much more complicated and convoluted. However, in all of these cases, there is one common root cause. Decisions are made at the wrong level, by people who should instead push ownership down the structure.  

Can it be that simple?

Potential pros of pushing ownership down the structure are quite obvious but lets name just a few for the sake of example:

1. People who make decisions about things they work on everyday, get much more attached and invested. So they are less likely to leave the company and literally put more work into the product.

2. But because they make decisions, they also feel more responsible. They care about the quality much more.

3. Devs that work in the industry for some time, are not idiots. They know exactly what workflow and what tools they need in a specific situation. It’s much more likely that they know that than a producer or a PO who oversees a much wider domain.

4. Efficient and healthy studios require strong accountability. The closer decision making is to the execution, the easier it gets to assess decisions and find issues. Blame shifting becomes impossible. 

5. If a decision needs to be based on information that is originally created in the dev team, the farther the decision maker is from the team, the more distorted input he will get.

6. If a manager has a last word about 8 different areas, he is much less likely to make good decisions and change them if a better solution appears during the development. 

Ok, so what are the potential risks of going too far the other way?

There is a reason why producers / POs / managers like to make and own decisions by themselves. It lets them control the choices made, have better transparency for the higher ups, avoid total chaos. If everybody on the team makes decisions on their own, there is a very real risk of communication problems, different parts of the project being dragged in opposite directions. Personal agendas of particular devs can take over and the common goal is lost. 

A suggestion

So what should be the role of a manager in this aspect?

There are 3 main responsibilities of a manager that are important to make sure the project keeps going in the right direction and chaos doesn’t take over:

1. Facilitate decision making - highlight issues and problems that need a decision, make sure that a decision is made and communicated to everyone involved. This also includes making sure that one topic isn’t discussed over and over again when different people try to change it too often with no valid reason.

2. Communicate project goals and priorities during the decision making process - Pose hard restrictions that come from the management. Make sure that people who decide how to solve problems, actually work towards improving the final product or the development process. In the end, managers can veto glaringly bad decisions. 

3. Manage accountability - Oversee if the decisions made are followed and implemented. Make sure that they have a positive impact on the project. Create an environment that supports devs ownership. Praise good execution and highlight issues of bad execution. This assessment should be done on the result of the decision implementation, not on the personal view on the decision itself.

Oversee and guide, don't order. 

There is one more issue that you can see in this model. On one hand decisions should be as public and transparent as possible, ideally made by a team and not by one person. On the other hand, I’m talking about accountability and ownership. Also for the sake of communication it’s important to have one, decisive voice that can clarify any details, implications and impacting factors. So how to connect these two? Ideal scenario is that a closest team makes a decision as a group. Then, they choose a most interested mid+ dev (avoid assigning too many issues to a lead by default) that will be an owner of this decision. The herald of change. It doesn’t mean that he needs to be the one that implements all of it and gets fired if anything goes wrong. But he should understand the problem and be able to defend the choice in the name of the team. 

Why is it so important to have a person publicly responsible? 

Let’s say I’m a dev. I found out that there was a decision made by another team about some aspect of the game. And I don’t like it. There is sth seriously wrong about it in my opinion. If I can't easily find anyone to talk about it or I hear that “management” decided that, it’s really bad. The studio could have just lost a chance to avoid a huge problem. But if with every major decision I get a name attached to it, I can quickly ask a question. Get convinced that the decision is actually good or convince the person responsible, that there is an issue and it needs to be discussed again. In both cases it’s a win. People don’t work well if they feel that there is sth wrong with the project and they don't see an easy way to change it. Sometimes a similar philosophy can also be applied to work organization / studio decisions but it’s a separate topic.  

Implementation

This philosophy to decision making can be implemented in many different shapes and forms. People can present new decisions on weekly meetings, during milestone presentations or on a dedicated slack channel. I would argue however, that in bigger (20+ people) and longer projects (2+ years) some form of a Decision Log is very useful. It doesn't have to include all the decisions, just the major ones. Think about it as an internal GDD that grows during the development, that includes details about implementation and workflow (as well as parts of design). Things that I find useful in such document include:

1. Decision summary

2. Reason for the decision (short points)

3. Owner

4. (Optional) Alternatives that were discarded and why

If there is an owner, reasons and alternatives don’t have to be very detailed, you can always ask. 

One last anecdote: I once worked in a veery big studio that needed to decide their approach to several technical issues in a new project. One of them was the usage of blueprints in UE5. Very common problem. Every project using UE5 needs to somehow make this decision. Me and 2 other programmers spent quite some time on this topic, researching, testing, doing lists and presentations. At the end we created a set of recommendations that were accepted by the studio (so far so good, people working on a thing make an informed decision). The problem was, everytime a new programmer came in, or a manager changed in one of the teams, the subject resurfaced. People who had no idea about the topic tried to answer the same questions again and again. Sometimes coming to the same conclusions, sometimes changing everything for the whole studio. There was no documented solid decision, no owner that would be the ultimate responsible authority on the topic. No one to say “no, we already made this decision, let’s stick to it”. Lately I heard that they still struggle with rules around this subject. It’s been 3 years.