Atari : Or how I learned to stop putting pressure on teams and trust people

atari

I recently watched the documentary Atari: Game Over. For those who have yet to watch it, it’s about the Atari games engine and the rumors surrounding the dumping of the ET game. I would highly recommend everyone watch it. What I found most interesting about it was the company’s attitude towards its staff. There are interviews with old staff members. It seem Atari was the cool place to work at the time, and why was this? They left their staff to pretty much their own devices. There was nearly an “anything goes” attitude, once the work got done. This allowed for people to have fun and try new things. What happened? Work got done! Not only that, but the developers made some of the most popular and best selling games at the time. Some of these games took 6 months, some took a year, but the finished product always seemed to sell well. Along comes the ET film and, with it, a great idea for a new Atari game.

etvideogamecover

This is where the pressure increased. Suddenly this game was needed for the Christmas market. Rights for the game were finally obtained in July, thus giving the developer (Howard Scott Warshaw) only 5 and a half weeks to make the game. This is a big difference from the 6 – 12 months he had to create some best sellers of Atari’s fame. The game is regarded as the worst game ever made in a lot of reviews. Personally I think that’s a bit harsh, knowing the developer and the deadlines. But it was the start of the end for Atari. What can we learn from this? Well a lot of people would say that the game should have been better. There were some bugs in the finished product, making the game an overall frustrating experience for the user. So, I firmly believe given the same amount of time as previous games that ET could have been much better and a massive hit. The pressure put onto the developer, to create a game under such a deadline, was a massive mistake. The more pressure, the easier it becomes to cut corners. The first thing that usually goes is testing, hence you get a bad user experience, exactly what happened with the ET game.

Sadly I have seen this happen to teams I have worked on. Best practices go out the window once there is some pressure. “I don’t have time to write tests, this needs to be live”, or “I was told to release this card anyway and we can spin up another card to fix the bugs”. This tends to happen when the teams are judged on how many cards they release per week. Suddenly its a race to get cards done by Friday. The answer to this is to focus on the value that is being released to the customer, not how many cards we get done. Pressure tends to come from above, but if we are focusing on value and each card delivers something useable to the customer then  we can build up trust and this will help to remove pressure. I, of course, don’t know the details around the ET game but I imagine had a user been put in front of it before it was released, a lot of the bugs would have been found and it could have possible saved a chunk of money.

Queen and David Bowie understood what happens with too much pressure. We don’t want to be “watching some good friends screaming ‘Let me out'”

maxresdefault

Teams should be empowered to work and trusted to do able to do their jobs. If there is pressure try and not let the teams see it. Fix it by allowing the customer to see the product early.

3 thoughts on “Atari : Or how I learned to stop putting pressure on teams and trust people

  1. Great article and love that you picked out the reason we count velocity as cards per X. We don’t trust each other to work and do what’s of most value to customers. So we need a count that we’re actually working.

    One sticky point is the external influences. The reason for the ridiculous 5week deadline was probably to ride of the ET wave and garner sales off the Christmas market. Leaving the team to their devices and having the gave arrive in 6months means next summer which would make the sales forecast/outlook less favourable.

    How do we satisfy the external influences and what’s best for providing the best value for customers?

    Does one of the two have to get screwed?

    Like

    • Thanks for the feedback. I think we can still release software under market deadlines, just making sure there is fast feedback. ET for example was released and in time for the market, the problem was that the game was crap to play. Had they even showed an early version to some end user they could have found these problems out sooner. Agile embraces the small change and get feedback approach which I think really works and can be used even under deadlines.

      Like

Leave a reply to Darryn Downey Cancel reply