Why standards are important for your team
By Jeremy Putnam on December 4, 2015
How many times have you been frustrated by not so much what was done, but how it was done?
“Why did they name their file this way? What is ‘Asset6_new_final3?”
Or, “Why didn’t you see my message? What do you mean you don’t check Google chat?”
Whether standards of practice or technical standards, good standards are essential to maintaining sanity and efficiency.
Not establishing best practices can lead to lost work, failed communication, or unpredictable results.
Below I’ll detail some of the ways poor or unfollowed standards have bit me in the past. Hopefully, you'll get some wisdom to avoid these pitfalls.
What are standards?
First, to be clear about our terms: for this article, I’ll refer to technical standards and standards of practice.
Technical standards refers to requirements for the actual work or assets being made. For example, polycount limits, memory usage, file formats, etc. It refers to what is being made.
Standards of practice refers to how things are made. Things like methods of communication, officially adopted tools and software, recommended timelines, etc.
Technical standards can be very different from industry to industry. I'll speak to them broadly, but will dive a bit deeper into standards of practice.
The goal in either case is to reliably recreate success and to cut unexpected variables.
What happens if you don’t have good standards?
When I first started in the games industry, I was an animation intern. To get acclimated, I got familiar with our existing rigs and assets by looking through existing Maya files.
The trouble was, almost every character was different.
It was a small company with a team of seven artists, using outsourcing to handle the bulk of the asset creation. As it turned out, we used three or four different outsourcing companies.
Each company had their own method for creating rigs, animations, naming files, etc. No animations were reused between characters, and some animations were missing from our version control entirely.
Most of our tasks that summer were focused on standardizing our assets. For example, making sure each character had the same joint names, oriented the same way and so on.
We also made sure that we had a consistent naming scheme so it was clear which was the latest version of a file.
Another task was making sure the rig was referenced into the animation scenes. This way, if the rig got updated it'd populate to the other scenes automatically.
I was just out of college, but I was amazed that a company had launched games without locking these things down before.
It took weeks of work to organize everything, and in the cases with missing files, permanent damage had been done.
To this day, improving and creating standards is part of my job.
I’ve seen weeks wasted because people didn’t message when work was complete. I’ve seen artists spend days recreating assets they couldn’t find. I’ve seen games crash due to memory usage, leading us to discover that characters ranged from 3MB in size to 30MB, with some textures ten times over recommended resolutions.
It’s amazing what can go wrong if you don’t define best practices, or if you don’t enforce them.
It can cost you weeks of time, not to mention a good portion of your sanity.
Our process is a mess - what now?
So, you’re in a hole. You don’t know how work is being done, or it’s being done in ten different ways. What do you do?
First, identify the problems you want to address, and start ranking them.
What's the cost of the current process? What’s painful?
This'll likely be difficult to measure, but you can extrapolate from specifics you have.
“When you had to recreate that missing asset, how long did that take you?”
Or, survey your team - “how long on average do you spend looking for files each day?”
Once you have things roughly prioritized, look at the top issue and start to define what good looks like.
For our example, let’s say the most painful thing right now is documentation.
It’s either missing, or if it exists, no one can find it because it could be on one of five different internal wikis your company has used over the years.
What would good documentation look like? You'd probably end up with a list like the below:
- All documentation in one place
- Easily searchable/ browsable
- Clear ownership of who updates what
- Easy to understand
- Consistently organized
Once you have a draft of goals, socialize it with your team. Get feedback and iterate.
Once you’re happy with your goals, create a project plan to execute.
Give it a timeline, clear owners, etc.
Remember, creating a standard is a project worth planning and completing. The worst thing you can do is to half-implement a new set of standards, only to fizzle out and add yet another competing standard to the existing ones you were trying to unify!
Opportunities to look for
After working in a certain pipeline or process for long enough, it can be difficult to step back and see the opportunities to standardize. If you aren’t sure where to make improvements, here are some ideas of where to start:
When assigning work or starting on a task, there are several things you'll probably want to identify: the definition of done, the deadline, key customers, etc. Without a standard template or process to work from, it can be easy to forget to define some of these things. Having a template or example to work from can ensure the right questions get answered while also speeding up the task creation process.
If you work with digital assets, even text files, is there a standard organization to the content? If you’ve ever had to pick up other people’s files in progress, you’ve likely experienced frustration as you try to find your way around. Image layers are untitled, referenced assets are missing, etc. Identify these potential traps and define a convention for your studio to follow.
Is there a standard way to talk within your team? Is there a standard chat platform for your company? Having multiple platforms not only creates confusion, it also can have security implications. Teams may pick insecure channels to share information. If no one is monitoring these choices, this can go undetected for months or longer.
Memory Budgets / Technical Specs
If you work in software, you likely have someone at your company thinking about this already. But it’s still worth mentioning. If you don’t know the limits of your game or software, you can’t make informed decisions about the content you create. Know how much content is in your project and make sure you have a limit-per-asset that keeps the total within realms that won’t crash your users’ machines.
A lot of problems stem from unclear roles or ownership. Make sure that, if someone is transitioning into a new role, they have a clear description of their responsibilities and expectations. Make these widely available so others know what to expect of others on their team. If you have clear role descriptions for everyone on your team, you might even identify that there are parts of your process that nobody owns. This is a great thing to discover and correct!
I’ve seen this be a very inconsistent process on multiple teams. Make a plan for what happens for anyone joining your team. Identify things the new hire needs to know, and make a timeline so there are expectations of what will be taught when. Get granular - a date to introduce the hire to other team members. A checkbox for setting up their machine. A list of tools they’ll need to be trained in. A good standard for onboarding can vastly speed up the time it takes new team members to become effective.
I hope these examples give you some ideas of where to improve your process.
Remember: that which gets measured, gets done.
Have a plan of attack and a timeline for rolling out new standards. Also, don’t let knowledge like this live in your head; document your standards and make sure they’re visible to your teammates. Best of luck!