I say “Approaching the Pipeline” because this topic contains mountains of technical discussions, philosophies, and department-by-department specifics. The answers will be different for every studio. Helping studios scale their pipelines for feature animation has taught me a few consistent lessons. Think backwards and forwards, be realistic about scope, and keep the people building the tools close to the people using them.
For this discussion, let’s assume we’ve joined an existing studio with a pipeline and a pipeline team. Our job is to help that studio move from short-form animation into its first feature.
Thinking Backwards and Forwards
Before developing a single tool, you need to think through what the work requires. Even when production moves broadly in one direction, the needs of downstream departments have to inform what gets delivered upstream.
Coming from lighting, I like to start near the end of that journey. By the time a shot reaches lighting and the render farm, the consequences of many earlier decisions have arrived with it. So I start asking questions: How do I know I have all the right things in this shot before I render it? Can I easily remove things that don’t need to render? Can I light several “same-as” shots together? Can I adjust shaders without turning a small change into a major undertaking?
When the answer is no, we look upstream. What would need to be delivered differently to turn that answer into a yes?
At this stage, we’re defining what the departments need — not designing the technical solution. I like to keep that conversation supervisor-led, with the head of pipeline involved early enough to flag constraints and challenge assumptions. I wouldn’t pull the whole development team into every exploratory discussion. It’s easy for a useful conversation about the problem to become a detailed debate about implementation before we’ve agreed on what we’re trying to accomplish.
That’s the backwards thinking. Forward thinking is about throughput. This is where we talk about departments and their —I know, I hate this word too— quotas. Do we have the tools and workflows for each department to work at the pace this film requires? The supervisors should have a good sense of that.
We also need to ask what our downstream requirements cost everyone else. Can something lighting needs happen automatically? Does it add work for another department? If it does, is that burden reasonable, or are we simply moving the problem upstream?
After working through the pipeline in both directions, you should have a useful wish list. Now it’s time to check it against reality.
Getting the Scope Right
Everyone wants the Cadillac pipeline. A Honda Civic might get the film done.
Call the Cadillac version Plan A, but work through Plans B, C, and D with your supervisors. You need to know what is absolutely essential, what will meaningfully improve efficiency, and what will make daily work less painful. Those categories can overlap. Something that looks like a convenience on a short project can become essential when hundreds of artists repeat the same task for months.
When I meet with pipeline management, I like to bring clearly defined needs in that order: essentials first, efficiency gains next, then quality-of-life improvements. Not just a list of tools we want, but an explanation of the problem each one solves and what happens if we don’t build it.
The first priority is a workable path to finishing this film. That doesn’t mean ignoring the future. It means knowing which investments belong on the first film and which can wait until the second or third. You may not get everything now, but you should understand how today’s decisions affect what you can build later.
Keeping Development Close to the Work
There’s a problem I’ve seen repeatedly: distance between the people developing pipeline tools and the artists using them creates enormous waste.
The pattern is familiar. Someone has an idea for a tool. It might come from either side. The pipeline team goes away and does some very clever work. Time passes. The tool comes back, and it doesn’t quite line up with what the department actually needs.
Nobody wants this—especially the developer who has invested all that effort. But when the feedback arrives too late, both sides can become frustrated, and that frustration can turn into animosity.
The problem isn’t that developers should somehow know every detail of an artist’s job. It’s that the process hasn’t kept the people who know the work close enough to the people building the solution. You don’t have time for that disconnect while making your first feature.
Once we’ve agreed on the plan and assigned the development work, I like to assign someone from the artist side — usually a lead with a strong understanding of the workflow — as the product owner for that tool or capability.
That person works regularly with the developer. They clarify the need, test what’s being built, and help establish whether it actually works in production. The developer brings the technical judgment; the artist representative brings the production context. Neither should have to guess what the other means.
They might meet once a week, or on another cadence that fits the work, but communication needs to stay open between meetings. The important thing is that nobody disappears for weeks and comes back with a surprise.
Knowing When to Pivot
Alongside those conversations, the pipeline team still needs its own planning: milestones, resource allocation, dependencies, and shared technical knowledge. I like a practical flavor of Agile here, with work broken into manageable pieces and enough visibility to see when something is getting bogged down.
We’re building the pipeline while the film is moving through it. The plan has to respond to what we learn.
Maybe a tool is taking much longer than expected. Maybe testing reveals that it solves the wrong part of the problem. Maybe an upstream dependency won’t be ready when the department needs it. Those are reasons to revisit the scope—not simply keep going because the work has already started.
This is where your earlier prioritization earns its keep. What is the essential capability we still need? Is there a simpler way to provide it? Can an improvement wait? Does a temporary workaround genuinely save time, or just create a bigger problem somewhere else?
With supervisors, artist-side product owners, and pipeline leadership sharing that information, you have a much better chance of changing direction while there’s still time for the change to help.
I fully expect you to be on Plan Q by the end of the film. The important thing is that you got there on purpose: making informed decisions about what to build, what to defer, and how to make the most of the people and resources you have.
That last part goes well beyond the pipeline. Next time, we’ll talk about Film Scope and Bidding.