Thoughts on Team Leading in IGM
Thoughts on Team Leading in IGM
Throughout my time as a Game Design and Development student in IGM, I’ve worked on a large number of small teams. Since my first semester here, I’ve had at least two group projects a term, and have worked on a variety of roles across them. A large part of the way I work, especially on games, is to start early and get the ball rolling, which usually ends up with me leading the early conversations. This trait flows into often becoming a de-facto leader, and as a result of that pattern, I’ve lead a lot of teams I’ve worked on. That’s not a bad thing, but definitely was an element I had to learn to be comfortable with. I had to practice and grow in regards to how I worked with others, delegated, and planned meetings in ways I hadn’t done in high school.
Leading a group isn’t always a fun experience. Personally, I greatly enjoying working on feature implementations and design processes, so I don’t always like getting pulled out of that to check status updates or work out group issues. But projects do need leads, or at least an untitled someone to help take and categorize the organizational work. To me, leading projects at IGM isn’t a dictatorial experience, but feels more like a guider for the collaborative process. It involves forming a project out of different people’s perceptions and ideas, and then working to refine that into an actionable work plan. The leader holds people accountable, but groups are small enough that the leader also has to work on implementations and other elements. In some big projects, like my capstone, we use timelines and task lists to stay focused, and I make, maintain, and monitor those as part of my role. I never thought Excel would be so important when I entered college. Even there, I still work on the game directly as part of my team. I’ve never seen a pure management person on an IGM project simply because most projects and timelines need everyone working on the deliverables, and I’m happier for it.
Even as I moved on to larger scale projects over longer timelines, that same system has worked well for me. It’s important to note that most people in your projects are of similar skill and knowledge, with only a handful of classes or years difference in experience. If someone isn’t particularly focused on one aspect of the project, they have something they’re the best at elsewhere. As a usual lead, it’s a responsibility to ensure people are working on the best features and issues for their skill sets, and understand directly comparing output or work isn’t always useful. Comparing an artist’s contribution to a programmer’s work leads to confusion more often than helpful insight. Rather, a lead should look to how that work is getting used, and how the efforts are directed. Communicating with the team to find issues early, or to make it easy for someone to discuss delays and issues also helps make this process easier for everyone.
However, the biggest thing I focus on as a lead now is making sure my group knows when to stop working. I’ve had to make people go home, and then ensure they take a break. Often, this isn’t a result of deadlines but rather a desire to keep polishing and improving the experience. It leads to delicate situations, where a lead has to step in and stop someone from working now so they can stay healthier later. I’ve pulled some long nights for deadlines, but I’ve always looked back later and evaluated what put the project in that situation. Usually, it came from underestimating a problem or a lack of communication, and those skills can be improved over time.
The most difficult element I had to learn would have to be delegating. It took a long time for me to become comfortable with giving tasks to other people, especially when I had to pull them off of something else. Knowing we’re all working towards one goal helps, but it still felt weird. Ultimately, moving people’s focuses or updating the priority list helped make the projects better, but it definitely took me a while to become used to it. Similarly, there are times where discussion needs to stop and work needs to start, and making that transition can be odd.
Granted, these are all aspects of my experience leading in IGM. I recommend everyone work to put themselves in a lead position at some point in college to get comfortable with the idea, and find what style suits them. You learn a lot about working with others, but also about the hidden workload that comes from trying to put all the pieces in order in the background. It’s not for everyone, but the project based nature of IGM allows tons of experimentation, and it’s well worth the try.