Autonomy Without Accountability: How You Can Fail a Team by Trusting Them

Cover image from Great Games Need Great Leaders.

Traditional wisdom on leadership in the games industry tells you to trust your team. Give them ownership. Get out of their way. It is good advice that is badly understood. There is such a thing as trusting your team too much and getting so far out of their way that you leave nobody driving the car.

I gave my team everything the books say a good leader should give to develop our game. Autonomy, ownership, patience, a fair wage. I made sacrifices, didn’t take a wage of my own, invested money in the project from my income, managed the project alongside my day job. Three years later we were way behind schedule and years away from being ready to release, a team member had gone rogue on the narrative we had agreed on, I had to fire a team member and write off money I paid them in advance for work they never did, and I had lost my love for a project I'd built from nothing.

We weren't failing because I was a bad leader. We were failing, in part, because I was trying so hard to be a good one.

The hardest thing for any leader is gaining and maintaining enthusiasm around the work you are doing. Nowhere is this challenge felt stronger than in independent (indie) game development, where budgets are limited, pay is low, and teams are often composed of pre-existing personal friendships. While generating initial excitement among friends for a grand idea may be straightforward, maintaining their enthusiasm and commitment when deadlines are approaching and budget is scarce is a real challenge. Friendship may be the engine for many indie games, but it also creates challenges if we lack the willingness to confront our friends when they are underperforming.

It was my hope that Omi Oh My AI (Omi) would be run the right way. We were a small, scrappy team: one designer, one programmer, one writer, one musician. We could come together and discuss what we wanted to achieve and negotiate to get the best possible outcome, rather than one person being in control of everything and dictating their desires. I would be the deciding vote, but I would be a good lead and defer to the team. It was my hope that by having each person on the team be responsible for their own sections of the game, that they would be enthusiastic about ensuring it was reflective of them and their skill. They would put their best foot forward: it wasn’t my game, it was our game that contained their work, it belonged to them as much as it belonged to me.

The entire team working on Omi were contractors. Nothing about that was unusual, indie game development very often employs a large number of contractors due to the budget constraints of indie projects. However, contracting has significant challenges for both the contractor and the client. While contractors may be cheaper and fit nicely into a tight budget, they bring an invisible cost with them. For the contractor, the work is precarious; it’s unclear where their next pay may come from, they may need to manage multiple contracts at a time, or seek supplementary work in the middle of an existing contract. This instability can bleed out into a project the contractor is hired on and cause issues, particularly when the contractor is employed to work on a major game section or mechanic. This is the hidden cost of employing contractors: to manage them successfully, you need to provide them with continuous oversight and leadership, more than you might otherwise have to provide to a full-time team member.

We were fortunate enough in the development of Omi to receive funding in 2019 from Screenwest, a creative media funding body in Western Australia. The amount was modest: $20,000 was allocated for developing a portion of the game into a release-ready product. I elected not to take a salary myself to ensure the necessary resources were available for the rest of the team and maximise the use of our small budget.

The project had immediate challenges. I provided financial assistance to a team member who planned to attend an international conference, where they would pitch our game to potential publishers. This team member received an advance on their salary to facilitate their travel and attendance at the conference. After receiving the advance, they failed to meet multiple deadlines. In the months since the project had begun they had not made any real progress. My desire as a leader and their friend was to be patient and supportive, but the outstanding advance payment for travel became incredibly difficult to ignore as they weren’t doing the work necessary to be paid up to the advance. Then 2020 rolled around, and we were all thrust into lockdown as a result of the COVID-19 pandemic. All plans to travel overseas were cancelled. We would not be meeting with potential publishers.

A year after we’d started the project, we had still not seen much progress from this team member. Being put in COVID lockdown was not their fault, of course. But it was well within their power to make progress, and so I had begun to feel like my patience and understanding were being exploited, particularly after paying an advance on their wages. Eventually I had no other choice than to terminate their contract and find somebody to replace them. I’d made great efforts to work with them and resolve the challenges causing their delays, but they only received a year of my patience as they were a friend. If they were a stranger to me, it would have been an entirely different outcome. I had to accept that the advance I paid to them was lost, and for a project with such a constrained budget the financial impact was especially painful. The new team member that replaced them was paid out of my own pocket.

While progress was especially slow for this team member, the uncomfortable reality was that progress was slow across the entire team. Everyone on the project was employed elsewhere in order to sustain themselves, myself included. These external commitments frequently took priority over the game's development. Missing deadlines became a common and persistent challenge throughout the project, and we requested extensions from Screenwest on multiple occasions. Omi Oh My AI released to Early Access after three years of development, but the scope had expanded and the game had taken two years longer than expected. In no small part due to COVID, but mostly due to the majority of the team working jobs outside of the project.

In the year following our release to early access our development slowed down to a crawl. The absence of a deadline or financial support from Screenwest diminished the team's motivation to continue work on the game, despite my hopes they would be motivated by ownership. I investigated potential funding opportunities, and upon the announcement of a second round of production funding by Screenwest I submitted an application. This time we received a larger amount just short of $100,000, which would support the refinement and expansion of the existing game into a full release.

Rather than being a relief, the additional funds marked the start of a new set of problems for the game’s development. A core team member who had been integral to the success of the game going into early access was now causing substantial delays. While they remained engaged in work they were often secretive and reluctant to share their progress. Our meetings were conversational and productive, there was no obvious problems. But months into development, it became clear that their section of the game had deviated dramatically from our original intent and the plan we had allocated time and funding for. It changed the flow of the narrative, introduced new characters we hadn’t originally planned for, and changed the style of gameplay from what we’d found success with in early access. But we were too far along in the development to fix the problem. Faced with a deadline and this work that was too far along to scrap, we had to adopt it and change our plans.

In the initial round of development we had allocated sections of the game to individual team members, and this worked well within our limited budget. So when we transitioned to the full project we kept this approach, despite the significant increase in scope. Only in hindsight is it clear that it created more problems than it solved. While it balanced our budget, it presented a nightmare as the team lead for keeping the team aligned. It also presented a challenge for team members: if their primary responsibility is solely the creation of art or narrative content for the remainder of the game, what constitutes their next key objective? I attempted to address this by providing direction and requesting specific deliverables, with wide goal posts and weeks to deliver in order to allow the team the space to manage themselves and their time.

The typical expectation of a contractor is that you can provide them with an objective, and they will identify the specific tasks necessary to complete it within the time provided. It became clear with the larger scope and time on Omi that the team lacked the professional experience or capacity as contractors to self-manage and complete their broad objectives as contractors in this way. Contracting is itself a skill. In order to manage things effectively, I would actually need to be meeting with them more often and build a better understanding of what they were trying to accomplish, so that I could direct them on specific tasks to complete and tighter timelines to complete them within. This was immensely time consuming and took me away from my own duties, making it necessary for me to hire a new team member to assist us and cover some of the work I was now unable to make time for.

While their behaviour was unprofessional it was also not specifically the fault of the team. We had set up the studio in such a way that they owned their work, they didn’t need to answer to anybody but themselves. As a result they became listless or focused on concepts that were more interesting to them than they were critical to the game we were making. I had established that I would be patient and get us extensions if necessary, so if it took more time they wouldn’t be responsible for the inevitable fallout.

Servant leadership is a leadership model built on a simple inversion: the leader's job is not to direct, it is to enable. Rather than being a centralising authority, a servant leader removes the obstacles between their team and their best work. They trust people to do what they were hired to do. It's a model with genuine appeal in creative industries, where expertise is distributed and autonomy tends to produce better work than micromanagement. In game development especially, where teams are often composed of specialists who know their craft better than any single director could, the instinct to lead by serving rather than commanding feels right. It often is right. But I found its limits. I had become such a servant leader that the team was no longer accountable to me or the deadlines we’d established.

I had the worst of both worlds: I was responsible for a substantial amount of money, and for a team that took no responsibility.

When we set out on the project, I wanted the team to feel ownership and to be motivated by their own professionalism. I repeatedly deferred to them, expressed my trust in their expertise and direction, and provided them with whatever they needed to succeed. But I failed to hold them accountable. Without a leader to be accountable to, the team answered to no one. And with no one to answer to, the team became listless. Servant leaders don’t remove the goalposts, they clear the path so that the team can score goals. If all the obstacles are cleared and goals still aren’t being scored, a servant leader still needs to step in and hold the team accountable. I’d failed at that final step because I thought the team would care about kicking goals as much as I did, but very often they just enjoyed the idea of being involved at all.

Our typical approach when educating game developers is to emphasize the creation of their own games. This assumes that an understanding of the development process will naturally lead to employment. But with the game industry's increasing reliance on contract work (particularly within the Australian context), it is clear that game developers lack the requisite skills to operate effectively as contractors. Contract work demands strong communication and accountability, yet the established structure of our team made these qualities non-essential. This systemic issue was never addressed on Omi: once the project commenced and gained momentum, implementing changes to contracts and fundamentally altering the working culture would have prolonged the development of the game. I made the choice to just do what I could to get it done. I lost my love for the project, I just wanted it to be over.

The team were never unenthusiastic, but they were unfocused. Granting the team autonomy and accountability resulted in a greater number of complications than it resolved, but what was the alternative? Consider if I had opted to assume the role of game director instead, centralizing all authority and responsibility around myself. I would need to communicate specific requirements to each team member; a process demanding a deep understanding of the game and its individual systems to provide the necessary direction. Instead of the team having broad functional responsibilities (e.g. writing, design), contracts would need to stipulate the successful completion of predetermined tasks. I’d need to identify the tasks from the broader scope of the game, and direct the team on my specific intent. Our current approach had already taken me from other tasks, this approach would have rendered me completely reliant on the team by requiring that I delegate those responsibilities to others, increasing the cost of the project. A game director is essentially a coach: providing directions from the sidelines, not on the field. It’s not impossible to kick goals while also shouting directions, but it will inevitably lead to missed opportunities due to the lack of focus.

An entirely flat-structured game studio where each individual assumes responsibility for their own output is not impossible. But it requires one of two things: either an exceptionally high standard of professionalism among contractors, or a large enough budget to secure a team's undivided focus as full-time employees. People require consistent wages and stability to maintain their energy on the game you are making. If they are preoccupied looking for their next role or considering what they need to get done at their “real” job tomorrow, they aren’t going to be thinking about what you need from them right now.

Towards the end of Omi’s development I shifted my responsibilities as much as possible to a more directorial role. The programmer I hired freed me up to think about providing more specific direction to others. If I were to do the project over again, this would be my approach from the start. The “right” way to do a project requires the team to feel heard and appreciated, and a good director will do these things. I would give the team strict deadlines and clear tasks: not micromanagement, but goalposts. I would not tell them “write the story”, I would say “write this dialogue”. With their contracts reduced from broad sections to individual features I would be able to hold them accountable to our deadlines. Then, if they missed established deadlines, only that single feature may have experienced a slip rather than a whole game section.

As creatives we want a perfect world where everyone’s voice is equal. We value the creative input of every individual involved in the process, and we want everyone to feel heard. This can make a flat studio structure highly appealing, but I think it also comes from a darker place. Game developers have had exceptionally poor experiences with leadership ever since its inception. By adopting a flat structure, the underlying message is not merely that the problem lies with poor quality leadership, but with the fundamental concept of leadership itself. But a flat structured studio doesn’t remove leadership, it makes everybody responsible for leading. Now, rather than a single bad leader, you have a studio full of bad leaders.

Games are hard to make. Our teams need people who are willing to manage the strategy so that they are free to think about scoring goals. That’s what a good leader should do: lift the burden of thinking about the game plan, so they can focus on kicking goals. We cannot avoid leadership because we have experienced others being bad at it. We must commit ourselves to establishing a higher standard of leadership and embrace the role as necessary for the health of our games and teams. So don’t play a position: clear the path, watch the clock, and ensure that everyone else is in the best position to succeed. Even a team of the best players will lose their games if nobody is on the sidelines.