Fences

The Programmer-Designer Fence

Tim's first and most personal example comes from being both a programmer and a designer throughout his career. As a designer, he understood that specifications change — you can't simply write the perfect design doc and hand it off. Yet he's worked with programmers who want to code something once and get angry when the spec changes.

The Bug Analogy

Tim found an effective way to bridge this gap by speaking to programmers in their own language. He'd point out: "You've written code and later found a bug that needed fixing. Why can't the designer find a problem in their spec and fix it?" Programmers understood debugging their own code, but couldn't make the leap to seeing that design documents can contain "logical bugs" in how features interact.

The Point Release Argument

His most persuasive argument involved middleware updates. He'd remind a programmer: "Remember when you asked for a month to update to a point release of our middleware, even though it gave us no new features we'd use?" Tim had to explain to designers that the programmer wouldn't be available for a month with nothing visible to show for it. If programmers can accept that updating underlying software is worthwhile, they should understand why a design doc changes to make the game more fun.

The Leader-Team Member Fence

Tim has led teams in multiple capacities — producer, project leader, game director (titles that changed across decades but often meant the same thing). The leader typically holds the vision for the game and must communicate it effectively.

He describes having to explain the game's pillars in team meetings, strike team meetings, and one-on-ones, connecting specific features back to the core vision. When a team member suggested a different approach, Tim would ask: "Do you disagree with the pillars, or do you disagree that my feature supports those pillars?" — forcing the conversation to a productive level.

From the other side, he's been the team member going to a leader saying, "This feature doesn't seem to jibe with your vision." He once worked with someone who, when challenged, simply repeated themselves word for word — assuming Tim didn't understand rather than engaging with his actual objection.

The Employer-Employee Fence

Tim calls this one "a fence people rarely cross," but he's crossed it — running his own company (Troika Games) for seven years. He's heard employees say managers are incompetent and managers say employees are lazy. His verdict: "In general, both of those people are wrong. However, both of them had specifics that they were right about."

He's seen genuinely bad managers (untrained, unclear on their role, or unwilling to do the work) and genuinely bad employees (full of excuses, never at fault). Both are frustrating. And while people argue managers can do more damage, Tim has seen popular employees cause massive rot by normalizing a culture of blame-shifting — "it's not my fault" becomes contagious.

The Gamer-Developer Fence

Gamers call developers "stupid and lazy." Developers call gamers "whiny babies who don't know what they want." Tim has been firmly on both sides. He notes that gamers will say they hate a feature, then praise a different game for the same feature — what they actually hated was the implementation, not the concept. But they can't articulate that distinction.

Meanwhile, developers stop listening after the thousandth person calls them a stupid lazy idiot and sends death threats. So when a gamer with legitimate feedback finally shows up, the communication channel is already "gummed up" with garbage.

The Core Problem

Having been on both sides of all these fences, Tim identifies the universal pattern: people on each side would rather feel better in the moment — venting anger and frustration — than actually try to improve things and feel better in the long run. Both sides do this.

People who don't understand the other side make arguments that are "so wrong they can't even be addressed" — showing a fundamental misunderstanding that makes you not even know where to begin.

Tim's Prescription

Best Option: Do the Other Side's Work

Actually cross the fence. If you want to understand why programmers are telling you something, learn to code and try coding the thing you're complaining about. If you think design is easy, try writing a design doc. Tim has thrown that challenge out and received "the most hideous design docs I've ever seen."

He's tried it himself with art — he made a mouse cursor for one of his games and the art director threw it out the next day. ("I thought it was pretty good.")

Second-Best Option: Talk and Listen

If you won't do the other side's work, talk to people on that side and believe what you're hearing. Talk to many of them to get a consensus, because some will be complaining about their perception of your side rather than explaining their actual issues. You're trying to understand their real problems, not their complaints about you.

The Grass Metaphor

Tim extends the classic saying: the grass isn't always greener on the other side, but it isn't always browner either. "It's just different grass. And maybe you don't like that grass as much." When people want to leave a company, he always tells them to talk to people who already work at the new place — because things you hate here might also be there in abundance, and things you take for granted here might be absent.

Beyond Games

Tim acknowledges this applies far beyond the game industry: "I think I just explained a lot of problems that we have in today's society." The universal issue is that limited communication bandwidth across fences gets clogged with unhelpful noise, preventing the constructive exchange that would lead to better outcomes for everyone.

References

• Tim Cain. YouTube video. https://www.youtube.com/watch?v=fIj8az5HPds