I once told Pixar that RealFlow was crap.
At the time, I thought my mistake was being too blunt. Twenty years later, I realised I'd made a completely different one.
It was 2008. My wife and I had just arrived in London, and I was a few interviews deep into a Visual Effects Technical Director role at Pixar. I'd already been through HR, and this was the technical interview. On the call was the head of the technical department, another senior technical lead who'd worked on WALL·E, and the HR representative I'd already spoken with.
At some point the conversation turned to RealFlow. It just so happens, I'd spent the previous few months living inside that software while freelancing at The House of Curves — using it every day, pushing it well beyond what it wanted to do, building tools around its limitations, and learning exactly where it broke. Pixar were considering using it on an upcoming film, and I later realised it was almost certainly Brave, with all its rivers, waterfalls, and splashing water.
One of them asked me a simple question: "What do you think of RealFlow?"
Without much hesitation, I replied, "Honestly? I think it's crap."
There was probably a pause. Maybe surprise, maybe curiosity. Realising how blunt that sounded, I immediately backed it up — walked them through every limitation I'd encountered, every workaround I'd built, every reason I'd reached that conclusion. My opinion wasn't based on hearsay or preference. It came from spending months trying to make the software do things it simply wasn't designed to do.
I walked away from that interview thinking I'd probably been too blunt.
For years, I assumed that was the lesson. It wasn't.
Two Layers to Every Question
At the time, I thought the interview had taught me something about diplomacy — about choosing softer words, or being less direct. But that's never really been who I am. If you asked me today whether I thought a piece of software wasn't fit for purpose, I'd still tell you.
The difference is that today I'd ask another question first: "What are you hoping to use it for?"
Experience has taught me that most conversations have two layers. There's the question someone asks, and then there's the problem they're actually trying to solve. Those two things aren't always the same. Back then, I answered the question. Today, I'd try to understand why they were asking it in the first place — were they looking for a recommendation? Validation? A technical critique? Someone who'd confirm the direction they were already heading, or someone willing to challenge it?
I never thought to ask.
Judging the Work vs. Understanding the Path
I've noticed the same shift in how I lead people. Twenty years ago, if someone produced work that completely missed the brief, my instinct was to judge the outcome. Today, my instinct is to understand the path that produced it — was the brief actually clear, or just clear to me? Had something changed since I last spoke to them that nobody flagged? Was this new territory for them, territory I'd wrongly assumed was familiar? Or did one small misread quietly send them down the wrong path?
Those questions have become far more interesting to me than the work itself, because poor work isn't always the product of a poor artist. Sometimes it's the product of poor communication, missing context, or poor leadership. The work is simply where the symptom becomes visible. Once I understood that, my job changed — it wasn't to judge the work, it was to understand the path that produced it.
Ironically, that's exactly what I failed to do during the Pixar interview. I judged RealFlow. I never stopped to consider why they were asking me about it, what they already knew, or what problem they were trying to solve. I answered the question. I never really understood the conversation.
Looking back, I don't think I was wrong. I just wasn't curious enough.
Where This Doesn't Hold
I don't want to turn this into some universal rule. Sometimes the work really is just the work — someone wasn't right for the task, didn't put in the effort, or simply wasn't capable of producing what was needed. Not every bad outcome has a hidden systemic cause, and searching for one when it doesn't exist only delays a conversation that needs to happen.
The point isn't to assume the path always explains the outcome. The point is to understand the path before deciding whether it does.
These days, when someone brings me work that isn't what I expected, I rarely start with the work itself. I start by trying to understand how they got there — because if the brief was unclear, the process was broken, or the context was missing, correcting today's work doesn't solve tomorrow's problem. Fixing the path does.
I don't think I've become less honest over the years. If anything, I've become better at understanding what honesty is supposed to achieve. These days I spend less time judging answers, and far more time trying to understand the questions that produced them.
← Back to Articles