When it comes to freelancing or managing a team I normally don’t post much about my experiences. I do however make exceptions if it makes for a great lesson. For this particular blog post, I’m going to walk you through one of the startups I was working for. Particularly why it failed. For everyone’s own personal protection, however, I won’t be mentioning any names. Before I dive into this I do want to mention that I have full permission to disclose the following information.
Like Most Beginnings
It was about a little over a year ago that a colleague had reached out to me about joining his team. Of course, since I’ve had worked with him on many occasions before and recognized his skills as a developer I agreed. Like many start-ups, things kicked off fairly well. Everyone had gotten the chance to personally introduced themselves and learned a bit about each other’s backgrounds through various Skype calls. The team consisted of a total of five members of which two, including myself, had worked remotely.
The first project we had taken on had been planned to have a time span of at least a year through a year and a half of development. Since it was aimed towards being an online multiplayer game with on-going support, post-production timelines were made to give a realistic idea of what we wanted to achieve.
We had about two through three Skype calls each week to check-in and make sure everyone was on the same page and on track. Weekly game sessions were also built into the schedule to allow for team bonding and to prevent burnouts. This kept up for about roughly three months before things got a bit messy.
No One Was Held Accountable
Like many ambitious projects, this one demanded quite a lot of time. Since this was a start-up, funding was extremely limited. Most of us had a full-time job with families we had to support. None of us talked about our personal lives very much or thought to talk about our work schedules until the last critical moment.
It became very hard to access the situation and deadlines kept being pushed back. No one was held accountable. Slowly the fun perspective of working together soon started feeling like the average 9-5 job except, it wasn’t a 9-5 job.
The Stressful Tipping Point
Slowly one by one life caught up with most of us and many of us stressed out about issues which caused many problems to develop within the team. A couple pushed for rapid development in order to get financial support and many threw temper tantrums. This has eventually led to the “finger pointing” moments and “hidden motives” that never really existed.
The team started slowly breaking apart and on many accounts, damage control meetings took up a majority of the time rather than productive production meetings. Eventually, this has led us all to agree that dropping the current project and starting fresh on a new one with less complexity was the only way to go.
Different Pages, Different Times
At first, this new project gave us all a fresh breath. Mechanics were planned out, concepts were created and prototyping was a breeze. Everyone was happy with the end result. We actually for the first time thought we had a fun solid prototype. The biggest downside, however, was that everyone was on different pages at different times. No one was ever on the same page.
Disagreements arose, as they tend to normally do amongst team members, and features were added non-stop. Concerns about “breaking into the game industry” versus “releasing a game to release a game” was in debate. Both to some extent had some very valid points but no one ever met at the middle ground.
Lost In Communication
By this point, we were already a couple months into development, which was basically just re-prototyping the prototype to accommodate the different mechanics and ideas. Concepts were just being pushed back and forth which led to difficult features that weren’t even going to be used in the final product. Communication soon became an issue and that led to different features being programmed. Many more damage control meetings had taken place and communication became less and less clear.
The planned release for summer soon became winter and then became spring. Parts of the team began dropping off for days at a time without notice and soon excuses became flowing one after another. The project dragged on for a couple of months and eventually managed to enter a beta state.
As the game became polished more features kept creeping in. Instead of working towards a final product we soon found ourselves with yet another prototype. Basic mechanics soon became clusters of multiple features and gameplay soon became untestable. The light at the end of the tunnel dimmed even further because the project was no longer within scope.
Lost of Trust
As the project timeline extended and communication clearly worsen, trust became a huge issue. We did eventually get the game to an open beta release but that was the end of that project’s lifeline. Serious legal matters were discussed and a lot of paperwork was involved. I, of course, left at this point in time only to find out later that the team has disbanded.
To wrap things up here neatly there are a few key points I wanted to touch up upon. Creating a team is fairly easy but managing one with trust isn’t as simple as it seems. There will be many rollercoaster moments but if your team can’t handle and tackle any issues that arise together it will become increasingly hard to continue. A team can only be a team by working together.
Communication must always be clear and feature creep must never be a thing, else your product will never see the light of day. Many start-ups fail because they lack communication. So next time, instead of pointing a finger, communicate.