It started with a simple question. What, I asked the Hardware Test guys, are the power consumption and heat dissipation measurements for the new switch models? I needed that data for the Technical Specifications section of the user guide.

Questions and answers in Seoul, Korea (by WordPress user george2008)
To be helpful, I included with my request the chart for the existing models — my way of saying “I need numbers just like these.”
One of the Test guys looked at the chart, paused, and said, “I’m not sure these numbers are so good.”
That sparked a discussion — among 5 of us from Hardware Test, Development, and Tech Pubs — about how the data is collected: is it measured at the power source or at the switch? About how to quantify the data: should heat dissipation be expressed in wattage or in BTUs? About why our customers would want the data: to monitor lab conditions, to plan how best to deploy power supplies. or both.
(That’s right: these mechanical engineers wanted to know not just about feeds and speeds but about the customers’ requirements. Is it any wonder I’m proud to work with them?)
It happens all the time
If you’re a technical writer, you’ve seen it happen too. Your questions open the door to more questions and sometimes to whole new lines of inquiry. Your questions, many times, end up influencing the whole project for good.
Why is that?
For one thing, we’re good at asking questions. My blogging colleague Sharon Burton notes that curiosity is a hallmark of technical communicators, and curiosity often manifests itself in questions. Questions that stimulate thought, questions that force people to reach beyond pat answers, questions that no one’s asked before.
I admit that my initial question about power consumption wasn’t profound. But when the first engineer stroked his chin and paused, I was quick to draw him out, to get him to think out loud and see where the conversation would go.
We’re advocates for our readers, for our audience. We can understand all of the deep-down technical stuff the engineers understand, but we’re not satisfied until we can explain it in terms our readers will find meaningful. Sure, I want to know the amperage reading when all 24 ports are moving data at 10 gigabits a second. But what I really want to know is how a network operator can make decisions based on that information.
We’re persistent. Maybe we’re driven by our innate curiosity. Maybe by our loyalty to our audience. Probably both. Whatever it is, we persist until we have the answers we need — until we can give our readers the answers they’ll need.
Our patron saint is television’s Lieutenant Columbo, who never dazzled anyone with his brilliance but who always persisted, and who always ended up asking the right questions at the right time to crack open the case.
It’s part of our value proposition
I’m proud of the technical writer’s ability to ask good questions. I’m proud that we bring about positive changes, that we contribute value, in this way.
In the lab today, it started with a simple question. The answer turned out to be more complicated than anyone expected. But it was the right answer. It was the best answer.
I’m going to keep asking questions.