The Art of Asking Better Questions | Essay 01
An ancient Buddhist dialogue, a modern organizational puzzle, and a question we rarely ask about collective performance.
Imagine assembling ten exceptional professionals: an outstanding architect, experienced engineers, a brilliant designer, a respected product manager, and a delivery leader with an impressive record. Every résumé is convincing.
Six months later, the project is behind schedule. Decisions take weeks, meetings end without agreement, and each department believes another is responsible for the problems.
Now imagine a second team whose members are competent but less celebrated. They ask questions early, share information freely, and make decisions without endless negotiation. Their project succeeds.
How can a group of individually brilliant people produce disappointing results while a less accomplished group performs remarkably well?
We evaluate the people who make up a team. We rarely evaluate what happens between them.
To see why that matters, begin with a conversation from ancient India.
A King Who Asked the Right Questions
The Milindapañha, or The Questions of King Milinda, is a Buddhist philosophical dialogue between King Milinda, traditionally identified with the Indo-Greek ruler Menander, and the monk Nāgasena. Its method is what makes it remarkable. The king does not accept answers politely. He questions, challenges, and demands explanations, and Nāgasena replies with reasoning and carefully built analogies.
The most famous exchange concerns a chariot. Asked his name, Nāgasena says it is only a conventional designation, not the name of an independent, permanent self. The king objects: if there is no permanent self, who acts, who learns, and who bears the consequences? Nāgasena asks how the king arrived. By chariot, the king replies. Then is the chariot its wheels? Its axle? Its frame or pole? The king answers no to each, and cannot point to a chariot existing apart from its parts. Yet he arrived in one, and both men understand what that means.
Nāgasena's point is that "chariot" is a designation that depends on its components, and that a person is likewise designated in dependence on changing physical and mental processes, with no independent, unchanging self required. It would be misleading to say he was explaining teamwork, or that Buddhist non-self is another name for systems thinking.
But borrowed loosely, the image still helps. A pile of wheels, axles, and poles is not yet a chariot. It becomes one only when the parts are put together in a particular way, and that arrangement is what carries the king anywhere.
A list of capable people is in the same position. What exactly do we mean when we say we have assembled a team?
When the Parts Are Right and the Whole Is Wrong
Suppose a company builds a new product. The product manager promises a feature without discussing its technical implications. The architect designs a solution without understanding the customer's real constraints. The developers implement the specification precisely, the tester confirms the software matches it, and the delivery manager reports that every milestone was met. When the customer finally uses the product, it does not solve the original problem.
Nobody necessarily lacked competence. Each person did their assigned task correctly. The failure lived in the connections between the tasks: the organization divided the work but lost the shared understanding of the problem.
Incentives make this worse. Sales is rewarded for winning customers, so it promises customization. Engineering is rewarded for on-time delivery, so it prioritizes speed. Operations is rewarded for lower delivery costs, so it limits support. Customer service is rewarded for closing tickets quickly, so it aims for fast resolution. Finance is rewarded for controlling spend, so it postpones investments whose benefits are hard to measure. Every function has a legitimate goal and evidence of progress. Yet customers grow frustrated, rework piles up, and profitability slips.
This is a core insight of systems thinking, which Donella Meadows sets out in Thinking in Systems: behavior comes not only from components but from the relationships, feedback loops, incentives, and constraints among them. Examine each department alone and everything appears to work. Examine the whole customer journey and the organization is working against itself.
Even the product reflects these connections. In 1968, the programmer Melvin Conway observed that organizations tend to design systems that mirror their own communication structures. If the teams building a product cannot talk to each other, the product will show the seams.
The psychologist Ivan Steiner put the general principle in a formula: a group's actual productivity equals its potential productivity minus its process losses. Talent sets the ceiling. Coordination, communication, and motivation determine how much of that ceiling is reached.
These failures are hard to catch because there is no obvious villain and no spectacular mistake. There is only a series of locally reasonable decisions that add up to an unreasonable result, and the problem can stay invisible until the final outcome arrives. Many of the most important organizational problems sit in the spaces between responsibilities, and because those spaces belong to no single department, they can go neglected for years.
What the Research Says
Research on collective performance offers useful evidence, though it is more nuanced than the popular claim that teamwork matters more than intelligence.
In 2010, Anita Woolley and colleagues published a study in Science asking whether groups show a measurable collective intelligence. Across experiments with 699 participants working in small groups, they found a general factor that predicted performance on a range of tasks. In their studies it was not strongly correlated with the average or maximum intelligence of the members. It was associated with social sensitivity and with more equal participation in conversation.
The debate did not end there. A later study by Timothy Bates and Shivani Gupta reported a much stronger link between individual intelligence and group performance. That disagreement matters, because it warns us against swapping one simplistic belief (hire brilliant people and success follows) for another (individual ability hardly matters). Both go too far. It is also worth remembering that these were short tasks done by groups assembled in a laboratory. Real teams have histories, hierarchies, and stakes, so the findings are suggestive rather than settled.
A second line of research looks at one of the conditions that may help. In 1999, Amy Edmondson studied 51 work teams in a manufacturing company and examined psychological safety: the shared belief that people can take interpersonal risks without being punished or humiliated. She found that psychological safety was associated with team learning behavior, which was in turn associated with performance. The study was correlational and drawn from a single company, but a later meta-analysis by Frazier and colleagues found psychological safety associated with outcomes including information sharing, learning behavior, and performance.
This does not mean successful teams avoid disagreement. Quite the opposite. People need enough confidence in their working relationships to say "I think we have misunderstood the requirement," "I made a mistake," "I don't know," or "Before we proceed, can we examine this assumption?" Those sentences sound ordinary. In many organizations they are surprisingly hard to say.
The Junior Engineer Who Remained Silent
Imagine a junior engineer reviewing a system designed by a highly respected architect. The engineer notices a potential weakness. But the architect has already defended the design in several meetings, the deadline is close, and everyone else seems satisfied. The engineer says nothing.
Months later, the weakness causes a production incident. The first questions are predictable. Why wasn't the issue caught earlier? Why didn't the review process find it? Why wasn't the engineer more proactive?
Those are fair questions. But there is another one worth asking: what made speaking up harder than staying silent?
Perhaps the architect routinely dismissed challenges. Perhaps the meetings rewarded agreement. Perhaps raising the concern would have delayed the release and hurt the team's performance rating. The engineer's knowledge was present, and the organization failed to use it.
A capability that cannot influence a decision has limited practical value. A company can employ highly knowledgeable people and still build an environment that keeps their knowledge from reaching the places where it matters. The failure is then not only one of expertise. It is a failure of organizational design.
Trace One Failure
The usual response to poor team performance is to look for better people, better processes, or better tools. Sometimes that is exactly right. But before changing the components, understand the connections.
Pick one recent failure, such as a missed deadline, a rejected deliverable, or a production incident, and follow the work from the original request to the final outcome. Ask:
- Where did the understanding of the problem change?
- Which assumption was never tested?
- Where did information stop moving?
- Which decision waited because ownership was unclear?
- Which incentive encouraged someone to protect a departmental target at the expense of the overall result?
- Who recognized the problem early but lacked the authority, confidence, or opportunity to act on it?
These questions do not remove personal responsibility. They make it possible to tell individual mistakes from recurring system failures. That distinction matters because replacing a person may remove a symptom while leaving the underlying conditions untouched. A new hire enters the same environment, meets the same incentives, and eventually produces a similar result. The organization concludes it has another people problem. What it may actually have is a design problem.
Why AI Makes the Question More Important
Artificial intelligence adds another dimension. It is accelerating individual tasks, and there is evidence for that. In a controlled experiment by Sida Peng and colleagues, developers using GitHub Copilot completed a programming task about 56 percent faster than a control group. Analysts can draft requirements faster, developers can generate code faster, testers can create cases faster, and support teams can draft replies faster.
But a workflow moves only as fast as its slowest stage. This is the central idea of Eliyahu Goldratt's Theory of Constraints: speeding up steps that are not the bottleneck does not improve overall throughput. It moves the bottleneck.
Imagine a product team using AI throughout development. Requirements appear in minutes, design alternatives almost instantly, code rapidly, and automated tests run continuously. The output looks impressive. Yet the customer still does not get the right product, because nobody resolved the original ambiguity about what the customer needed. AI accelerated the production of answers before the organization had agreed on the question.
Or the output may grow faster than reviewers can keep up, so the bottleneck moves from creation to verification. Or teams may generate more options than decision-makers can reasonably weigh, so it moves from execution to judgment. None of this is inevitable, and well-designed AI workflows can improve coordination as well as individual productivity. But the distinction is essential.
Making every activity faster is not the same as making the whole system more effective.
Before counting how many documents, lines of code, or tasks AI has produced, organizations should ask how much of that work reaches a verified, valuable outcome. The customer experiences the whole system, not its productivity dashboards.
The Question Behind the Question
Return to Nāgasena's chariot. His purpose was to make the king examine something he thought he understood and ask whether his explanation held up. That method is useful far beyond its original setting.
When an organization says it has assembled a great team, ask what makes it great. When a leader says a department is performing well, ask whether the larger system is. When a company celebrates AI productivity gains, ask whether customers have felt them. And when a project fails despite excellent people, resist the urge to look for someone to blame, and investigate how the pieces interacted.
There is a difference between having the necessary parts and having a functioning whole. It may lie in coordination, trust, incentives, decision rights, shared understanding, or the ability to correct mistakes. None of these makes individual excellence irrelevant. They determine whether individual excellence can become collective achievement.
We spend enormous effort finding the right people. We should spend just as much care understanding what happens when we bring them together.
A question to carry with you
Think of the most effective team you have ever worked with. What made it effective? Was it simply the talent of its members, or was there something in the way people listened, challenged, decided, helped, and trusted one another?
Now think of a team that struggled despite having capable people. What was different?
The answers may reveal more about collective performance than a stack of impressive résumés.
Think Sriram Better Thinking. Stronger Careers. Brighter Futures.