Thoughts of a First-Time Game Director
Autumn Conway , 11/3/2025
When I walked into my first official meeting as lead of the Jelly Beach development team, I was terrified.
Sure, I’d technically had some form of leadership experience on other group projects before—mostly just by virtue of being an overachiever who couldn’t take the thought of getting a grade lower than an A+. But I’d never been an official lead on a project so carefully structured and organized. A project where we all cared about making a quality game on time, not just meeting some random requirements on a rubric. A project where a team of students, some of them more experienced than me, were relying on me to keep production of a game running smoothly.
I had no clue what I was doing.
Now, with a semester and a half of leadership under my belt… well, I wouldn’t say I magically have all the answers now—far from it, I still feel like I have no idea what I’m doing most days. But I’ve learned a lot. And I imagine I’m not the only one who will ever find themselves in this position. So, I thought I would write this blog post to share what I learned along the way while struggling my way through leadership, so that if anyone reading this ever finds themselves in the same position, they can learn what to do—and what not to do—when a leadership role is thrust upon them.
Start of the Semester
At the start of each semester, I would sit down and figure out what we needed to do to bring the game to completion. (Doing this was not my own idea; every team did it at the suggestion of Professor Mesh and the production team.) I would look at the current state of the game, the problems we’d discussed it having, and the features we still wanted to add, then use that information to try to figure out how to bring the game to completion.
Since our team was using Agile methodology, our work was broken up into “sprints”—two-week spans of time where everyone on the team would be working towards some goal, with the intent of meeting that goal by the end of those two weeks. As a result of this, I usually just identified a major task or two per sprint and wrote those down in what seemed like a logical order to me. (Usually this meant putting the most important and most potentially time-consuming things at the beginning.)
I also learned—or more accurately was taught by the producers at echoes—to take into account the fact that I, and my team members, were human. In particular, despite what I said about putting the most important tasks at the beginning, the first sprint of the semester is not a good time to bash everyone over the head with our most challenging, stressful tasks. Simple debugging tasks are much more effective for onboarding new members and getting old ones back into the flow of things. Even if it killed me inside to wait to start on the important tasks until two weeks in, it was absolutely necessary for everyone’s sanity.
Start of a Sprint
The start of each sprint went a little differently. We already had our sprint goal, so then the question became “how do we actually meet that goal?” This was twofold: what did we want to do to meet the goal, and how did we want to do it?
For example, for much of the semester we were dealing with an issue where our players weren’t fully understanding our “dialogue,” which wasn’t dialogue at all but instead wordless pictures that told a story. We had to go back to the drawing board over and over again while trying to get the idea across to our players. Because of this, our sprint goal was something along the lines of “fix player dialogue”—which, though useful as an overarching task, didn’t tell us much about how to accomplish it.
So, the first question was, what did we want to do to fix player dialogue? Did we want to alter our game design completely, maybe start using words again? Did we want to redraw a few of the dialogue pictures? Did we want to revise the area surrounding the character in question so that there were more context cues?
Once we’d decided on that, the next job was to break everything down into measurable tasks. Let’s say we settled on redrawing some of our dialogue. Someone needed to redraw that dialogue and add it back into the game—was there anything else that needed to be changed? Maybe a different line of dialogue referenced the one we’re changing; will it need to be changed too? Who would be in charge of changing these things? Figuring out the answers to those questions usually wasn’t difficult, but they had to be asked—on occasion, I accidentally let meetings slip by without getting answers to those questions, and this resulted in the tasks not getting done at all and stalling work on the game.
As we were breaking everything down into tasks, my job was to keep in mind what would be reasonable for everyone to complete on time—since we had three coders, we would usually divide up the coding work evenly. But since we only had one artist, a lot of art tasks ended up having to get pushed back to other sprints (which was unfortunate, but everyone’s sanity and other classwork was more important than having every art asset in the game immediately).
This was very much a team exercise. While planning out the per-sprint semester goals was usually an individual endeavor (which I only briefly ran by the team to make sure they didn’t have any objections), planning out the sprint itself had to be a group effort conducted via a meeting or two at the start of the sprint… as much as my very Type A, if-you-want-it-done-right-do-it-yourself personality wanted to just jump ahead and work everything out by myself.
However, not only does the team deserve to have a say in all of our design decisions, but also, this was often a task far too daunting for any one person to take on alone. Early on during my time as lead, I mostly understood this, but I would often try to come up with solutions to as many problems as possible in advance, juuuuust in case. But, as the semesters went on and I became overwhelmed, I started doing this less and less… and the team kept going just fine. It wasn’t bad to come up with potential solutions beforehand (this helped keep brainstorming productive so that there was at least something to jump off of, instead of everyone sitting around staring at each other), but they didn’t need to be the perfect solutions that solved all our problems—half the time, they didn’t even need to be good. The team would hammer out the flaws or come up with something entirely different over the course of our meeting. As lead, my only job was to guide the discussion and make sure everyone stayed on task.
Unfortunately, I tended to make a big mistake here when sprint planning, which plagued me until the very end of Jelly Beach: I usually tried to get the team to plan out the entire sprint in detail at the very beginning. This made intuitive sense to me, to plan out what we should do at the start and follow through on this plan until the end. However, this also meant that if anything had to be added for some reason—if I received instructions during the leads meeting to hold a retrospective that week, or if we got feedback that made us realize a feature was much further from completion than we thought—it was very difficult to pivot and get everything back on track. This often resulted in either overwhelming myself to keep up with demand (because I wasn’t willing to overwhelm my team members for my mistake), or pushing other, fairly urgent tasks farther back, much to my team’s frustration!
To be honest, I still struggle with this one. But so far what’s worked best for me is simply to plan less, and leave as much wiggle room as possible in the plans I and my team do make. Having a general idea of what should happen in each sprint was very important, but it was much easier to fit something new into a meeting if there weren’t any plans for that meeting in the first place.
Before Meetings
Meeting planning was by far the easiest and usually my favorite part of planning. Really, it was just working out the answers to three questions:
- 1. What do I need to communicate to my team?
This was something I would be paying attention to throughout the week, as information like due dates for individual assignments, echoes-wide meetings, or tasks I knew I’d want my team to do came up. Basically, I asked myself, “If I were one of my team members, what would I want to know about?”
- 2. What do I need my team to communicate to me?
This was usually in the form of quick check-ins to see how everyone is doing, but if I wanted feedback on something (e.g. “is this meeting time working well for everyone?”), or wanted to see if anyone needed help with an upcoming assignment I knew could be confusing, this was also something I would put on the meeting agenda.
- 3. What does the team as a whole need to figure out?
This usually made up the bulk of our meeting. What do we need to get done? How do we want to get it done? Who’s going to do it? At the start of a sprint, this was the sprint planning stuff I discussed earlier. In the middle of a sprint, it was usually adjusting to anything that had come up, or further elaborating on stuff we’d figured out in prior meetings.
Once I had those questions answered, I’d just throw a quick bullet point up on our shared meeting agenda document for each thing I wanted to discuss, and refer to that document throughout the meeting. I usually did this a couple hours before the meeting, but sometimes it was days before and sometimes it was minutes before—whatever worked best with my schedule at the time!
Final Thoughts
I’m sure for experienced game directors and team leads, the things I’m outlining here are nothing special, possibly even basic common sense.
However, as a brand-new lead, these were all things I had to be taught or figure out myself. I can’t imagine I’m the only one who felt, feels, or will feel confused and overwhelmed at the prospect of being a team lead for the first time. My hope is that this post will help you learn from my mistakes and get whatever project you’re working on off to a smooth start!