Opinion: The TechCabal

[In this reprinted #altdevblogaday-opinion piece, Yager Development's Andre Dittrich explains the usefulness of having a TechCabal in large teams, and describes the functions and make-up of such a group.] I am a member of the TechCabal. Usually this does not involve any arkane rituals or strange outfits. We are a group of higher ranking technical guys that guide the project on the technical side. How and why did we create this group? Once a team reaches a certain size some decisions cannot be made directly by the people in the trenches doing the work anymore. This lesson usually is learned the hard way when a team grows from a small developer to a full AAA project team like we did. The easy direct lines of communication one is so used to, simply do not work anymore. People need to step up and start leading and leading means making decisions. So either you hire some experienced leads or you promote people from the midst of the team to lead them now – Problem solved! Problem Solved? The team grows further, the decisions become bigger. You start to create more specialized teams: a gameplay development team, an AI development team, a performance/console team, a technical art team, a build/tools team… Now you have decisions and problems that are bigger then any of these specialized teams, and you also need to coordinate these teams somehow. What Now? Another lead, a lead for the leads! Now that person makes all the really big decisions and handles the coordination, an enormous amount of responsibility for a single person, a lot of pressure. That person, by pure necessity and time limitation, would be pretty much removed from working the real metal, from the trenches of the actual development. We still would like to have him have all the knowledge that you get by working in the trenches to have his decisions be properly influenced by it. Maybe we could find some kind of uber-genius for that. Me personally, I do not believe in the uber-genius that can fill such a role, or at least I have not met such a person, and even if it would exist, you would need at least two for your team because even an uber-genius needs to take vacation or will be sick. To me this means we have to find a different solution. Our solution to the problem is the TechCabal. So, What Is This TechCabal? The TechCabal is a group of tech guys that meet at least once a week to discuss the current technical issues and questions of the project. These questions range from questions of coordination of the different technical groups of the team to making far reaching technical decisions. I have to give the credits for this idea to where they belong. Hendrik, our technical project lead, came up with that idea, and together with him the members of the group shaped it. Currently the TechCabal includes the technical director, the technical project lead, the lead programmer, the lead technical artist, and the heads of the gameplay and performance/console programming teams. Instead of relying on a single very great person, we share the responsibility for the big and not so big technical decisions among this group. When we discuss in this group we try to keep title and rank outside. We try to discuss absolutely honest and that sometimes means getting loud and shouting at each other. But what was the saying: What happens in the TechCabal stays in the TechCabal! We found that decisions that are achieved in honest discussions are usually a lot better than if somebody has to make them alone. Do not get me wrong. This is not democracy. Usually we do not end up with a compromise. We end up with clear decisions. Most of the time once you listened to all viewpoints of the involved parties, you end up with a good decision that is not the smallest part of the whole that we could barely agree on. I guess a reason for that might be that technical problems seem to have good and bad solutions. The whole process only works as long as the members of the group trust each other and political bullshit stays out of it. So, yes, that means that they need to get along well with each other, which is a weak spot to some extend for this way of making decisions. Once the decisions have been made in the group, the group makes sure that they are followed. Individual members are tasked with carrying out individual decisions of the TechCabal. A group that usually only meets once a week cannot make all the decisions that come up in the development process, and it should not. As much as a lead should not try to make decisions for the guys in his team that can do without him (micromanagement), so should the TechCabal not try to take over the work, the decisions the leads should be doing. Remember, it was setup to fulfill the need for the uber-genius, not to replace the leads. How Do We Find Out What To Discuss In The TechCabal? This is not easy, and we have no strict rules. Basically every member of the group decides what to bring up in the TechCabal. For me, some of my decisions or problems feel big enough to inform the TechCabal about the decisions I have made and some decisions are big enough that I do not want to make them alone. It is a matter of experience and trust that brings the right topics into the TechCabal. Of course this means that we sometimes discuss things that are actually too small, and sometimes things that should have been decided by the group are not. It is a learning process, and we get better over time and there is also a positive side effect to discussing big and small problems alike. It gives even somebody as high up in the hierarchy as the technical director a pretty good idea of what happens in the trenches of the development of the project, and this is something that is hard to achieve by writing reports. Who Should Be In The TechCabal? There is two factors that influence who should be in the group. First is technical and organizational knowledge. You need to have all guys in the group that have the knowledge you need to make fast decisions. For us, that means that we have three programmers (lead programmer, the head of gameplay programming, and the head of console/performance programming) and two technical artists (the technical project lead and the lead technical artist). With these guys we make sure to have all the needed technical knowledge and the needed information about the current state of the project available in our discussions. The second important factor is the place in the hierarchy of a person. We simply need to make sure that all needed persons are available when it comes to making decisions. In our case, the technical director is that person that brings the authority and his knowledge about company wide technical questions. If he would not be there, we sometimes would have to get certain decisions signed off externally which would slow the whole process down. If we find out that we constantly miss certain pieces of information we add somebody that has that knowledge to the group. One thing you need to take into account though when setting up a group like the TechCabal is size. Make it too big, and decisions will be very hard to make and meetings will take far too long. Make it too small, and you will not get enough opinions, ideas, and knowledge for it to work efficiently. We found our current setup working very well. Six guys with very different background bring six different views and are still fast enough to make decisions. How Does The TechCabal Interact With The Usual Hierarchy In The Team? Very well! The TechCabal includes decision makers from very different levels of the hierarchy but includes all top level guys. So the decisions made do not need to be signed off by some higher level in the hierarchy. This also means that if the TechCabal for some reason would fail to make a decision, it can still be done in the usual way using the hierarchy in the team. I cannot remember a single instance where that was necessary so far. The classic hierarchy even helps the TechCabal in the communication with the team. Carrying out project-wide big scale decisions is usually something the technical project lead or even the technical director is tasked with. If issues become more specific to smaller parts of the team, it is the specific lead or head that is taking the responsibility. I think the TechCabal is a good example for how making decisions in a group of experts will get you better decisions and will provide a more failsafe way for decision making. This can also be used by other groups. I could perfectly imagine a design cabal, an art cabal. Just look out for situations where the decision making of a single person spans a huge area, has a big impact on the whole project and requires a multitude of opinions and facts to be taken into account. This might be a good place to have a group instead of that one person. [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]