Christopher Latham Sholes, the Milwaukee newspaperman behind the first practical typewriter patent in 1868, wasn’t a novelist chasing flow state. He was a printer and editor staring at chaotic, manual workflows and deciding to hack them with mechanics and ingenuity. He wasn’t “just” a publisher, or “just” a politician, or “just” an inventor, or a formally trained engineer of any kind; he lived in the overlap, and that overlap reshaped how work gets done.
He fits the description of a multifaceted thinker who excelled in several distinct fields; journalism, high‑level politics, and mechanical engineering learned through practical experience and self‑taught skill—born from the necessity of improving his own trade.
A lot of my career has felt like a smaller version of overlaps like these. And if Jeremy Gutsche is right in his book Exploiting Chaos, that times of disruption are when you’re supposed to smash molds and let the multi‑passionate weirdos loose; then this is exactly the wrong moment for studios to shove people back into single, safe lanes and lean hard into specialization. Game development is heading into a new renaissance; we need smaller teams and more multi‑talented people to fill them (history doesn’t repeat itself, it rhymes.)
Why I’m writing this
I am a chameleon. I am the changeling. I don’t fit a mold. I’m a multi‑passionate polymath and autodidact: educated in digital arts, self‑taught in most of the engineering, tooling, and systems work I do today. My value is in connecting disciplines and turning that breadth into practical systems that artists, designers, and engineers actually enjoy using.
On paper, a lot of modern studios say they want the same thing.
They talk about T‑shaped, or W-shaped, or π-shaped people, cross‑functional collaboration, “connecting the dots.” They say they want folks who can bridge art and engineering, who can translate between disciplines, who can see the whole system instead of just their little slice.
That’s who I am. That’s the work I’ve been doing for decades. (Another day I could also tell you how this has made interviewing for new roles really difficult.)
In practice, though, many organizations are still wired for specialists. The ladders, the titles, the politics, the unspoken rules are all built around single‑lane identities. You are an Engineer. You are an Artist. You are a Designer. Step outside that, and things can get awkward and high-friction quickly.
I remember when you “couldn’t mix game genres.” I wanted a run‑and‑gun with an escape sequence and a car chase. People told me it was impossible, that it would never work. Then games like that became normal. Change is inevitable and you can’t halt progress. We live in a genre‑bending world now. I’d go further: access to AI used in ethical ways can accelerate learning and help turn anyone into a multi‑passionate and/or polymath, and the old molds are cracking around every role, anyway, as a result.
This post isn’t a hit piece on any boss or studio. It’s not about any previous employer, or about any single recent layoff, a single quip, one bad conversation, a manager, or a failed project. It’s not actually about engineering or any other one discipline; it happens in many verticals and relationship dynamics. It’s a recurring pattern I’ve seen and experienced over and over, across companies and years. Some of it happened in games. Some of it happened in big tech. Some of it hurt in the moment, and some of it I only realized years later.
What I’m trying to do here is put language around that pattern: how lane‑policing phrases like “stay in your lane” collide with psychological safety, how they quietly push polymaths and multi‑passionate people back into smaller boxes, and how that breaks the exact kind of work we say we want to do. I’ve experienced it, I’ve watched it happen to others, and I’ve had people quietly confide the same frustrations. I’m just one voice among many. In the rest of this piece, I want to unpack what lane‑policing actually looks like on teams, how it erodes psychological safety, and what it would take to build studios where people like us can operate at full scope.
This is my story, but if it resonates, it’s probably not just mine. And if you catch yourself thinking “is he talking about me?” It’s not personal, and you’re definitely not the only one. But yeah, that’s a pretty good sign you’re exactly the audience I’m writing to.
Hard truth: I have been guilty of doing this myself, unintentionally putting someone in their place and eroding that psychological safety; we can all do better.
You don’t have to be an engineer to see the whole system
I’ve lost count of how many times I’ve heard some version of “you’re just an artist” or “stay in your lane.” It almost never shows up when you’re doodling on the edges of a problem. It shows up when disciplines actually need to overlap: large worlds, tools, pipelines, production reality. It shows up when someone gets uncomfortable that the “artist” in the room has opinions about things they consider purely “technical” or purely their domain.
When leaders say things like “you’re just an artist,” “stay in your lane,” “let the engineers worry about that,” or “that’s not your concern,” they’re not just being blunt. They’re doing what organizational psychologists would call suppressing voice by enforcing rigid role boundaries. I think of these as lane‑policing phrases: little verbal fences that tell you your perspective isn’t welcome outside your job title. They’re attempts to prematurely optimize complexity out of the conversation.
I started my career as a 3D artist. Over the last few decades I’ve been an artist, designer, director, producer, product manager and I’ve been embedded deeply within engineering teams. I’ve shipped games, built tools, and released engines. My current job title has the word “Artist” in it, but the work is fundamentally cross‑disciplinary: connecting what art, design, engineering, and production say they want with what the tools and tech can actually do at scale.
My lane is the spaces between other lanes.
So when someone looks at that and still says “you’re just an artist,” what they’re really saying is: “I don’t have a mental model for people who cross boundaries, and that makes me nervous.” That nervousness has a cost: it teaches anyone who can see across lanes that honesty is dangerous, which is the opposite of psychological safety.
What lane‑policing actually does
People who defend “stay in your lane” tend to say it’s about efficiency.
They say things like:
- “We just need people focused on their own discipline.”
- “Too many voices slow us down.”
- “If everyone comments on everything, nothing gets done.”
On paper, that sounds reasonable. Clear ownership matters. Infinite bikeshedding is bad. Nobody wants a room where every minor decision turns into a 20‑person design review.
In practice, lane‑policing usually isn’t stopping chaos. It kicks in when someone crosses an invisible status boundary.
You don’t hear it when an engineer comments on art. You don’t hear it when design critiques narrative. Or when artists critique each other’s work. You hear it when someone not in your vertical or inner-circle you trust has unexpected feedback. You hear it when someone from a “lower‑status” discipline (in that person’s head) shines a light on risk, complexity, or tradeoffs in the “higher‑status” discipline. That is not about efficiency. That is about ego protection.
Here’s what those lane‑policing phrases actually buy you:
- People stop telling you the truth about your ideas.
- Problems get buried early and come back later when they are expensive.
- Hybrid roles like Tech Art, Tech Design, Tools, or Production get quietly punished for doing their job.
Often critique flowing into engineering from other disciplines is treated as overreach, while critique flowing out of engineering into other disciplines is treated as normal “engineering bias”.
The longer you work on complex games – large worlds, systemic content, intricate pipelines – the more obvious it becomes that interesting problems don’t live inside one discipline. “Engineering only,” “art only,” “design only” problems are rare. Reality cuts across everything: tools, workflows, content, schedule, mental bandwidth.
If you tell someone who lives at those intersections that their input “isn’t their concern,” you’re enforcing a boundary that makes the work worse. You’re asking them to stop doing the thing you actually need them for.
Everyone else sees it. Once they see that voice gets shut down whenever it crosses an invisible role line, they learn quickly. Keep your head down. Do your narrow work. Let the train hit the wall. Those teams don’t lack talent. They lack permission. And without permission to speak across lanes, “psychological safety” is just a slogan on a slide.
Psychological safety, translated to game dev
There’s a term for that permission: psychological safety.
In plain language, psychological safety is the shared belief that it’s safe to take interpersonal risks on your team. Not “nice,” not “easy,” not “conflict free.” Just safe.
In game development, those interpersonal risks look like:
- Telling an engineering lead: “This large‑world tooling approach won’t survive real production, here’s why …”
- As an artist, asking: “Why are we optimizing this thing no one will ever see, instead of the thing that is killing iteration?”
- As an engineer, telling design: “If we do this system the way it’s described, players will break it in five minutes.”
- As QA, telling everyone: “This part of the game falls flat, it might not be fun.”
Those are risky moments. You might be wrong. You are exposing gaps. You are poking at someone else’s decisions or identity. Without psychological safety, most people will only do that when the pain of not speaking up finally outweighs the fear of the reaction. That is almost always too late. That’s when the amygdala hijack happens: fight‑or‑flight instead of a real conversation.
Lane‑policing is a clean way to kill that safety. It does not just shut down the current comment. It broadcasts:
- “Input across disciplines is not welcome.”
- “Your role defines the ceiling on your insight.”
- “If you see a landmine outside your box, step over it quietly.”
If you say you want innovation, fewer late‑stage disasters, and better games, this is the opposite of what you need. You cannot have psychological safety and lane‑policing in the same room; one will kill the other.
Early‑career safety vs mid‑career safety
The funny thing is, I didn’t really run into this early in my career.
Back then I was “the artist who can script a bit,” not the person connecting art, tools, engine, and production timelines in one mental model. People were mostly happy to have extra hands and desire to optimize my own workflows. If I poked at something outside art, it read as enthusiasm or curiosity. I could ask “dumb” questions and nobody felt their authority was on the line. They just answered and moved on.
That is one kind of psychological safety: safety to be new, to learn in public, to say “I don’t know” without getting punished.
Later, the dynamic changed.
I became very technical. I had shipped many games. I’d managed departments and whole teams, projected P&Ls, restructured server contracts, wrestled with Agile. I’d built and maintained tools. I’d lived inside engine and content pipelines. I’d watched large worlds succeed and fail for specific, repeatable reasons. When I spoke up, it wasn’t coming from “eager junior” energy anymore. It was coming from someone with receipts.
That is when lane‑policing showed up more often. Mid‑career. In places that advertised excellence, but flinched when someone crossed old discipline lines.
At that stage, psychological safety means something different:
- It is not “Can I ask basic questions?”
- It is “Can I say the thing everyone quietly knows but doesn’t want to say out loud?”
- It is “Is my cross‑disciplinary perspective seen as part of my job, or as a threat to whoever thinks they own this space?”
When a senior hybrid person in Tech Art, Tech Design, Staff/Principal (anyone) gets hit with lane‑policing, the message is not “focus.” The message is: “Your scope makes me uncomfortable. Please shrink, so I don’t have to expand my model of this team.”
Early‑career ‘me’ needed safety to admit what I didn’t know.
Mid‑career ‘me’ needs safety to say, “I do know, and we are headed into a wall if we keep going like this.”
That second kind of safety is rare. It is also the kind that keeps big, ambitious projects from quietly bleeding out. If you want late‑stage truth instead of late‑stage surprises, you have to protect mid‑career lane‑breakers when they say the thing nobody wants to hear.
How we start fixing culture
I don’t want to just complain about the mess. I helped build parts of it. I’ve benefitted from it. So here’s what “fixing it” actually looks like to me, in plain terms.
First: make psychological safety non‑negotiable, not decorative. That means people can say “this isn’t working” or “we’re headed into a wall” in the real room, not just in DMs. It means leaders model it by going first: “Here’s something I was wrong about,” “Here’s a bet I’d change with what we know now.”
Second: kill lane‑policing on sight. Any time someone shuts down cross‑disciplinary input with “that’s not your concern” or “stay in your lane,” treat that as a bug, not a leadership move. Redirect it into evidence: “Okay, what are you seeing? What data or experience is behind that?” Over time you want a culture where who said it matters less than what they’re pointing at.
Third: rebalance engineering bias instead of pretending it isn’t there. Let engineering keep its real job: guarding hard constraints, calling out technical risk. But write it into the culture that design, art, production, and player data are just as “real” as perf graphs. If a solution is technically elegant but wrecks iteration or comprehension, it’s a bad solution. Period.
Fourth: design for polymaths instead of accidentally rejecting them. In org charts, promotion criteria, and leadership meetings, make “connects disciplines and sees end‑to‑end systems” a first‑class skill, not a side hobby. Give those people real scope and a mandate to ask cross‑lane questions without having to apologize for it.
Fifth: make the behaviors explicit. Write down the tenets you actually believe in: “We criticize work, not worth,” “Anyone can raise a concern about any pillar,” “Discomfort is data,” “We change our minds in public.” Put them where people can see them, and enforce them the same way you enforce performance bars or code quality.
None of this is magic. It’s just deciding, as leaders and teams, that the way we’ve been doing things is giving us exactly the results we’re seeing: burned‑out people, safe ideas, wasted talent, and games that don’t live up to what they could have been. If we want something better, we have to change how we behave when it’s uncomfortable, not just what we print on the slide.
This is the personal layer: what it feels like to be a lane‑breaker in a system that says it wants you and then flinches when you actually show up. In Part 2, I’m going to pull the camera back and talk about the bigger forces that make this worse or better: fake safety vs real safety, engineering bias, and why stewardship and invention need different kinds of courage.
Jonathan Galloway is a polymath technical art leader who bridges art, tools, engine, and AI to help teams ship large, beautiful games with fewer headaches. A 30+ year AAA veteran with deep roots at Sony PlayStation, he specializes in technical art, real‑time rendering, Python tooling, and procedural worlds. Equal parts artist, engineer, and systems thinker, he turns messy pipelines into creative playgrounds where technology actually serves the people using it.