“I hope I don’t wreck this thing”: When Imposter Syndrome Hits Hard
As a producer, you assume ownership of your team’s goals, backlog, and deliverables. It feels like standing at the helm of a massive ship that could capsize at any minute. It is a heavy burden and one that can easily foster a strong sense of imposter syndrome. And on my first large team project, there were moments when I experienced that big time.
My time as a lead producer was my first experience with imposter syndrome. In my previous industry, I was often the only individual in a room under the age of 40 or without a Ph.D. It was easy to feel like an odd duck out in a group of swans. In those instances, I learned to remind myself why I deserved to be in any given company and how I was more than able to hold my own.
But imposter syndrome as an individual is different than the kind of imposter syndrome you feel as a leader. Rather than worrying “Do I belong in this group”, it’s more “Am I the right person to lead it?”
Nothing validates those negative feelings more than a harsh taste of reality. I had just left a meeting with the primary stakeholder for my arcade racing game, and the project’s progress had been thoroughly raked over the coals. We were underdelivering on basic requirements and gameplay functionality, delaying usability and expert testing. For some development risks, “not finishing the game” was considered a contingency. For me, it’s nigh impossible to hear those words and not think for a second, “Is this because of me?”
Thankfully, I was able to remove my emotional brain from the subject and focus my logical brain on how to proceed.
The key to these situations is to remain calm, take a pause, and not hope for gold-plated solutions.
When a team misses significant milestone deliverables and you feel it’s your fault, it’s easy to assume it’s in your power to implement some perfect solution. You put everyone in this mess, so shouldn’t you be the one to clean it? Putting aside the incorrect assumption of total blame, let’s look at how one could react. It can be tempting to scramble and hope you find some metaphorical magic beans that rally the team to hit a sudden uptick in productivity.
Rarely, however, are those moments the case without significantly scaling up time or resources. But at Guildhall, we don’t work on projects outside core hours, and onboarding new talent was off the table.
So in the moments that followed the stakeholder meeting, I recognized that a rapid response on hope and prayer would not be the best way to go about things. As unsettling as things felt, I wasn’t going to scramble on a quick fix with a shaky foundation to speed up the sprint plan. I knew there was nothing I could do at that moment, so I took the feedback in stride and gave myself time to carefully think things over.
As soon as possible, capture your thoughts in whichever medium fits you.
I followed the advice of an old coworker of mine and wrote every feeling and potential solution I could think of in a barebones PowerPoint deck. I find larger fonts, structured bullet points, and the “drag-and-drop” slides capability very useful for organizing my thoughts. The key is to find whatever works for you in a given situation. It doesn’t always have to be in writing, either. On many occasions, I’ve recorded myself on camera, letting my opinions out unscripted.
Almost every time I revisit these musings after a few hours, I am surprised by how well I was able to articulate things. This is great self-validation. “Yes, I felt down on myself and my abilities, but look at how well I was able to communicate what was on my mind.” In doing the exercise, I’m laying the groundwork with resources for the near future. You can go back and trim or pull points from your raw thoughts into a concise package for your team.
In this recent game development scenario, I took my seemingly jumbled words and broke them down into an actionable narrative I could share with the other leads. Though it was not a definitive set of next steps, it offered a refined vision that could influence others’ plans as we adjusted to stakeholder and playtester feedback.
Shelve the reflection on “why” this happened for a sprint retrospective or a project postmortem.
It’s helpful to know “what went wrong” to help address things going forward. But spending your time and energy at that point takes away from enacting a solution. The best you can do is highlight the key pieces you believe brought you here and know to avoid them. You may miss the mark on what a primary cause was, but at least you will have general ideas that serve as a foundation. Once you reach the end of a sprint or the project’s completion, you can better remove yourself from a scenario and weigh the factors when determining lessons learned.
I know what happens when people start blaming themselves or one another. It’s important to blame neither yourself nor any individual on your team. If you do, both internal and external resentment will hold the project back further. A resentful team is less likely to feel motivated and get the game over the finish line.
Most of all, remember that you’re not alone.
Yes, big projects are difficult to manage. But with large teams come a larger support group of co-leads. And whether or not they’re feeling imposter syndrome to the same degree as you, you all want to achieve the same goals. I have learned to lean on the resources, talents, and strengths of my peers.
In the instance of my arcade racing game, I worked with the department leads and game designer to calmy reduce its scope and reprioritize key elements. By successfully putting my faith in their abilities and carefully coordinating their efforts, we achieved what we wanted to. We successfully shipped our game without crunch and delivered a balanced project we were proud of. And, through that process, I was reminded of how and why I was fit to lead.
