Pivoting into production

Until recently, I was a programmer who was just a team member, programming whatever a designer or instructor asked. I hated not having a say and watching the people above and around me give outdated advice, use non-optimal systems, and assign tasks that did not play to individuals’ strengths. I thought I could do so much better than the managers above me. In other words, I had an ego and thought leading a team was easy work.

After years of stress and irritation, I realized I did not want to be a programmer for the rest of my life. Do not get me wrong—I still enjoy programming sometimes. I like playing around with front-end programming, UI, and web design. However, cleaning up other people’s code, looking for bugs, multithreading, and cybersecurity protocols kill much of the joy and intrigue that came with programming for me. It became a monotonous task where I sat at my computer for hours and did not get up to talk with anyone; I hated that part the most.

The combination of my ego and my dying interest in programming led me to investigate more leadership-aligned positions. When I saw a position for an entry-level producer, I applied immediately, only a few days before the applications closed. I went through the Zoom interviews the following week and got the job. I felt elated to be moving from the computer science field and into game development - my absolute dream.

Managing not to manage

I hate feeling out of control. Since I was a child, I have had power struggles with various authority figures because I felt like I had no say in what happened for most of the things in my life. Moving away for college was the first time I got to control my schedule completely. It took some time to get used to the freedom, but over the four years I lived at school, I grew to love finding ways to help increase my productivity and manage my life better. Though there were many areas I still did not have complete control over, such as my work as an RA, I prided myself on my ability to find optimal systems and effectively control the chaos in my life.

 When I started working as a Software Development Producer on an arcade racer called Fastival, I tried to take control immediately. Since we had a 48-person team (15 of which were programmers), I wanted to ensure the programmers could get off the ground as soon as possible. I created what I thought was the most optimal system so the level designers could have a car to test their levels, and then artists could have an object and maps to put their 3-D models on.  I made a board on Monday.com and planned the entire first sprint without consulting anyone above me. I wanted to begin our first sprint with a solid plan and get people working on the tasks.

I was quickly humbled because, it turns out, the team members also dislike it when other people try to control them. Additionally, it was not even my job to make the system I used to assign tasks, meaning I took away the control the people above me were supposed to have. On top of all that, it wasn’t even my job to start building a backlog in the first place.

One of my mentors heard about this, and we had a discussion during which he gave me one of the best pieces of advice I have ever heard: you are not a manager. If my job were to be a manager, that would be my title. A well-intentioned dictator is still a dictator at the end of the day, and if I do not give my team the autonomy to self-organize at all, they will resent me for it.

Additionally, a Monday.com was already in the works that would be usable for all the teams on the project, not just mine. By creating my own board without consulting other leadership members, I forced my team to learn how to use my board, only to learn a whole new board in the next sprint.

 Securing stability

In the next sprint, I overcorrected just a bit too far. After acting heavy-handedly with tasks during the first sprint, I pulled back and gave the team much more freedom. Sprint planning with the lead team produced a rough set of goals for our upcoming milestone. Together with the lead, we broke down the goals into tasks and presented the list of several dozen to the whole of the programmers.

The strict structure we focused on during the first sprint was gone in the second. I let people work on whatever they wanted and no longer forced them to work exclusively on tasks assigned to their sub-teams. I did not want to step on any toes, so I did not even place priorities on the tasks.

The second milestone showed many more completed tasks, but the lack of order meant some tasks saw progress without enough completion to show stakeholders. Some systems had no intentional design, and many had to change for rebuilding throughout the next milestone.

Throughout the next several sprints, I found ways to balance the team's organization while giving the team freedom and not stepping on the toes of those above and around me. By marking tasks based on their priorities and informing the team of milestone deliverables, I could still give the team autonomy to choose tasks while communicating which tasks were necessary deliverables. Within the Monday.com board and later the Jira board (we switched halfway through development), I found ways to support my team by creating automated behaviors like notifications without making my own unique system.

These experiences taught me that better leadership is about balance and collaboration rather than enforcing whatever I thought was best. Transitioning from programming to a production role taught me the importance of empowering team members and valuing their input while maintaining a clear vision and structure. I fostered a productive and harmonious working environment by finding a middle ground between hands-off freedom and rigid control. As I continue to work on new teams, I do not doubt that I will have to take time to find the best balance for each new team I work on, but I am excited to make mistakes, learn, and adapt.