On some projects, nobody asks any questions. What could possibly go wrong? (Everything. Everything goes wrong.)
I knew a Scrum Master who would ask if anyone had questions. No one ever had questions.
When there were none, he’d say:
“No questions are good.”
It became a little mantra for him, and other people started repeating it.
Scrum Masters are supposed to coach developers.
He was coaching them to not ask questions.
Not to challenge.
Not to think too hard.
No questions are good, right?
Because it means no one has a question.
Um, no.
People did have questions. I knew — they told me afterwards.
They just felt like they couldn’t ask.
When you say “No questions are good”, it implies:
“Questions are bad.”
At that point, it’s not just bad Scrum.
It’s cargo cult Scrum.
The thing about questions is:
People say they want them.
But mostly, they just like the idea of them.
When questions get hard—or expose gaps—they suddenly don’t.
I was once interviewed for a QA role.
They handed me a fake requirements spec and asked if I had any questions.
“Oh, yes.”
They wanted me to ask questions. I wanted to ask questions, too.
Every question I asked showed how they’d not really thought this feature through. Each answer raised two more questions.
This went on for a while.
The whole purpose of this task was for me to ask questions about requirements — this is part of the role of a QA.
But the more I asked, the more frustrated they got.
Eventually, they cut me off:
“Well, we’re moving on.”
And that’s when I realized: They didn’t want a QA. They wanted a wizard.
Someone to wave a wand and make broken requirements magically work — without asking difficult questions that exposed uncomfortable gaps.
When I spoke to the recruiter afterwards, I told him:
“I’m rejecting them.”
He began venting too. They’d been rejecting candidate after candidate — because what they were really looking for didn’t exist.
There aren’t many certified wizards on LinkedIn.
Interviews are a two-way street. And sometimes, you don’t want to go down that road.
This wasn’t an isolated experience.
I’ve seen it at different companies, in different roles.
Poorly thought-out requirements getting waved through — not because they’re solid, but because no one wants to be that person.
The one who slows the meeting down.
The one who asks the awkward question.
The one who makes things harder.
But here’s the irony:
Asking awkward questions is part of the job.
If you’re not asking them, you’re just a code monkey.
And when it all goes sideways? Everyone gets flattened.
I told people questions mattered. But I realised I’d have to demonstrate it—mercilessly.
I had recently joined a new company. I didn’t know the politics. I didn’t want to rock boats.
But there we were: backlog grooming. A shiny new feature appeared.
They went through the description in a couple of minutes:
“Any questions?”
Silence. Everyone sitting there on mute.
I was QA. Technically, this wasn’t even my problem. I wouldn’t be implementing this story.
I could have stayed silent. But I couldn’t. My brain was screaming.
It was like watching a slow motion car crash. I could see the tree moving inexorably towards us. Everyone oblivious to the carnage that would follow.
We’d been having problems with poorly defined pieces of work spiraling out of control. People were frustrated, but they didn’t see the connection between having vague requirements and the disaster that comes from that.
After an uncomfortable pause, I came off mute:
“I have a question…”
Every question exposed another gap. Another blind spot. Another “oh, we hadn’t thought of that.”
Thirty minutes later, the feature was wreckage. A mercy killing.
I wasn’t trying to be mean. I was doing the developers a favor.
Not asking a question doesn’t resolve the question.
If these gaps weren’t exposed now, they’d be exposed mid-sprint, in code, or during testing — when they’re much harder to fix.
After the meeting, the tech lead messaged me privately:
“You did good. People needed to see how badly thought through this was.”
That was the point.
I only did that once. I only needed to do it once. The descriptions suddenly got a lot better.
When one person is already asking questions, other people feel more confident asking theirs too.
Sometimes I would ask one question to open a door.
Then they could pile in with their own — the ones they’d been too hesitant to ask before.
I liked it when other people asked questions. I didn’t need to keep thinking of them. It was like crowdsourcing ideas.
With five people all thinking, you get a wider range of viewpoints — and we often reached a solution that was far better than any one person could have reached alone.
I found the best way to get people to ask questions was to do story pointing. Everyone has to assign a point value.
That means they have to understand the story, identify the complexity, and anticipate the risks. It leads to questions.
Lots of them.
Some people think questions waste time in meetings. But compare that with the cost of not asking them.
I’ve seen developers spend weeks implementing a feature, only for it to fall apart when someone finally asked the question.
Asking a question where people know the answer takes seconds.
Asking one that people don’t?
It might save weeks of work.
Questions are the core of how humans think.
It’s how we evolve.
How we grow.
If we didn’t ask questions, we’d still be living in caves.
It’s how we learn as children.
How science works.
How philosophy works.
How bad ideas get exposed.
How good ideas get better.
Without questions, there’s no discovery.
Without discovery, there’s no improvement.
So ask your question.
Not to be awkward—but to make things better.
Because the right question at the right time?
Might be the only thing that saves a feature.
Questions are good.
Davide la Locomotive 
Leave a comment