In ‘Design and Impostor Syndrome’, I said:
“ Designers seem plagued by the notion that they’ve somehow tricked their way into their positions, fooled hiring managers into believing their facile bullshit is actual skill and experience.”
I want to explore where this notion comes from, and why it’s so corrosive to game development and good design. It’s important, because when designers cannot advocate for design itself, as a discipline, as a craft, and as a set of practical skills, they also cannot advocate for specific good design choices.
The truth is, all designers are impostors.
Nobody working in game design has any idea what they’re doing.
Soft Skills vs Hard Skills
There’s a metric that I think is applied whenever game design, specifically (though other fields of creative work suffer under it as well, and I’ll talk about them in a bit) is discussed as part of the overall value proposition of a game. I think of it as the ‘Sister’s Nephew’ metric, and if you’ve worked in tech fields around non-technical people, you’ve probably seen it in action.
For any task that needs to be completed on a project, could a sufficiently ill-informed manager or executive assert that his sister’s nephew could do the work quickly and cheaply?
When I’d just gotten out of college, back in the midst of the dot com boom, this most often manifested as small business owners outsourcing their entire web presence to a young relative who was ‘good with computers’. The corpses of their efforts still litter the Internet Archive, with their bizarre and eclectic formatting and choices of graphical elements. The ‘under construction’ gif is an artifact of this era, where the people commissioning these attempts at web design knew something wasn’t right, but couldn’t put their fingers on what.
Game development, for all it’s a billion-dollar industry, is absolutely crammed full of the sorts of work that an executive believes can be farmed out to a relative, or an amateur they worked with once, or a friend who’s between jobs but ‘knows about this kind of stuff’. The biggest of these, of course, is the community management team, which is often saddled with — or entirely staffed by — people whose only qualifications are that they have a twitter account and they’re ‘good with computers’. Sister’s nephews, in other words.
(Community management, as an aside, is a very real discipline with real impacts on the game’s bottom line; it is not just an arm of marketing or sales, and it is not a job that can be competently performed by amateurs. I’m not qualified to talk about it at length but: the community managers I’ve worked with have been skilled and effective professionals.)
I’d like to think that nobody is actually saying the words ‘how hard can it be?’ out loud, or at least not where anyone who cares about the game’s success can hear. But I know some of you are thinking it. It’s the rallying cry of the micromanager: “I’d do all these tasks myself, if I had more time. None of them are very hard. Your job exists only because there aren’t enough working hours in the day for me to do it personally.”
Community management is usually the biggest casualty, because every manager believes they have what it takes to talk about the project with the fans. Only after this approach leads to some level of disaster does anyone consider that maybe managers, project leadership, or studio leadership aren’t qualified to do that job effectively.
Test is another frequent victim of this tendency. The number of fans who believe that their gaming experience is sufficient qualification to be a member of the QA team is alarming. I’ve talked at length before about how critical QA is to the game development process, so I’m not going to dig further into it right now, but the sister’s-nephew problem is in full effect in the QA department. Testers are often brought in late, sometimes too late to have any meaningful impact on the project; they’re often understaffed and underbudgeted, and they’re often triaging what kinds of test work they even have the resources to do, from their first day on the project. If cuts are needed, it’s testers that are let go.
Writing is a common victim. Reality television producer Jon Collins has written a series of funny but also deeply painful blog posts that I highly recommend. Every time his network executive character says ‘it’s storytelling 101!’ I die a little inside, thinking of the writers who have to put up with this ignorant bullshit.
There’s a common thread in all of these fields: ‘Anyone can do that.’ Anyone can write — after all, everyone writes emails, don’t they? Anyone can test — we’ve all played games and encountered bugs, after all. Anyone can manage communities — it’s just talking to fellow geeks on the internet, right?
And usually when they say ‘anyone’, what they really mean is ‘I’. ‘I can do that. I can do that as well as you can. Your professional accomplishments are probably just luck and good self-promotion. I am as a good a writer as our writing team.’
A little knowledge can act as a force-multiplier on this tendency. Most managers won’t claim to be able to step in for the artists, because most managers don’t claim to be artists. But a little art experience and they’ll think of themselves as an art critic writing for the New York Times. They’ll talk about whatever art terminology they’ve internalized, pointing out things they think they’ve noticed about the work without really having a grasp of the process that led to the finished work. I will never forget the feedback one of my UI artists received from our license partner: ‘This menu should be more edgy.’ To this day I’m not sure what they meant by ‘edgy’ but we just kept throwing new variations of the design back to them until they agreed we’d met the ‘edgy’ quota.
As a survival strategy, avoiding this nonsense when talking to programmers seems critical, and for the most part managers don’t harass the coding team. Presumably, those who did all failed so spectacularly that they’ve been run out of the industry. But I’ve seen far too many non-technical managers invite themselves along to a technical meeting, and then use up a quarter of the meeting’s time trying to tenuously connect some detail of the project’s underlying architecture to a concept they understand, so as to seem engaged and attentive and On Top Of Things.
The more difficult it is for a manager outside a discipline to insist they, or their sister’s nephew, could do it just as well as the professionals, the more I think of that discipline as a hard skill. You can’t fake programming knowledge for long; ultimately, you have to write code. As someone who’s lost a programming job because she didn’t know enough to write the code, I assure you that you can fake it for only a little while.
You can’t fake art skills. If you can’t model a character, you won’t be able to pretend to model one for very long. If you can’t draw, you can’t make concept art. If you can’t animate models, you can’t fake being an animator. In all these cases, of course, you can muddle along and maybe get away with it for a while, but ultimately your inability to produce usable work is going to expose you. Art is a hard skill; if you can’t do it, you can’t really fake it.
Test rides the line between hard and soft skills; it’s a rigorous discipline with standards and best practices, and there are right and wrong ways to do it. But it’s also a soft skill in that without a test manager who knows all that stuff, you can probably sneak by with ‘play the game, file bugs’ as your basic approach. If nobody insists on rigor, you can absolutely ship a game without any rigorous test practices. It will be a mess, but you can ship it.
Writing is even softer, because everyone believes they can write well, or would be able to if they simply put in a bit of effort. My partner is a writer, and I’ve seen the kind of difficult work she does on every one of her novels; it isn’t the same as writing an email or even writing a series of game design essays on Medium. It’s a serious craft. But at the same time, I’ve read the jumbled nonsense garbage to come out of the bottom of the genre fiction barrel, and I’ve seen how well it sells. Writing can be faked. Bad writing is obvious to people who care about writing, but as long as the criteria remains ‘grammatically adequate English’ and ‘enough word-count to seem significant’, writing remains a soft skill.
Design is the softest of all the skills in game development.
Because everyone believes they know what makes for a fun game.
Everyone. Every person who plays games knows, deep in their bones, what makes games fun. Everyone on the team — writers, testers, artists, programmers, managers — knows how to design the game, knows what good and bad design looks like, knows how to make players engage with the game, knows what will be fun and what won’t.
Don’t believe me? After lunch, before anyone goes off to meetings, start a conversation at work with a random assortment of people, about a recent game you’re playing. Listen for how many of the comments in the conversation are about the game’s design. Not the art, not the bugs, not the game’s stability — the design. It will be almost all of them. And everyone who knows the game will leap in with their thoughts, regardless of discipline or experience.
Anyone Can Design
In high school, I was a varsity swimmer; my event was the 100 breaststroke. I was okay, but not great; I came close to qualifying for the state championship which is relatively challenging to do in California but I wasn’t really even college-team material, and I didn’t continue swimming after graduating from high school. Still, being as good as I was, even in the mediocre range of competitive swimmers, meant that I learned a lot of the skills of a competitive swimmer.
There’s a notion that athletic skill falls into two distinct areas: knowing what to do and being able to physically do the thing. This is where the idea of the ‘armchair quarterback’ comes from — someone who believes their knowledge of football could, if only they had the physique, translate into success at playing football. ‘That’s easy,’ they say. ‘I could do that if I was built like him.’ Particularly when someone has seen a skilled activity well-executed over and over, they have a tendency to overlook how astonishing that activity really is. ‘I’ve seen better’, they think.
What I learned from swimming was that knowing how to swim wasn’t half the problem solved. Being fit and muscular and having enormous lung capacity wasn’t the other half of the problem solved. At every moment of every event, there was a dizzying array of skilled activity happening, and it all had to happen naturally and quickly and without thinking and it all had to be integrated together seamlessly. How you stood on the blocks. How you loosened up while waiting for the mark. How you tensed to anticipate the gun. How you entered the water; how your first underwater stroke was angled and where you’d first break the surface (I lost, and won, a lot of events just based on the first underwater stroke). How you took your breaths and when. How you moved your hands during the return part of the breaststroke, to minimize resistance. How you took the turn, what angle you pushed off at. How often you stroked and kicked. How you reserved your air and energy, and when you spent it, and what you spent it on.
It’s a lot. It’s a complex set of skills, and each of them was learned and reinforced through constant practice. They were consciously learned, and we’d do focused sessions on just one element of the overall skillset, practicing turns or starts or whatever, over and over again, refining and polishing that tiny element until it was bone-deep knowledge.
Any abled person who’s taken swim lessons can swim. Any abled person can run. Any literate person can write.
Any gamer can do game design.
The gulf between the level of performance possible for ‘anyone’ and that possible for the person who’s learned all the specific techniques that apply to each moment of the activity is the gulf between the armchair quarterback and Colin Kaepernick.
For some activities, we expect a qualified professional to come with certain bona fides. We want our doctor to have a medical degree from a reputable school. We want our lawyer to have passed the bar exam. We want our climate scientist to have a PhD. We want certifications and guarantees of competence, and we want those guarantees to be vetted by large professional organizations.
Where no certifications exist, though, we’re in a murky place. What do we want to know about our game developers? We’d like the programmers to have bachelor’s degrees in computer science, but that’s not a hard requirement. Degrees from art schools are nice but we also recognize that almost all art schools are for-profit and attending them is something only a fraction of skilled artists can afford.
There’s no certification for game design.
There are degrees, of course; locally, Digipen offers one, and Full Sail does as well, and a large number of technical schools and art schools have game design degree programs. But most of us in the industry have very little sense of what, practically, is being taught there. When people ask me how to break into the game industry, I tell them to make games. I don’t know if the people getting game design degrees are making games or not. In fact, all I really care about from a game design degree program is whether the person with the degree has a portfolio and can speak intelligently about the games they’ve made — roughly the same as what I look for in someone without a degree.
Really, the only certification for game design is ‘you’ve made a game’.
That makes the whole field both restrictive to the point of elitism, and open to the degree that anyone can assert themselves as a game designer and be believable.
My boss has made several games. Is he a game designer? Do I defer to him, knowing his games have been moderately successful? I don’t know what he actually did on those games, but he worked on them, so that counts for something, right?
I’ve made several games. Am I a game designer? Should I insist on being heard on the strength of my expertise? My games have been moderately successful. What part of that success was thanks to my personal contributions to the game?
All Designers Are Impostors
Every one of us. We’re all lying. The truth is, there is no objective measure of game design skill or experience, and we all know that the only difference between us and a typical fan on the internet with thousand-word design suggestions is that someone trusted us enough once to pay us money to design a game.
There’s a notion in psychology called attributional bias. It’s the idea that we incorrectly attribute the cause of actions taken by ourselves and by others. It may be that we assume other people are ‘just bad’ instead of perhaps having a bad day; we may assume that we failed because of bad luck rather than anything specific we did. We aren’t necessarily wrong, but we’re not arriving at these conclusions objectively.
A particularly nasty form of this bias is the inverse of something called the self-serving bias, which is the natural tendency we have to attribute our successes to ourselves, and our failures to others. When inverted — which is common with people suffering from depression — this becomes an ugly condemnation of our self-worth. “I only succeeded because I got lucky,” we think. “I’m not a good designer; I just had a good team and a good project.” Conversely we tell ourselves that other people around us are smart and skilled and talented. “She succeeded because she’s smart and capable,” we think. “She’s a good designer; look at the amazing stuff she put in this game.”
This inverted bit of bias is the reason so many of us suffer from impostor syndrome. We assume our victories are due to chance. We see people who are smart and talented and we compare ourselves to them, and the bias tells us that they’re the Real Thing, unlike us, because we’re just faking it.
And how can we counter the sense that we’re ‘faking it’? We have no certifications, we have no degrees, we have no examinations by professional organizations. We have shipped games, but we know that was just luck, or the rest of the team, or the IP, or the marketing department. Shipped games tell us nothing, because we know people on those games who were bad designers, and they get as much credit for the game as we do.
We don’t know how to trust ourselves. We don’t trust that we’re good designers. We have nothing solid on which to ground that trust.
That’s bad, but what’s worse is that nobody else trusts us, either.
Trusting Designers
When I talk about trust in this context, I mean specifically believing that a skilled designer will be able to identify good and bad ideas, will exercise judgement and find compelling gameplay through that judgement. I don’t mean trusting a designer to write decent specs, or take control of a meeting, or make a good slide deck. Those are incidental skills; I’m talking about the deep heart of what a designer is doing for a game.
I’ve worked at more than one game studio that openly distrusted designers. Where every design decision was passed through a half-dozen layers of creative control, filtration, and modification before it was approved. Where the reaction to a clever idea was not enthusiasm, but rather suspicion.
Working in that kind of environment wears on you. You’ve only brought one thing to the table: your judgement, your ability to identify good and bad ideas. That’s it; that’s what you’ve sold to the company when you sold them yourself. Otherwise you are, as I said in a presentation on specs, just a technical writer with delusions of grandeur. Technical writers are skilled professionals but they’re not game designers, and there’s much less of a trust requirement when working with a technical writer.
Every day your judgement is questioned, every day your ideas have to go through multiple layers of vetting by non-designers, every day that you’re reminded that everyone else in the world thinks they’re designers, and can do your job just as well as you can, is another day of having that deeply held attribution bias reinforced. They’re smart; you’re stupid. They know how to make games; you’re just an impostor.
Give it long enough and it will become true. You’ll self-edit on your way to exercising your judgement. You won’t say ‘that’s a bad idea’ because you recognize that someone higher up in the chain of creative leadership thinks it’s a great idea, and you know that you’re just an impostor anyway, so what makes you so sure you know better?
Remember: your judgement about games is the only thing you’re offering to the company in exchange for your salary.
When that judgement is attacked and called into question repeatedly, when it’s eroded by constant second-guessing by armchair quarterbacks, you’re losing the only thing you brought to the table. You’re no longer able to function as a game designer, because that judgement was literally the only difference between you and the technical writer.
Once you’re convinced to doubt your own skills as a designer, you’ve lost. You will never again be able to take creative ownership of anything on that project, with that team. It just takes one moment of ‘what the fuck makes me think I know better than them?’ to bring your whole fragile edifice of certainty in your own hard-earned skills down. The first time you believe that micromanagement from a non-designer is warranted, justified, or a good use of anyone’s time, you’re no longer a designer.
It’s that tentative. It really is. A designer brings judgement to the table, but the team’s leadership has to bring something as well: trust. They have to trust your judgement.
Which seems obvious, right? If you hire someone for their judgement, you must believe in that judgement, right? You must have some basic level of confidence in their ability to tell good ideas from bad ones, to pursue good ideas and shut down exploration of bad ones?
If not, why did you hire a designer at all? Technical writers are far cheaper.
It’s Not Me, It’s You
If you’re a designer, and you’re feeling this self-doubt, please keep in mind that it isn’t about your skills or judgement. The essential foundation of your identity as a designer, the very thing that lets you function despite the constant yammering voice of impostor syndrome, is under attack. If you can’t function under those conditions, it should come as no surprise to anyone.
I wish I could tell you how to fight back against it. I wish I could give you an answer and a happy ending. Unfortunately, my experience is that you’ll either have to suffer working at vastly diminished capacity… or you’ll push back one time too many against it, and you’ll be asked to leave. Insisting that you be allowed to do the job for which you were hired is not going to make you any friends among the people who are keeping you from doing so… and those people are largely the same as the ones who decide if you get to keep your job. They hired you for your judgment, but they never had any intention of letting you exercise it; they just wanted your rubber-stamp agreement with their own ideas, and as non-designers, they can’t easily tell the difference between good and bad ideas. You’re in a no-win scenario.
If you’re hiring or employing designers, I want you to take a step back and ask yourself: why did I hire a designer? Why did I hire this designer? What did she say or do that made me think she’d bring value to the project? What was her track record, that I thought she would help rather than hinder our efforts?
Do you trust your designers? Do you trust their judgement?
If so, stop eroding it. Stop attacking it. Stop damaging the one thing of value they’ve brought to your team. Imagine bringing in outside contractors to review all the programmers’ code; imagine what a waste of time that would be, and how demoralizing that would be. Imagine how your programmers would react to that.
You’re doing that exact thing to your designers.
Cut it out, and let them do their jobs.
