Time Tracking, When Done Wrong, Is Useless

My good friend, this week you are in luck.

For starters, I’m going to forego my usual wordy style and cut right to the chase. I’m typing this well in advance of the deadline, because I’ll be on vacation when this is posted. That means I don’t have time to blather incessantly about artwork and other such nonsense. (Really, who has the time?)

The other reason you’re in luck is because I’m about to save you about 14 months of hassling when it comes to proper time tracking. They say that good judgment comes from experience – and that experience comes from bad judgment. Well, let’s talk about my experiences with time tracking. Then we’ll get to my bad judgment near the end.

 

Jack

A sample time sheet from the veeeeeeery beginning of the Demo Phase.

 

Time Tracking: An Intro

Before we go on, a quick definition is in order. You’re probably wondering what time tracking is. (If you already know, you’ll save time by skipping this section.) Time tracking is the continuous project management process of collecting data on how members of a project are spending their time working on that project.

In theory, you’re supposed to do it for a few months and then look at the data. If you find out everyone is spending 5 times as long as they should working on some task (A), then you’ll change process (B) so that task (A) doesn’t take so long in the future. That’s the hope, anyway.

In practice, it means filling out time sheets (see above) like a madman every time you do anything related to your indie game. Done incorrectly, it will actually take time away from your project and give nothing back in return. Done properly, it gives you keen just-in-time insights that let you wisely cut features and move staff around before you hit that impending deadline.

 

Old Sheet

On the surface this time sheet may look good. However, on further inspection…

How To Do A Bad Job

I want to tell you how to do time tracking properly, but you won’t appreciate the correct approach until you see it done wrong.

For the entirety of our time working on the Where Shadows Slumber Demo, Jack and I tracked our time with a time sheet I devised. This Google Spreadsheet had an entry for every sprint (a period of 1 or 2 weeks, usually the time between team Skype meetings) with a bunch of headings: Day, Start, End, Total, and Task. Here’s what they meant:

  • Day – What day during the Sprint did you work on this Task?
  • Start – “Punch in” at a time to begin working on the Task.
  • End – “Punch out” at a time to stop working on the Task.
  • Total – The number of minutes you worked on the Task.
  • Task – What you worked on.

As you can see, this tells us a lot about how I spent my Sprint. But none of this information is relevant to project management in the long term. There’s no indication whether or not I actually completed the Tasks I worked on. (Some have percent complete markers, but those are just guesses anyway) Looking at this, I have no idea how the project moved ahead during the Sprint. Our only real metric is the number of hours I worked – nearly 19. But… who cares? It’s not like I’m charging anyone by the hour! Jack and I do this as a labor of love, with salaries to come from proceeds from the final game.

This time sheet makes the critical error of measuring the wrong metric. I must confess that some weeks, I tried to just work for a long time instead of working effectively so I could feel good about logging impressive hours. That’s a sign of bad project management. As a manager, you ought to offer incentives for behavior that gets the project completed on-time and at a high quality.

The results? Internally, we had a lot of arguments about this process as Jack felt it was unnecessary. Because I never returned to the data we created to analyze it, we got nothing for all our tedious efforts. Jack stopped tracking his time, and that was a warning sign that I needed to change things up. Our time tracking was costing us time to do, with no benefit to the team. Time for a change!

 

TimeSheet

Time Sheet: Version 2.0!

 

My Time Tracking Strategy

Here’s how I altered the process for the final project. Starting April 4th, I began tracking my time the way shown above. The headings this time are Task, EST, ACT, Error, and Status. Let’s deconstruct that jargon:

  • Task – One entry for the Task this time, no matter how long it takes.
  • EST – Short for “Estimate”, this is an educated guess about how many minutes this task will take to complete. You’re supposed to guess at the beginning of the sprint.
  • ACT – Short for “Actual”, this is the actual number of minutes this task took to complete. You’re supposed to fill this in as you go. It’s the only thing that requires active time tracking while you work.
  • Error – This is automatically calculated with an Excel formula. It’s the percentage of error between your guess (EST) and the actual time (ACT). You want to get 0%, meaning that your guess was perfect. The larger the number is, the worse your guess was. The formula I use here is =(ACT – EST ACT.
  • Status – The most important part! Each task is a discrete item within the larger project that is either done or not done. We want a full list of check marks at the end of this sprint. If a task is left incomplete, there had better be a good reason!

As you can see, now the spreadsheet is setup with the Task as the most important thing. We’re measuring whether tasks are complete ( ) or incomplete ( ) instead of measuring how many hours someone has worked. That’s important, because people tend to maximize whatever they’re being graded on if you observe them working.

It’s changing my behavior, too! Instead of acting like I need to fill my time sheet with useless “minute points”, now I feel the pressure to get my estimation right. Of course, I can only be right if I finish the Task. The incentive structure of this time sheet is way better! We begin with an incentive to make a good guess. Then we have an incentive to conform towards that good guess so we don’t get “mark of shame error percentages”. Finally, we have an incentive to finish each Task so it doesn’t remain a permanent “X of shame” forever. Perfect!

This will lead to actual progress on the project and helpful information about our estimation ability at a glance.

 

innovation-think-big-act-small-fail-fast-and-learn-rapidly-7-638

In all seriousness, though – I did fail.

The Lesson? Get It Right The First Time

To conclude… I have bad news. If you’re a project manager, listen up! You need to get this stuff right the first time. Putting your teammates through a tedious process of time tracking gets on their nerves after a while. People can only put up with that for so long, especially if they don’t get anything out of it.

I’m still doing time tracking, but Jack has become disillusioned with the process. I don’t blame him, but it’s still a shame. Had I gotten this right the first time, we might still be on the same page.

Don’t reinvent the wheel like I did on my first attempt. Use a proven method that works, read some software management books, talk to an industry professional, and communicate with your teammates during the early stages of the project. If you do, people will find time tracking fulfilling. Otherwise, they’ll fall by the wayside. And remember – you can never force anyone to do anything, you can only offer irresistible incentives!

 

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

Thanks for taking the “time” to read this “clock”. Have a question about time tracking that was not answered here? You can find out more about our game at WhereShadowsSlumber.com, ask us on Twitter (@GameRevenant), Facebook, itch.io, or Twitch, and feel free to email us directly at contact@GameRevenant.com.

Frank DiCola is the founder of Game Revenant and the artist for Where Shadows Slumber.

 

Where Shadows Slumber: Working On A Small Team

Editor’s Note: The post was almost titled ‘Working with Frank Suxxxxxx’, but I decided against it (mostly because it’s not true).

So, you want to be a game developer, do you? You want to be the voice behind the games that so molded your childhood? You want to create an experience for generations ahead to enjoy?

Well, the best way to do that is probably to get a job at-

What’s that? Oh, you want to be in charge of the game development. You don’t want to work on a game, you want to create a game. You don’t want to help someone else make their game – you want to make your own game, in your own voice.

In that case, it looks like you want to become an indie game developer. You get to design your own games the way you want to, which is a thrilling concept. However, it’s not all fun and games and I-don’t-have-a-real-boss, and you should probably know exactly what you’re getting into.

MNCvsStartup

Choices, choices…

Now, I’ve never worked at a professional game development studio, so I can’t give you an entirely clear picture of what you’re missing out on there. I do have some experience with different-sized companies though – my last job was at one of the biggest banks in the world, my current company employs no more than seven people, and I, of course, am on the two-person Where Shadows Slumber team. So, hopefully I can give you a good overview of the differences between these types of jobs and companies, so that you know what you’re signing up for.

There are a lot of differences between small teams and large teams, and there are a lot of similarities. I’m going to go over some of the things that are better about each. These lists won’t be absolutely complete, but I hope I can sketch out a rough image of what life looks like at these different jobs.

Also, real quick, I just want to mention that if I say something bad about working on a small team, I am not necessarily referring to Frank, or anyone at my current job. I’ve been on a lot of small teams over the years, and these are just my general observations, not passive-aggressive pain points meant to make my colleagues feel bitter.

 

The Bigger, the Better

BigFactory

Cubicles, as far as the eye can see!

For the most part, when I tell someone working in technology that I worked for a large bank, I get a negative response, or maybe some sympathy. It seems that it’s not viewed as the ideal technological job. While bureaucracy isn’t exactly my thing, I will say that I did enjoy my time there, for a number of reasons:

  • Responsibility – The thing I liked most about working at a big company was a lack of responsibility. Maybe that’s my 16 year-old slacker self talking, but there’s something really satisfying about not having to worry about the future of the company. Had a bad quarter? As long as I still have a job, I don’t really care! There’s a tough decision to be made? Glad I don’t have to decide! While this isn’t the best way to be thinking about the company that’s providing your livelihood, it is a somewhat calming thought.
  • Funding – I suppose this one is the most obvious reason why a big company might do well. There’s a lot of cash money floating around in the company, so any project the company decides to pursue will be well-funded. Along with this comes a lower chance of failure. Since you already have funding, and you already have a name people recognize, most of your projects will be much more likely to turn a profit. They say that 90% of startups fail very quickly, making startup jobs very volatile. Getting a job at a large company, however, might end up lasting far longer than you even want it to!
  • Specialization – When I worked at the bank, I was on the identity management and access control team. If someone had a question about SSO, security, trading, or anything else, they wouldn’t come to me. I only had to worry about identity management and access control concerns. You end up specializing in a certain area, and that area is your only concern, so you can really learn a lot about it.
  • No Personality Clashes – This is one you don’t really consider that much, but it can be a biggie. Working in close proximity with the same people day after day will probably happen wherever you end up. However, that situation gets a lot more interesting when you have to continuously make difficult decisions with those people. If you disagree, how will you resolve it? There’s no ‘boss’ you can go and ask – you have to work it out. This doesn’t sound too bad, but that’s only because we don’t really notice other people’s personalities until we’re already in the crucible with them. Maybe your partner is incredibly stubborn, and you can’t convince her to change her mind about something. Maybe he’s really arrogant, and he’ll never even consider that your idea might be better than his. Whatever the situation, you need to be able to resolve it. (again, this doesn’t refer to anyone in particular).
    This situation, however, is less likely to occur at a large company. If you disagree with a colleague, you can ask your boss, or quote company procedure, or ‘escalate’ the issue to their boss. In the majority of cases, you’ll only have to work with that person a handful of days out of the year anyways!

 

Less Is More

booth

Just one booth?

As good a case as I made for big companies, working on a small team has also been really awesome. Here are some of the reasons:

  • Decision Making  The first and most important benefit of working at a small company (or, in particular, your own company), is being involved in the decision-making process. When you’re one of the only five people making decisions about your product, you have a lot more say in the outcome. People take your opinion seriously, and you can actually make a difference in the product. This, I imagine, is the biggest reason that people like to work at smaller companies – if I want to make a game that’s really mine in some sense, then the bigger an impact I have on that game, the better.
  • Creative Freedom – This is another biggie, and it’s very similar to the above. I don’t want my boss to tell me that the Ring of Blood item should be red – I want to make that decision myself – maybe I want it to be green! That might not be a great idea, but at least it’s my decision.
  • Pride – When you make something awesome, you have a lot of pride in it. When you’re one of the main reasons that a project is completed, you feel a lot more pride in it than if you only helped out a little. Saying ‘look at my awesome game’ feels a lot better than ‘look at my company’s awesome game’.
  • Learning – When you’re working on a large team, you might end up being a ‘guy’. You might be the ‘shader guy’, or the ‘pathfinding guy’, or whatever. However, when you’re working on a small team, you have to be all of the ‘guy’s. For Where Shadows Slumber, if there’s anything that counts as a programming task, I’m the one responsible for it. That means I have to be an expert on everything. This can be viewed as a bad thing (and I even listed it as a benefit of working at a big company), but I prefer to think of it as a learning opportunity – I know a lot more about shaders now than I would have if I had a ‘shader guy’ to take care of it for me.
  • Working with Friends – Yes, I listed this as a startup-con before, but there’s still something to be said for working with your friends. While it can lead to some messy situations, it can also lead to some brilliant teamwork and a very fun working environment. You just have to make sure you know how to deal with each other before you start working together.

 

The Dream Team

So, what is the ideal team to work on? In particular, what is the ideal team for you to work on? What’s your dream team? Unfortunately, I can’t answer that question. What I can do is tell you about my experience with small teams, and what I’ve learned from it.

17159203_1817437325174646_6524966612565150056_o

This is it. This is the dream team.

Striking out on your own is an exciting prospect. Thinking forward to a future where you’re publishing a game and making enough money to not die is awesome, and knowing that you get to make any and all decisions about that game, making it truly yours, is inspiring. You’ll sit down at a booth to show off your game, someone will ask you how big your team is, and you’ll get to smugly reply ‘it’s just us’. You don’t answer to anyone, and you’re the only one who gets to change your game.

This is also an exhausting experience. Continuing to work hard on your game, knowing the chances of failure, can be very discouraging. Working on the same project every single day, seeing the glacial progress, and still believing that you’re going to ‘make it’ is sometimes impossible. Arguing endlessly with your team members and looking forward at another year of difficult decisions, knowing you still have to work with them every day, is a near-insurmountable mental and emotional hurdle. Not to mention the pressure to succeed, especially if you’ve decided that this will be your only occupation. It’s a task that not everyone is cut out for.

The option I went for ended up being a blend of both. I worked at a big company as my actual job, and worked on Where Shadows Slumber as a side project. This allowed me the freedom to create my own game in my own voice, without having the stress and pressure of living on an indie game development salary. This is an option I would recommend, although I will say that it can be more difficult than either of the alternatives, since you end up doing more day-to-day work, but your game takes even longer to complete.

 

I can’t tell you exactly what kind of team you should be trying to work on, or if indie game development is the career for you. No matter what I say, if you’re meant to be an indie game developer, you will be. All I ask is that you know what you’re getting into before you take the plunge.

 

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

Hopefully this gives you some insight into the world of small teams, and I didn’t scare you off too much. If you have any questions or comments about working on a small team (or anything else), you can always find out more about our game at WhereShadowsSlumber.com, find us on Twitter (@GameRevenant), Facebook, itch.io, or Twitch, and feel free to email us directly with any questions or feedback at contact@GameRevenant.com.

Jack Kelly is the head developer and designer for Where Shadows Slumber.