I can build a Sunday production system that gives me complete control over everything. I can add more routing options, more layers of processing, more automation, more custom controls, more flexibility, and more ways to solve unusual problems. But if I’m the only person who can operate it confidently, I’m not sure I’ve actually built a good system.
That’s something I’ve been thinking about a lot lately. Church production is an interesting environment because we often build systems that look a lot like professional broadcast, touring, or live-event systems, but we usually don’t staff them the same way. Most churches are not filling every technical position with someone who has ten years of experience and does this for a living. We’re asking volunteers to run them, and that changes the design problem.
The most capable system isn’t always the best system
There’s a tendency in production to equate capability with quality. If a console can route something twelve different ways, that feels better than one that only gives you three. If a camera gives the operator complete manual control over every parameter, that feels more professional. If a control system can trigger fifty different actions, we want all fifty available.
From a technical perspective, that makes sense. From an operational perspective, it can become a disaster. Every extra option is another decision somebody may have to make on Sunday morning. Every menu layer is another place to get lost. Every workaround that only one person understands is another failure point waiting for the week you’re not there.
Complexity is not automatically bad. Sometimes the system genuinely needs to be complex. But the operator experience should not have to be.
I’ve seen this show up in cameras
We recently went through this with camera focus. For a long time, manual focus felt like the more professional option because it gave us complete control and prevented the LED wall behind the stage from confusing the autofocus system.
The problem was that our volunteers were also trying to frame shots, follow movement, zoom, anticipate transitions, and keep track of what was happening in the room. On a wide stage where people might be thirty feet apart, manually maintaining perfect focus became one more responsibility stacked on top of everything else.
Technically, manual focus gave us more control. Operationally, it often gave us softer pictures. Once we tuned autofocus to behave properly in our environment, we realized that letting the camera handle that repetitive technical task actually gave the volunteer more space to make the creative decisions we wanted them making.
The goal wasn’t to remove control. It was to put control in the right place.
Wireless taught me the same lesson
We’ve seen the same thing with RF. For a while, wireless frequencies were essentially handled one system at a time: find something clean, program the device, and move on.
That works until it doesn’t. Once you have enough wireless microphones, instrument packs, and in-ear monitor systems sharing the same building, the RF environment becomes too complicated to manage casually. We eventually discovered that 20 of our 27 wireless devices had some kind of coordination issue.
The solution wasn’t asking the operator to become better at guessing frequencies. It was building a system that did the complicated work ahead of time. We coordinated everything together, documented the frequencies, and made the Sunday experience simpler.
That’s the pattern I keep seeing. The best production systems may have a lot of complexity behind them, but that complexity should be absorbed by the design whenever possible instead of dumped onto the volunteer.
Volunteers should not need to understand the entire system
I think production leaders sometimes accidentally train people backward. We feel like a volunteer needs to understand everything before they can operate anything: the complete signal flow, every routing option, every camera menu, every network path, every backup workflow, and every weird exception we’ve accumulated over the years.
Eventually, we’ve turned Sunday morning into a technical certification program.
I’m not saying volunteers shouldn’t learn. The best volunteers usually want to understand more over time, and I absolutely want to develop people who can eventually troubleshoot deeper problems. But somebody should not need to understand the entire system just to perform one role well.
A camera operator should be able to operate a camera without understanding the entire video signal path. A graphics volunteer should be able to run lyrics without understanding how every output reaches every screen in the building. A broadcast audio volunteer should be able to mix without memorizing every Dante subscription on the network.
Good system design creates boundaries. It gives someone exactly the controls they need for their job and protects them from the ones they don’t.
The test is what happens when you aren’t there
I think one of the most revealing questions a production leader can ask is: What happens if I’m not here Sunday?
Does the team still know how to power everything up? Can they recover if ProPresenter crashes? Do they know what to do if a camera disappears? Can they get audio back if something gets muted unexpectedly? Do they know what the fallback is if the livestream encoder fails, or does everyone immediately start texting you?
That question exposes a lot. Sometimes what we call a technical problem is actually a documentation problem. Sometimes it is a training problem. Sometimes it is a workflow problem. And sometimes the system really is just too complicated.
If the only reason Sunday works is because one person knows all the hidden tricks, that person has become part of the infrastructure. That’s not a particularly resilient system.
Documentation matters more than we like to admit
Documentation is one of those things that production people know they should do and rarely feel like doing. Building the system is fun. Programming the system is fun. Buying the equipment is definitely fun. Writing down how everything works is less exciting.
But documentation is one of the easiest ways to remove unnecessary dependence on one person, and it doesn’t have to mean writing a fifty-page technical manual nobody will ever read.
It can be much simpler. What order does everything power on? What should the normal console scene be? What happens if the stream goes down? What does a healthy system look like before service starts? Where are the spare batteries? What should never be changed without talking to somebody first?
A good checklist can sometimes do more for Sunday reliability than another piece of equipment.
Presets and guardrails are not cheating
I also think we need to get over the idea that every operator should start from a blank slate. Presets are good. Templates are good. Saved scenes are good. Locked settings are good. Macros are good. Automation is good when it removes repetitive work without removing judgment.
If every Sunday morning starts with volunteers rebuilding the same settings manually, that isn’t flexibility. That’s unnecessary risk.
We should be trying to create a known-good starting point. The volunteer’s job should be to operate the service, not reconstruct the production system before the countdown starts. The more predictable the baseline becomes, the easier it is to notice when something is actually wrong.
Good automation removes work, not people
This is where automation can be incredibly helpful if it’s used correctly. I like automation when it removes repetitive actions that do not require judgment.
If one button can consistently perform five technical steps that always need to happen together, I would rather give the volunteer one button. That doesn’t make the operator less valuable. It frees them to pay attention to the things automation cannot do well.
A camera automation can move a camera, but it cannot necessarily decide whether the shot feels right. A lighting cue can fire automatically, but somebody still needs to understand the room. A macro can route signals, but somebody still needs to know when that routing makes sense.
The goal is not to automate the volunteer out of the system. The goal is to automate unnecessary friction out of their job.
Design for the person who is learning
Production leaders usually build systems from the perspective of the person who understands them best. That makes sense because we’re the ones designing them.
But I think a healthier question is: What does this look like to the person who has been serving for three weeks?
Are the labels obvious? Do the buttons make sense? Does the screen show them the information they actually need? Can they tell the difference between something being wrong and something simply being unfamiliar? If somebody makes a mistake, can they recover without making five more mistakes trying to fix the first one?
Those questions may not sound as technical as bitrate, gain structure, network topology, or RF coordination, but they are absolutely production-system questions.
Usability is part of engineering.
Simple doesn’t mean unsophisticated
I think this is the part that can be hardest for technically minded people. Simple can feel like a compromise. It can feel like we’re lowering the standard.
But some of the best systems are incredibly sophisticated underneath while being incredibly simple to operate. That is usually the result of more engineering, not less.
It takes thought to decide which controls should be exposed. It takes work to build reliable presets. It takes discipline to remove options somebody doesn’t need. It takes time to document the workflow and testing to make sure the fallback actually works.
A complicated interface can happen by accident. A simple one usually has to be designed.
The bigger lesson
I still want capable systems. I want flexibility, quality, and the ability to solve unusual problems when they show up.
But I’m becoming much less impressed by complexity for complexity’s sake. A church production system ultimately has to work on Sunday morning with the people who are actually serving.
If the system is powerful but intimidating, flexible but fragile, or technically impressive but dependent on one person remembering twenty undocumented steps, then we probably still have work to do.
The goal isn’t to make volunteers become professional engineers before they can serve. The goal is to build systems that help volunteers succeed while giving them room to grow.
Because if Sunday only works when the Production Director is sitting in the chair, we haven’t built a production system.
We’ve built a dependency.
And that may be one of the most important technical problems we can solve behind Sunday.