How to Ask Smart Technical Questions
TECHNICAL RESOURCE
A practical guide for live production, AV integration, church tech, broadcast, and other technical communities.
Good technical questions get better technical answers. This guide is about doing the homework, defining the real problem, providing useful evidence, respecting the people helping you, and giving answers that actually move the conversation forward.
A Note Before We Start
This article owes a substantial intellectual debt to Eric S. Raymond and Rick Moen’s classic How To Ask Questions The Smart Way. Their original was written for hacker and open-source communities, but many of the same problems show up every day in church technology, live production, AV integration, broadcast, and technical groups online.
This is not a reproduction or adaptation of their article. It is an independent discussion of many of the same principles applied to the technical communities in which we work.
Read How To Ask Questions The Smart Way
IN THIS ARTICLE
1. Why Good Questions Get Better Answers
A good technical question does not prove how much you know.
It gives other people enough reliable information to help you solve the problem.
You do not need to be an expert to ask a good question. You do not need twenty years of experience, a measurement rig, or perfect terminology.
You do not have to know the answer. You do have to participate in finding it.
There is a huge difference between:
“I’m new to this and I don’t understand why this is happening.”
and:
“Mixer no work. Help.”
One is ignorance.
Ignorance is fixable.
The other asks everyone else to do all of the work for you.
This is not a rulebook for being polite on the internet.
It is a guide to getting useful technical answers and giving useful technical answers.
Technical communities work best when both sides participate. The person asking gives useful information, answers follow-up questions, runs tests, and reports what happened. The people answering apply their experience, explain their reasoning, and help move the problem toward a solution.
The goal is not to sound smart.
The goal is to get closer to the truth.
There is one question we are going to return to throughout this article:
What problem are you trying to solve?
Ask yourself before you post.
Ask yourself again before you hit submit.
Ask yourself again when the replies start exposing assumptions you did not realize you had.
2. Before You Post
Before asking several thousand strangers to troubleshoot your system, do a little work first.
Search the group.
Read the relevant part of the manual.
Check the manufacturer’s documentation.
Search the exact error message.
Look at the signal path.
Think about what changed.
Try to reproduce the problem.
Perform a sensible controlled test if you know how.
You may find the answer yourself.
If you do not, you will almost certainly ask a better question.
Being New Is Fine
Everybody started somewhere.
Nobody was born knowing how to coordinate wireless, configure Dante, calculate coverage, troubleshoot HDCP, align a PA, program a lighting console, or figure out why a generator suddenly hates their audio system.
If you are genuinely new and trying to learn, good technical communities should make room for you.
But being new does not exempt you from doing basic homework.
If the answer is on page 12 of the manual, in the manufacturer’s FAQ, or in the same group six posts below yours, somebody may point that out.
They may not wrap the answer in bubble wrap.
That is okay.
If you ask a stupid question, you may get beaten up a little.
Sometimes you deserve a little flogging.
That does not mean you should stop asking questions. It means you should learn how to ask the next one better.
Being inexperienced is not the problem.
Being unwilling to look, read, test, or think before asking everyone else to do it for you is.
Search First
Most active technical groups answer the same kinds of questions repeatedly:
- What wireless mic should we buy?
- Powered or passive?
- What console should we get?
- What is the best livestream camera?
- Why is my mixer doing this?
- Which network switch should I use?
- What speakers should we buy?
Many come around every few months.
Use the search function.
"STFW" (Search The Fabulous Web)
You may find:
- the exact problem,
- a similar system,
- a manufacturer response,
- a troubleshooting sequence,
- or a thread where the original poster came back and explained what fixed it.
That last one is especially valuable.
Later we are going to beat people up for posting:
“Never mind. Fixed it.”
and disappearing without saying what they fixed.
Searching only works when people leave useful information behind.
Be one of those people.
Read the Manual
Yes, really.
"RTFM" (Read The Fabulous Manual)
You do not need to read 600 pages before asking a question.
But if the issue concerns AES50 cabling, read the AES50 section.
If the issue concerns amplifier loading, read the amplifier specifications.
If you are trying to configure a console feature, search the manual for that feature.
If somebody later tells you:
“Read page 84.”
and page 84 contains the answer, they were not being rude.
They gave you the answer and showed you where to find it next time.
A Real-World Example
Someone asks:
“I’m installing a digital snake cable for an X32. It will run through conduit and raceway for about 100 feet. Should I use shielded Cat6 with EtherCON?”
That is already a reasonably thoughtful question.
But there is one excellent step to take first:
Read the AES50 cabling specification for the equipment you own.
The manufacturer specifies the cable type.
That matters more than:
“I’ve used Cat6 for years and never had a problem.”
or:
“Cat6 is better because 6 is higher than 5.”
Sometimes people get lucky using something outside the published specification.
That does not make it the specification.
Short-term success does not validate a bad method.
For the X32 family, Behringer documentation specifies shielded Cat5/Cat5e cabling for AES50 connections and lists a maximum run of 100 meters / 330 feet on shielded Cat5e.
If the documentation answers the question, great.
If not, now you can ask something better:
“The X32-family documentation specifies shielded Cat5/Cat5e for AES50. I need an approximately 105-foot permanent run through conduit. Is there a particular installation-rated cable you recommend that meets the published requirement?”
Now the remaining problem is clear.
Know What Changed
One of the most useful troubleshooting questions in any technical discipline is:
What changed?
Did it work yesterday?
Did someone update firmware?
Move a receiver?
Replace a cable?
Change the console file?
Install an access point?
Move the stage?
Add another wireless system?
Modify the DSP?
Plug in a different computer?
Problems rarely appear because the universe became bored.
If the system worked correctly and now does not, something changed.
Find out what.
Separate Facts from Assumptions
This matters enough to write down:
Know what you know. Know what you observed. Know what you measured. Know what you are assuming.
Those are not the same thing.
For example:
“The amplifier is configured for low impedance.”
Did you verify that?
Or do you believe it should be configured that way?
A much better statement is:
“I believe the amplifier is configured for low impedance, but I have not verified that yet.”
Perfect.
Now everyone knows where the uncertainty is.
3. Build an Answerable Question
You did some homework.
You did not find the answer.
Good.
Now give the people trying to help you something they can actually work with.
A useful technical question usually answers some version of these:
- What are you trying to accomplish?
- What equipment or software is involved?
- What did you expect?
- What actually happened?
- What have you already tried?
- What specifically do you want help determining?
You will not always have every answer.
That is fine.
Give what you have.
Ask an Actual Question
“Thoughts?”
is not a technical question.
Neither is:
“Help!”
Or:
“Anyone seen this before?”
Be explicit.
Instead of:
“My wireless is acting weird. Thoughts?”
try:
“Four of our eight wireless vocal channels are intermittently dropping RF during services. The failures are not always on the same channels. What information should I collect first to determine whether this is frequency coordination, receiver placement, or something else?”
Now there is something to answer.
You are not asking someone to magically fix the entire system.
You are asking for the next diagnostic step.
Please Retire “…and GO!”
You have seen this:
“Best mixer under $3,000. And GO!”
No.
Group participants are not contestants waiting for a buzzer.
The people you are asking may be technical directors, production managers, engineers, touring technicians, integrators, business owners, volunteers, parents, spouses, or some combination of those things.
They have rehearsals.
They have services.
They have shows.
They have installs.
They have businesses.
They have families.
And some of them are still willing to take ten minutes out of that schedule to help solve your problem for free.
Treat that time with a little respect.
Ask the question.
Provide the information.
Say thank you when appropriate.
If you throw out a vague question and finish it with:
“…and GO!”
you have earned at least a little of the grief that follows.
Tell Us What You Are Trying to Accomplish
Suppose you ask:
“How do I route Aux 7 into Matrix 3?”
Someone can probably tell you.
But a better starting point might be:
“I’m trying to create an independent livestream mix from the same console we use at FOH. I thought I needed to route an aux into a matrix, but I’m not sure that is the right architecture.”
Now someone can tell you that the path you chose may not be the best way to reach the goal.
Do not ask people to validate the solution you invented before you tell them the problem you are trying to solve.
4. Give Us the System, Not a Mystery
Technical problems exist inside systems.
Give us the system.
If it is audio, tell us the signal path.
If it is networking, tell us the topology.
If it is video, tell us what connects to what.
If it is RF, tell us the equipment, frequencies, antenna arrangement, and environment.
If it is power, tell us what is being powered and how.
You do not need an engineering schematic.
Even this is useful:
Vocal mic → wireless receiver → console → matrix → DSP → amplifier → loudspeaker
Now there is a system to troubleshoot.
Without that, every responder has to build an imaginary system before troubleshooting yours.
If the person answering has to invent half your system before they can answer, you have not asked a complete question.
Use Exact Equipment Names
“Shure wireless”
is not enough.
Shure makes products ranging from entry-level systems to high-end touring and broadcast wireless.
Likewise:
“Yamaha mixer”
could describe radically different consoles with different routing, capabilities, workflows, and network architecture.
Give manufacturer and model.
If firmware or software version matters, include it.
If you do not know:
“I don’t have the firmware version in front of me yet.”
is useful information.
5. Context Changes the Answer
A technically correct answer in one application can be completely wrong in another.
That is why one of the most legitimate answers in technical work is:
It depends.
“It depends” is not evasive when the answer actually depends on information you did not provide.
Size Is Not a Technical Specification
This question:
“Small to medium size churches. Amp and passive speakers or powered? Why?”
does not contain enough information for an intelligent answer.
What is a small church?
100 seats?
300?
1,000?
A 1,000-seat church may feel modest in one region and enormous in another.
More importantly, seat count still does not tell us:
- worship style,
- required SPL,
- room geometry,
- acoustics,
- permanent versus portable,
- number of coverage zones,
- existing wiring,
- electrical availability,
- subs,
- monitors,
- service expectations,
- budget,
- or who maintains the system.
Size is not a technical specification.
Size matters much less than you think.
Application matters.
If 75 people answer that question, they are not answering your system.
They are answering 75 imaginary systems they invented because you did not provide enough information about yours.
That is not useful consensus.
It is noise.
“Who’s Your Go-To for LED Walls?”
For what?
Manufacturer?
Distributor?
Integrator?
Installer?
Rental vendor?
Low price?
Long-term support?
What size?
What pixel pitch?
Closest viewing distance?
On camera?
Indoor or outdoor?
Permanent or temporary?
Power available?
Expected service life?
Without those answers:
“DM me. I have great pricing.”
is not a technical answer.
Neither is:
“We install LED walls all over the country.”
Those are sales responses.
Useful responses start with:
“What is the intended use?”
“Will it be on camera?”
“What size and viewing distance?”
“What power is available?”
Those questions are doing the work.
“What’s the Best…?”
Best microphone?
Best console?
Best speaker?
Best PTZ camera?
Best wireless system?
Best livestream software?
Usually:
“Best” is shorthand for “I haven’t told you my requirements yet.”
Best for what?
For whom?
At what budget?
At what scale?
With what existing ecosystem?
For touring?
For installation?
For volunteers?
Everything is a compromise.
The useful question is rarely:
“What is the best?”
It is:
“What best fits these requirements?”
The Brand You Like Is Not a Design Criterion
There is nothing wrong with having preferences.
You may like one console workflow.
You may prefer one microphone company.
You may love the sound of a particular loudspeaker.
Fine.
Preference is not design.
If your existing problem is poor coverage, the coverage requirement should determine the loudspeaker before the loudspeaker determines the placement.
Do not buy the answer before you have defined the question.
Good equipment can still be wrong equipment.
A Honda Accord is a perfectly good automobile.
It is still the wrong tool to pull a 53-foot trailer or spend the weekend crawling through the woods.
Specifications Need Context Too
A loudspeaker might be specified:
90° × 60°
Great.
At what frequency?
That question, from Ivan Beaver, is one of the most useful habits you can develop in loudspeaker discussions.
Ivan Beaver — Danley technical writing
Two loudspeakers can both carry a nominal 90° × 60° specification while maintaining that pattern very differently as frequency decreases.
The number alone does not tell the whole story.
The same applies elsewhere.
“This active speaker is 2,000 watts.”
Okay.
What does that tell us about how loud it will actually get?
Not nearly as much as the marketing department would like you to think.
There are plenty of common 12-inch powered two-way loudspeakers advertised around 2,000 watts.
For illustration, consider a representative one around 94 dB sensitivity.
For contrast, consider a loudspeaker such as a Danley SH96.
The SH96 is specified around 101 dB sensitivity and rated at 1,400 watts continuous / 2,800 watts program.
Danley publishes 133 dB continuous and 139 dB peak output for the SH96.
Yet the SH96 can produce dramatically more usable acoustic output than a typical powered two-way carrying a large amplifier-wattage number on the brochure.
Why?
Because amplifier wattage is only one piece of the system.
Sensitivity tells you how efficiently electrical input becomes acoustic output.
Directivity determines where that acoustic energy goes.
Driver capability, thermal behavior, limiting, distortion, and power compression determine what happens as you drive the system harder.
Doubling amplifier power in an ideal linear system only buys about 3 dB.
Real loudspeakers are not perfectly linear.
As voice coils heat, resistance rises and efficiency falls. More electrical input produces progressively less additional acoustic output.
That is power compression.
A high-efficiency loudspeaker with controlled directivity and substantial acoustic headroom can outperform a smaller box carrying a much larger amplifier-wattage number on the brochure.
As Ivan Beaver puts it:
“If you want ‘watts’ — then plug in a toaster.”
Look at sensitivity.
Look at acoustic output.
Look at directivity.
Look at distortion.
Look at the conditions under which the specifications were measured.
Marketing numbers are easy.
Engineering requires context.
6. What Problem Are You Trying to Solve?
This is important enough to say again:
What problem are you trying to solve?
A lot of bad technical questions happen because someone already invented a solution and now wants the group to make it work.
That is backwards.
Suppose someone asks:
“What app should we use so people can scan a QR code and have information show up instantly on a tablet?”
Maybe that is exactly the right workflow.
Maybe it is not.
Are you trying to collect information faster?
Eliminate paper?
Route submissions to the right person?
Display something live?
Keep records for follow-up?
Integrate several workflows?
Those are different problems.
If you only tell someone:
“I need a QR code that sends to a tablet,”
you have described a proposed solution, not necessarily the underlying problem.
Likewise:
“What wireless router should I buy for FOH?”
For what?
Console control?
Internet access?
Lighting?
Point-to-point networking?
Guest Wi-Fi?
Bridging venue Wi-Fi into your own system?
Start with the problem.
Then talk about solutions.
If you only describe your proposed solution, the group may help you build the wrong thing more efficiently.
Sometimes the Answer Is Uncomfortable
Someone may ask:
“How can I reposition these speakers to fix our feedback and coverage problems?”
The correct answer may be:
“There is not a good way to solve those problems with those loudspeakers in that room.”
That is not refusing to help.
That is the help.
Sometimes the answer is:
Repair what you have.
Sometimes:
Add another properly designed coverage zone.
Sometimes:
Buy different equipment.
Sometimes:
Wait and save.
And sometimes:
Spend money.
You cannot EQ a commodity loudspeaker into a Danley or an L-Acoustics system.
That is not a brand argument.
It is an architecture argument.
EQ changes frequency response.
It does not create missing directivity, displacement, headroom, thermal capability, or phase behavior that the acoustic system does not possess.
Some limitations are physical.
Physical Limitations Do Not Disappear Because the Budget Is Uncomfortable
“We need a PTZ camera under $1,000 that looks great in our very dark sanctuary.”
Maybe there is a workable option.
Maybe better lighting helps.
Maybe used equipment gets you closer.
But at some point, small sensors, mediocre optics, inadequate light, and aggressive image processing are physical limitations.
You cannot configure your way around physics.
The same applies to LED walls.
If the panels themselves have poor scan behavior, poor grayscale, objectionable moiré, or poor camera performance, a more expensive processor does not turn them into different panels.
Sometimes the answer is:
More budget, different equipment, better conditions, or different expectations.
Cheap twice is expensive.
Budget Is a Requirement. Physics Is Also a Requirement.
A small church may genuinely have $1,000.
That matters.
The answer should respect it.
But $1,000 does not change the physical requirement.
RF does not become more forgiving.
A loudspeaker does not cover farther.
Rigging loads do not become lighter.
Physics does not care that you are a nonprofit.
Sometimes the smart answer is:
“With $1,000, solve this part first.”
Maybe you buy one good wireless microphone instead of four bad ones.
Maybe you skip wireless entirely and use wired microphones.
Maybe you fix sanctuary audio before buying livestream cameras.
Maybe you rent for the two events a year that require more.
Maybe you wait.
Sometimes the wisest technical recommendation is to do less.
Spend enough to solve the actual problem. Not more. Not less.
7. Evidence Beats Opinions
Tell people what happened.
Not what you think happened.
Those are different things.
Instead of:
“Dante is dropping out because our switch can’t handle multicast.”
say:
“Every 20–30 seconds we hear a brief dropout across all eight Dante channels. Dante Controller shows late packets on the console. The stagebox does not show errors. Both devices are connected through the same managed switch.”
Now there is evidence.
Your theory may eventually be correct.
Give the evidence first.
Measurements Beat Adjectives
Instead of:
“The amplifier is bad.”
tell us:
“Channel 2 produces approximately 18 dB less output than Channel 1 with the same input signal and processing. Swapping the input cables does not move the problem.”
Instead of:
“RF is terrible.”
tell us:
“Receiver RF indication drops from full to nearly zero when the transmitter moves more than 40 feet from the rack.”
Instead of:
“The speaker isn’t loud enough.”
tell us what you can actually observe or measure.
Measurements beat adjectives.
Useful Evidence Is Useful
Screenshots help.
Photos help.
Short recordings help.
Signal-flow diagrams help.
Error logs help.
Measurements help enormously.
But more information is not automatically better information.
Fifty unlabeled console screenshots are not precision.
A twelve-minute phone video where the problem happens once at 9:47 is not precision.
Show the part that matters.
If more is needed, people can ask.
Tell Us What You Already Tried
Compare:
“I tried everything.”
with:
“I swapped the microphone cable, moved the channel to another console input, bypassed the DSP, and connected directly to the amplifier. The symptom did not change.”
The second eliminates entire branches of troubleshooting.
The first tells us nothing.
And no, you did not try everything.
Tell Us What You Have Not Verified
There is no shame in:
“I haven’t checked that yet.”
Maybe you do not know the amplifier mode.
Maybe you have not confirmed firmware.
Maybe you do not know the actual cable length.
Say so.
That is better than accidentally presenting an assumption as fact and sending everyone down the wrong path.
A Short Answer May Be Exactly Right
Someone asks:
“What’s the easiest way to test whether an XLR cable has a Pin 1 problem?”
Answer:
“Cable tester.”
Done.
That is not rude.
The question was narrow.
The answer was narrow.
Not every short answer is rude. Not every correction requires a hug.
8. Questions That Cannot Be Answered Yet
Some questions are not difficult.
They are incomplete.
There is not enough information present for an intelligent answer to exist.
“Powered or passive?”
Incomplete.
“What is the best microphone?”
Incomplete.
“Anyone using EasyWorship? Anyone using vMix?”
Maybe not even a question yet.
“Recommendations for a Sunday-school PA? Fifteen classrooms, one office.”
Still missing the actual use case.
“We need to improve our sound system. Any suggestions?”
Improve what?
Coverage?
Feedback?
Intelligibility?
Livestream?
Monitors?
Reliability?
The word improve is not a requirement.
Define the problem.
A Question Can Get Better
A vague question may become useful very quickly with an update.
For example:
“What is the best PTZ camera for a church on a budget?”
Mostly useless.
Then:
UPDATE: Budget is under $1,000 all-in. We already have an ATEM Mini and streaming computer. We previously used three hardwired cameras at the front, but they occupied a pew and blocked sightlines. We want to move to the back of the room and would prefer a single PTZ if possible.
Now we have constraints.
The answer may still be:
A sub-$1,000 PTZ may not give you the image quality you expect in a dim room.
That is an uncomfortable answer.
It is still an answer.
9. Safety Changes the Rules
Most technical mistakes cost time or money.
Some can hurt people.
That changes the standard.
Rigging.
Temporary power.
Permanent electrical work.
Structural attachment.
Flown loudspeakers.
Truss.
Lifts.
Working at height.
Lasers.
Generators.
Life-safety interfaces.
Anything where code, permits, licensing, or structural engineering may apply.
This is where Facebook stops being the final authority.
If You Have to Ask Whether It Is Safe, You Probably Should Not Be Making the Final Call
That is intentionally harsh.
We recently removed a loudspeaker system suspended using open eye screws and hardware-store chain more appropriate for a porch swing or hanging plant.
It stayed up.
That does not make it safe.
Short-term success does not validate a bad method.
A dangerous installation that has not failed yet is still dangerous.
“It has been hanging like that for 15 years.”
is not a rigging calculation.
If you are looking at an improvised suspension system and asking:
“Do you guys think this is okay?”
you should not be the person approving it.
Get someone qualified on site.
Education Is Fine. Remote Approval Is Not.
A technical group can discuss:
- load calculations,
- safety factors,
- manufacturer rigging points,
- cable types,
- connector ratings,
- grounding and bonding concepts,
- code concepts,
- what questions to ask,
- what documentation to obtain.
Useful.
What a public technical group cannot do is:
- inspect the structure,
- verify the attachment point,
- inspect hidden construction,
- test the circuit,
- see every installation condition,
- verify local requirements,
- assume responsibility for the work.
There is a difference between:
“Help me understand what needs to be verified.”
and:
“Tell me this is safe so I can hang it tomorrow.”
The first is education.
The second needs a qualified person on site.
“Facebook said it was fine” is not a commissioning standard.
Improper work can create code, liability, insurance, permitting, and safety problems.
The exact legal requirements vary by jurisdiction.
The physics does not.
Know What Kind of Professional You Need
Sometimes you need:
- an electrician,
- a structural engineer,
- a qualified rigger,
- a design engineer,
- an acoustician,
- an RF coordinator,
- a network engineer,
- a broadcast engineer,
- an AV integrator,
- or a competent local technician.
A good design engineer starts with requirements, not inventory.
A competent engineer looks at:
- the room,
- application,
- audience,
- coverage,
- SPL,
- acoustics,
- workflow,
- networking,
- power,
- rigging,
- infrastructure,
- maintainability,
- future growth,
- budget,
- and the people operating it.
Ideally, the question begins brand-agnostically:
What does this project require?
Then products are evaluated against those requirements.
Technical people tend to see problems through their own discipline.
The electrician sees electrical.
The network engineer sees VLANs.
The integrator sees system architecture.
The audio person sees loudspeaker coverage.
The lighting person thinks DMX can fix your marriage.
And I’m not the DJ, but you can request a color.
Get the right professional for the problem.
And remember:
Every machine is a smoke machine if you operate it incorrectly enough.
10. Working Through the Replies
You asked the question.
People answered.
Your job is not over.
Technical troubleshooting is iterative.
Someone asks a question.
You provide a fact.
They eliminate a possibility.
Someone suggests a test.
You run it.
The result changes the direction.
That is how this works.
Answer the Question People Actually Asked
You post:
“My wireless microphones keep dropping out.”
Someone asks:
“What exact manufacturer, model, and frequency band?”
You reply:
“It mostly happens during worship.”
They ask again:
“What exact manufacturer, model, and frequency band?”
You reply:
“The old microphones didn’t do this.”
We are not getting anywhere.
If someone asks for a specific fact, answer that fact.
If you do not know:
“I don’t know yet. I’ll check.”
is perfectly respectable.
Do Not Selectively Answer Only the People Who Agree With You
Ten people ask for measurements.
Five ask about signal flow.
Three challenge your assumption.
One person says:
“Yep. Sounds like a bad mixer.”
And suddenly that is the comment you want to engage with.
Why?
Because it validates what you already wanted to believe.
Ask yourself again:
What problem are you trying to solve?
Are you trying to solve the technical problem?
Or are you trying to get strangers to agree with your diagnosis?
Those are not the same goal.
11. Respect Other People’s Time
This is important enough to stand on its own.
The people responding may have jobs, businesses, families, rehearsals, services, installs, events, and their own technical disasters.
They still chose to give you some of their time.
Respect it.
Update the Original Post
If you discover important information, edit the original post.
Add:
UPDATE: The console is an SQ6. The stagebox is a DX168. Direct connection eliminates the dropout, so the problem appears to be somewhere in the network path.
Do not bury the most important new fact in Comment 38.
Think about the 40th person who arrives after 73 comments.
They should not have to perform archaeology to reconstruct the system because you could not be bothered to edit the original post.
Respect other people’s time.
Update it.
If You Left Something Out, Say So
You do not need to defend the original post as though it were a legal filing.
If somebody asks a question and you realize:
“I should have included that.”
Great.
Add:
UPDATE: I left out an important detail…
That is what competent people do when new information appears.
The people helping need the information.
They do not need you to pretend the original question was perfect.
12. Snark, Correction, and Not Being a Wanker
Not every short answer is rude.
Not every correction requires a hug.
Technical people often communicate directly because they are trying to eliminate variables and solve the problem.
Sometimes:
“Read page 47.”
is an excellent answer.
Sometimes:
“You are measuring the wrong thing.”
is exactly what you need to hear.
Sometimes:
“There is not enough information here to answer this.”
is simply true.
A close friend of mine, Gary Duty of Sound Doctrine, has a sign in his recording studio that says:
“I’m not mean, you’re just a sissy.”
That is probably a little too far as a general rule for technical communities.
But there is a useful idea buried inside it: directness is not automatically cruelty, and disagreement is not automatically disrespect.
Sometimes the answer is simply:
“No. That is not safe.”
Or:
“That assumption is wrong.”
Or:
“You have not provided enough information to answer the question.”
None of those require an apology for being direct.
If Your Question Was Bad, Fix the Question
Suppose you post:
“Best mixer under $3,000. And GO!”
and people give you grief.
You earned at least a little of the grief that follows.
The correct response is not:
“Wow. I thought this was supposed to be a helpful group.”
It is a helpful group.
That does not mean everyone is obligated to be endlessly patient when you did not show them the same courtesy.
If you are participating in a church technical group, there is a good argument that you should be more considerate of other people’s time, not less.
Many of the people helping you are volunteers too.
The onus is on you, the person asking for their help, to begin with basic courtesy.
Do not provide half the information, ignore the questions people ask, and then demand that everyone else improve their manners.
People should not have to pull the information out of you like a dentist pulling wisdom teeth.
Nobody is sitting by the phone waiting for you to get back to them.
Learn How to Be Wrong
This is a useful professional skill:
“Yep. I had that wrong.”
Try it.
You will survive.
Maybe you misunderstood impedance.
Maybe you confused AES50 and Dante.
Maybe the routing was not what you thought.
Maybe somebody showed you a manufacturer document that contradicts something you have done for ten years.
Good.
Now you know something you did not know yesterday.
Being corrected is not the same thing as being humiliated.
Humility is part of technical competence.
Don’t Be a Wanker
Use this rule once and remember it.
Do not:
- double down because you are embarrassed,
- move the goalposts,
- argue with everyone who provides evidence you do not like,
- delete information that makes your original conclusion look wrong,
- complain that the group is toxic because somebody corrected a technical error,
- demand that every correction be delivered like a customer-service survey.
Take the useful information.
Fix the mistake.
Move forward.
Good Snark Still Has a Job
Useful:
“You gave us the room dimensions but not the speaker model. My crystal ball is in the shop.”
The joke points directly at the missing information.
Useful:
“That 2,000-watt number tells me less than you think it does.”
Now explain why.
Useful:
“Your signal is probably not afraid of Sundays. What changes on Sunday?”
That redirects troubleshooting.
Not useful:
“You obviously have no business touching audio.”
That teaches nothing.
The standard should not always be:
“Was it nice?”
A better question is:
Did it move the technical conversation forward?
Snark can.
Cruelty usually does not.
13. Close the Loop
You got the answer.
Or you found it yourself.
Come back.
Don’t Drop a Question Grenade and Leave the Room
You threw the grenade.
Fifty people jumped into the thread trying to help.
Then you disappeared.
Do not do that.
If people invest time in your problem, come back and tell them what happened.
“Never Mind, Fixed It.”
No.
Fixed what?
What failed?
Which test found it?
What changed?
What assumption was wrong?
You asked the room to help solve the mystery.
Tell the room who did it.
Update the Original Post With RESOLVED
Leave the original question intact.
Add:
RESOLVED: The dropout was caused by a damaged network cable between the switch and stagebox. Replacing the cable eliminated the late packets. Thanks to everyone who suggested bypassing the network path one section at a time.
Now the thread has value six months later.
Someone searches the group.
They find:
- the symptoms,
- troubleshooting,
- updates,
- and solution.
That is how a technical community becomes a knowledge base instead of an endless recycling bin for the same questions.
You did use the search function before posting, right?
A quick:
“Thanks, that solved it.”
or even a thumbs-up on a useful reply is often enough.
Nobody needs a speech.
Basic gratitude is still basic decency.
14. How to Answer Questions Without Being That Guy
Bad questions waste time.
Bad answers waste time too.
If you are going to answer:
Answer the question. Justify your answer. Show your work.
If the person asking is expected not to be a wanker, the people answering do not get an exemption.
Answer the Question That Was Asked
Someone asks:
“What would you test next to determine whether this is an RF problem or an audio-path problem?”
Do not respond:
“Buy Shure.”
That does not answer the question.
A useful answer might be:
“Watch the receiver RF indication while reproducing the failure. If RF remains solid while audio disappears, look downstream of the receiver. If RF collapses at the same time, stay on the RF side and start checking coordination, antenna placement, cable losses, and receiver location.”
Now somebody learned something.
Justify Your Answer
A recommendation without reasoning is an opinion.
Opinions are allowed.
Label them honestly.
“I prefer Audix handhelds because…”
Fine.
Now tell us why.
What requirement does it satisfy?
What compromise are you accepting?
What competing option did you reject?
What data supports it?
What experience informs it?
Answer the question. Justify the answer. Show your work.
Brand Preference Is Fine. Brand Dogma Is Not.
Everybody has preferences.
The problem starts when preference becomes theology.
“Shure is the only wireless worth buying.”
No.
Shure is one of the major professional wireless manufacturers.
So are several others.
Each manufacturer has product tiers.
Every major manufacturer also has entry-level systems with compromises in RF capability, coordination, construction, networking, range, or features.
Everything is a compromise.
A budget system may be perfectly adequate for one or two channels in a forgiving environment.
That does not make it a wise choice for eight or ten channels.
“We Run Eight BLX Systems and They Work Fine”
Maybe you do.
That is useful anecdotal information.
It is not proof that eight channels of BLX are a good recommendation for someone designing a new eight-channel system.
You may have:
- a forgiving RF environment,
- short distances,
- favorable frequencies,
- receivers close to the stage,
- or simply enough margin that the weaknesses have not bitten you yet.
People drive on bald tires without crashing.
People tow trailers with overloaded vehicles.
People run engines after warning lights come on and sometimes make it home.
The absence of failure is not proof that the method was sound.
Short-term success does not validate a bad method.
And if somebody points out the limitations of the product you own, do not behave as though they insulted your grandmother.
“As an Integrator…”
Nobody cares.
And I say that as an integrator.
My title is not evidence.
My résumé is not evidence.
My company name is not evidence.
And neither is yours.
This is worth naming for what it is: an argument from authority.
An argument from authority asks you to accept a claim because an expert or authority believes it.
Expertise matters. Relevant experience matters. Qualified consensus can matter.
But:
Expertise is useful evidence. It is not a substitute for reasoning.
A title does not replace measurements, documentation, evidence, or a sound technical explanation.
“I’m an integrator, therefore this is the right answer.”
is not an argument.
“I have designed several systems with this exact constraint. Here is the problem I see, here is the data, and here is why I would solve it this way.”
That is useful.
The people operating at the highest level rarely need to announce it.
The work shows.
The reasoning shows.
The ability to explain the problem shows.
Sometimes “As an integrator…” is not really there to establish technical context anyway.
It is there to signal:
I sell this stuff. You can DM me.
If your answer is good, people will figure out what you know.
“Forty Years Mixing Sound”
Forty years of experience is meaningful context.
It is still not proof that a particular claim is correct.
Someone can do something incorrectly for forty years.
The correct response to:
“That claim does not match the manufacturer’s data.”
is not:
“I’ve been doing this longer than you’ve been alive.”
Show the data.
Technical truth does not gain seniority points.
If You Do Not Know, Say So
There is no prize for answering first.
“I believe this is the case, but I would verify it in the manual.”
Fine.
“I have not used that model, so somebody with direct experience may have a better answer.”
Fine.
Or do not answer.
Wrong information delivered confidently is worse than silence.
“I think…” is not a measurement.
Confidence is not a calibration standard.
Read the Question Before Replying
If the OP says:
“I replaced the cable, moved the channel, bypassed the DSP, and the problem remained.”
do not reply:
“Try changing the cable.”
If they say:
“Budget is $1,000.”
do not recommend a $4,000 camera without explaining why the requirement cannot be met at $1,000.
Read the question.
The same courtesy demanded from the asker applies to the answerer.
Teach Something
This may be the most important part.
The best technical answer is often not:
“Change this setting.”
It is:
“Here is the next test I would run, here is why I would run it, and here is what each possible result tells us.”
That teaches troubleshooting.
Instead of:
“Your gain structure is wrong.”
show where to start following the signal.
Instead of:
“Those speakers won’t cover.”
explain the geometry.
Be a teacher.
One of the clearest signs that someone genuinely understands a subject is the ability to explain it to someone who does not.
Sometimes:
“Cable tester.”
is still enough.
But when there is an opportunity to teach the method, take it.
15. Integrators, Vendors, Manufacturers, and Dealers
There is nothing wrong with making money in this industry.
There is nothing wrong with meeting a future customer in a technical group.
There is nothing wrong with saying:
“We do this kind of work.”
The problem is when that becomes your entire contribution.
Technical groups are communities first.
They are not lead-generation feeds.
“Highly Recommend <Insert and Link to My Own Company Here>!!”
We certainly hope you highly recommend your own company.
But that is not particularly useful information.
Someone asks for an integrator.
The owner of Acme AVL replies:
“Highly recommend Acme AVL!”
Excellent.
Thank you for the independent recommendation.
If your only participation in the group is recommending yourself every time somebody mentions an upgrade, install, capital campaign, LED wall, or new sanctuary, you are not contributing technical expertise.
You are prospecting.
It Becomes a Shark Tank Quickly
Someone types:
“We’re upgrading our system.”
Then the fins appear.
“DM sent.”
“We’d love to help.”
“We service your area.”
“Give me a call.”
“Highly recommend us.”
Before recommending your company, perhaps figure out where the person is.
A Healthier Technical Community Looks Like This
Answer a routing question.
Help someone understand gain structure.
Explain why their loudspeaker coverage is poor.
Point them to a manual.
Help troubleshoot gear you did not sell them.
Correct bad information.
Teach someone how to run a useful test.
Recommend a competitor when the competitor is better suited.
Contribute when there is absolutely nothing to sell.
Give.
Give.
Give.
Give.
Then comes the hook:
People figure out that you know what you are doing.
Those are the people worth paying attention to.
If someone consistently gives useful answers, explains their reasoning, helps when there is nothing to sell, and demonstrates competence in public, remember the name.
If you later discover that they provide a product or service you actually need, reaching out to them makes far more sense than responding to the person whose only contribution was:
“DM me. I can help.”
Geography Matters — but Context Matters More
A good integrator 600 miles away may absolutely be the right choice.
Some projects justify specialized expertise.
And some markets simply do not have strong local options.
A remote town may reasonably bring in an integrator from several hundred miles away because the nearest capable firms either cannot serve it or do not want the work.
That is a different calculation from a project in a major metro area with multiple qualified firms nearby.
The rule is not:
“Never hire someone farther than X miles away.”
There is no useful universal mileage rule.
A better principle is:
The farther away the integrator is, the more value there should be to justify the travel and service friction.
That value may be:
- specialized expertise,
- unusual manufacturer knowledge,
- a difficult project type,
- established relationships,
- proven engineering,
- or simply the absence of capable local alternatives.
Distance creates real costs:
- mobilization,
- hotels,
- return trips,
- warranty service,
- punch-list visits,
- future additions,
- emergency response.
Before the sale, everyone answers the phone.
Everyone promises support.
The more useful question is:
Who answers six months later on Friday afternoon when something stops working?
Service has geography.
Sometimes the Right Recommendation Is Someone Else
A professional may say:
“We can do this, but you are 800 miles away and this project does not justify bringing us in. I know someone competent near you.”
That may cost them the sale.
It may also earn them years of credibility.
There is enormous value in being willing to say:
“I am not your best answer.”
Disclose Your Interest
If you sell the product you recommend, say so.
“Full disclosure: we are a dealer for this manufacturer.”
Fine.
Now explain why it fits.
If you represent the manufacturer, say so.
If you compete with the company being discussed, that may matter too.
Disclosure does not invalidate an answer.
Hidden incentives make people distrust one.
The Design Engineer Has a Different Job
A good design engineer starts with requirements, not inventory.
The job is to begin with the project, not with products sitting in a warehouse or on a dealer line card.
A competent engineer asks:
What does this project require?
Then evaluates equipment against those requirements.
The engineer’s job is not to find a place to use the products they already sell.
A good engineer may ultimately specify expensive equipment.
They may also tell you that what you already own is fine.
They may tell you to spend less in one area and more in another.
They may identify infrastructure work that matters more than the shiny equipment.
They may tell an integrator that the integrator’s preferred product does not satisfy the design.
That independence has value.
The design engineer and the integrator may be the same company or even the same person.
They may not.
What matters is whether the process began with requirements or with a product list.
“DM Me, I Can Help”
Maybe you can.
But if the useful answer disappears into a private message, the technical group learns nothing.
The next person searches and finds:
“DM me.”
Wonderful.
What was the diagnosis?
Unknown.
What fixed it?
Unknown.
What should the next person test?
Apparently they should also DM you.
If there is private information involved, take that part private.
If someone needs a quotation, take that part private.
If the discussion becomes a consulting engagement, take that private.
But when the answer can reasonably remain public:
A public technical question deserves a public technical answer.
That is how one person’s problem becomes useful to the next hundred people.
16. Good Questions, Bad Questions, and Questions That Got Better
The earlier sections teach the principles.
Here is what they look like in practice.
1. Bad: Powered or Passive?
“Small to medium church. Powered or passive?”
Problem: Size is not a technical specification. The application, infrastructure, budget, service requirements, and coverage are missing.
Better:
“We have a 350-seat contemporary church with permanently installed mains and subs. We have no existing amplifier infrastructure but do have power near the loudspeaker locations. We are comparing powered versus passive primarily on serviceability, reliability, and installed cost. What tradeoffs should we consider?”
2. Bad: Who’s Your LED-Wall Guy?
“Looking to price an LED wall. Who is your go-to?”
Problem: Manufacturer? Integrator? Installer? What size? Pixel pitch? Viewing distance? On camera? Power? Long-term service?
Better:
“We are considering a permanent indoor 16 × 9 wall with a closest viewing distance around 25 feet. It will be used heavily on camera. Long-term support and replacement-panel consistency matter more than lowest purchase price. What requirements should we establish before requesting quotes?”
3. Bad: Best Wireless Mic?
“What are the best wireless microphones?”
Problem: Best for what?
Better:
“We need four wireless handhelds for youth worship and occasional speaking and may grow to eight channels. Reliability matters more than lowest price. What systems and frequency ranges should we evaluate for our location?”
4. A Question That Got Better
Initial:
“Best PTZ camera for a church on a budget?”
Then:
UPDATE: Budget is under $1,000 all-in. We already own an ATEM Mini and streaming computer. Three front cameras block a pew, so we want to move to the rear and would prefer a single PTZ.
Much better.
Now the answer can address the actual constraints.
It may still be:
“You may need more budget, more light, or different expectations.”
5. Good Question, Wrong Assumption
“Where should we hang these two powered 12-inch speakers to fix our coverage?”
If the loudspeakers were selected before the coverage problem was analyzed, the useful response is:
“What problem were you trying to solve, and what led you to determine that those two loudspeakers would solve it?”
That is not being difficult.
That is design.
6. Safety
“Can I hang it this way?”
If the system involves unknown structure, improvised hardware, unrated chain, open eye screws, or equipment not intended to be suspended:
Stop and get someone qualified on site.
A photo on Facebook is not engineering approval.
7. Good Question, Bad Answers
Sometimes the asker does everything right.
They provide:
- exact models,
- system topology,
- measurements,
- symptoms,
- tests already performed,
- budget,
- and a specific question.
Then the responses are:
“Buy Shure.”
“Get an X32.”
“QSC.”
“Call me.”
“I’ve been doing this 40 years.”
The asker did their job.
The responders did not.
A good answer should survive one simple follow-up:
Why?
If it cannot, keep reading.
17. A Question Template You Can Actually Use
You do not need to answer every one of these before posting.
But if the information is available, include it.
And if you cannot answer several of them, that may tell you what you need to investigate before asking the group.
What Problem Am I Actually Trying to Solve?
Not:
“What product do I want?”
The actual problem.
What Am I Trying to Accomplish?
Describe the desired result.
What Equipment or Software Is Involved?
Include, when relevant:
- manufacturer,
- model,
- firmware,
- software version,
- frequency band,
- amplifier mode,
- network hardware.
What Does the System Look Like?
Give the signal path or topology.
For example:
Vocal mic → receiver → console → matrix → DSP → amplifier → loudspeaker
What Did I Expect to Happen?
Be specific.
What Actually Happened?
Describe the symptom.
When Did It Start?
Did it ever work correctly?
What Changed?
Firmware?
Cable?
Computer?
Stage layout?
Routing?
Network?
Power?
New equipment?
What Have I Already Tested?
List the tests.
What Happened When I Ran Those Tests?
The result matters.
What Do I Know for Sure?
Facts.
What Have I Actually Measured?
Measurements beat adjectives.
What Am I Assuming?
Be honest.
What Have I Not Verified Yet?
Say that too.
What Constraints Matter?
Depending on the question:
- budget,
- room dimensions,
- viewing distance,
- SPL requirement,
- wireless channel count,
- portable versus installed,
- power availability,
- lighting conditions,
- operator skill,
- service expectations,
- geography,
- future expansion.
What Is My Specific Question?
Give people something they can answer.
Not:
“Thoughts?”
And definitely not:
“…and GO!”
The Short Version
If you do not want to use the whole template:
What problem am I trying to solve?
What equipment is involved?
What did I expect?
What actually happened?
What have I already tried?
What specifically am I asking?
Answer those six well and you are already ahead of a surprising number of technical posts.
18. Closing
Good technical questions are a learned skill.
So are good technical answers.
You do not have to know the answer.
You do have to participate in finding it.
Do some homework.
Describe the system.
Separate evidence from assumptions.
Answer the questions people ask.
Run the tests.
Update the original post.
Respect other people’s time.
Accept correction.
Come back with the solution.
And if you are answering:
Answer the actual question.
Justify your answer.
Show your work.
Admit what you do not know.
Do not turn every discussion into a sales opportunity.
Contribute when there is nothing to sell.
Teach something when you can.
A technical community is not a free help desk.
It is a group of people solving problems together.
Before you ask—
and before you answer—
ask one more time:
What problem are you trying to solve?
Why ESR Is Here
Eric S. Raymond’s writing had a real influence on how I learned to think about technical problems.
There is also one entirely irrelevant coincidence I have always enjoyed:
Eric Steven Raymond. Eric Steven du Toit.
No technical conclusion should be drawn from this.
I first encountered How To Ask Questions The Smart Way during my years working in large-scale Linux and Unix systems engineering. Over more than two decades in that world, the underlying habits became familiar: do your homework, define the problem clearly, gather evidence, question your assumptions, respect the time of the people helping you, and cut through the noise.
Those habits carried naturally into audio, AV integration, broadcast, and live production.
The tools changed.
The underlying discipline did not.
That same mindset is part of the culture we try to maintain today: get to the point, ask the uncomfortable question when it needs to be asked, test assumptions, and care more about finding the right answer than protecting a bad one.
None of that means the opinions in this article are correct simply because of my background.
They still have to stand on the strength of the technical reasoning.
That is the point.
Credit Where It’s Due
This article was heavily inspired by Eric S. Raymond and Rick Moen’s classic essay, How To Ask Questions The Smart Way.
Their article was written for hacker and open-source communities, but many of its underlying ideas remain just as relevant in church technology, live production, AV integration, broadcast, and today’s online technical groups: do your homework, ask clearly, provide useful evidence, respect the time of the people helping you, and participate in solving your own problem.
This article is an independent discussion of those ideas for the technical communities in which we work. It is not a reproduction or modified version of their article.
The original is worth reading.