This is the start of (hopefully) a series on what I've learned in the game industry over the past six years. The first topic is...
Assume but Verify Competence
 |
| Don't assume everyone is like this. |
Don't be the guy that assumes that somebody is bad at their job. This can lead you to distrust the people around you, and cause those same people to distrust you, because it's always obvious when someone else has the attitude of, "I don't think you know what you're doing." Assume everyone is competent, but then verify that this is true. Here's an example:
A designer is making a mission and you're reviewing it. You see a portion of the mission takes place on a seemingly unreachable part of the map.
Nothing you can think of will get a player to that area.
You have a few ways to approach this:
A) Tell the designer, "Change that part, players can't get up there."
B) Assume the designer knows what he's doing, say it looks good, and walk away.
C) Ask the designer, "How do you plan on getting players up to that part of the map?"
 |
| Option D, remain silent and walk away. |
Option A assumes that the designer doesn't know what they're doing. It's you asserting authority and telling the person they're wrong, and also subtly suggesting that you know everything there is to know about the engine.
Option B assumes competence but doesn't go through with "verify." You just assume that the designer knows what they're doing, and move on. This can lead to you getting burned if the designer did in fact make a mistake, and eventually you will assume that no one can be trusted.
Option C puts the power in the designer's hands. You assume they have a plan and perhaps they know something you don't know. You're curious about how they're doing to deal with this seemingly impossible problem.
This opens up many possibilities for dialogue. The designer could inform you about a new trick they learned, or a new piece of tech that was put in that you didn't know about. You could walk away from the conversation having learned something.
On the other hand, if the designer did make a mistake, they could tell you that they didn't realize players couldn't get to that map. At this point, you can work together to solve the problem, and the designer walks away from the talk having learned something.
 |
| Someone will learn something. |
All of this boils down to you assuming that you might not have all the information needed to make a decision about something. I initially dismissed this lesson as just office politics that I didn't want to deal with. However, if you assume someone doesn't know what they're doing and they actually do, then it creates a really negative stigma against you. People begin to mistrust you because it's obvious you mistrust them.
 |
| Everyone starts lying to each other and it becomes an episode of Arrow. |
This simple lesson can make or break an entire team. If a lead designer doesn't assume competence, it can create a terrible environment where the lead assumes they are always right and then enforces their own design decisions on the people beneath them without any discussion. The higher up they are, the more damaging it can be.
I was initially going to write all the things I learned, but it turns out I like talking more than I thought, and this blog post is long enough, so I'm going to save the second bit for next week's post.
Stay tuned next Monday for the second part of this series, "Lessons Learned - Skill Isn't Enough."
PS: Assume Competence does not extend to driving. Assume no one knows what they're doing behind the wheel.
|
| Assume everyone else driving is like this. You'll live longer. |
