When Is an Answer Enough?
Judging When Enough Is Known to Act
A software development manager in Austria asks why his Egyptian colleagues keep reopening tickets. In his workflow, an open ticket stops the work, so the question is costly for everyone. The more useful question is how people decide that enough is known to act, and what happens when two people use different criteria for that decision. The case shows how CuPS widens the explanation beyond culture, how Cultural Judgment determines what deserves weight in the situation, and why Connecting Contradictions becomes necessary only at the end.
The Setup
Florian is a software development manager in Austria. He is responsible for a project on software tests for advanced driver-assistance systems, including its requirements and the answers to developers’ clarification questions. About 90 percent of the programming is done by a team at the company’s Cairo site. Developers use a ticketing system to ask questions and seek clarification of requirements. It is Florian’s job to answer many of these tickets, and once a ticket is closed, the developer has what is needed to continue. If a ticket remains open, there is no green light to proceed with that part of the work.
In a team-development session, Florian described a recurring difficulty. He answers a question, and the developer, instead of moving ahead, returns with another one. At some point he feels that the conversation has left what the current step requires and moved into hypothetical scenarios. He calls this “looping,” and each additional round costs time and holds up the work.
A recent exchange with Ibrahim, a software project leader in Cairo who is accountable for what his team delivers, shows what he means. Ibrahim was working on a requirement for a backward-motion control system. He asked Florian to define parameters for a scenario in which the vehicle travels backwards at 200 kilometers per hour, and to specify a maximum permissible backward speed. Florian found the question practically irrelevant. “Who is going to drive 200 kilometers per hour backwards?” he asked, and he decided not to answer. Ibrahim did not treat the matter as settled and reopened the ticket.
So Florian’s question was: Why do my Egyptian colleagues keep coming back with new questions? It sounds simple, but it already carries interpretations. It turns a number of exchanges into a pattern, it turns individuals into a group, and it treats coming back as something that needs explaining, while Florian’s own way of deciding that a matter is sufficiently clarified remains largely unquestioned.
Where Traditional Intercultural Advice Stops Short
A conventional analysis would look for cultural differences that could explain the behavior: attitudes toward uncertainty, hierarchy, responsibility, initiative, or seeking approval before acting. That can be useful, but the reasoning can easily run like this: Egyptian employees need more certainty, so they ask more questions, so Florian should give more detail and plan for longer clarification cycles. This moves in one step from an observation to a cultural attribution and then to a recommendation.
The observation itself is already interpreted. Florian does not merely see another question. He sees a question that is too detailed, too hypothetical, and an obstacle to progress, while Ibrahim may see a requirement that is not yet resolved. The explanation also jumps to cultural differences before anyone has checked whether cultural differences are the strongest variable here. It treats the repeated question as the thing to be explained, when the more important difference may lie in the criteria Florian and Ibrahim use for deciding when enough has been clarified to justify action.
CuPS: Reopening the Explanatory Field
CuPS — Culture × Person × Situation → Behavior — asks us to consider culture, person, and situation together before explaining behavior. Applied to this case, it means not beginning with what Egyptians are supposedly like, but with what is actually happening between these two people in this particular work setting.
Situation
Florian and Ibrahim do not sit in equivalent positions in the workflow. Florian represents the requirements side. Ibrahim’s team turns those requirements into working software, and Ibrahim is accountable for what his team delivers.
There is another element that matters. Ibrahim perceives the relationship in client–deliverer terms. Florian is not formally his client, but Ibrahim sees his team as delivering against requirements that come from the other side. This perception affects where he locates authority and responsibility. If the requirement is incomplete, he may not see it as his role to decide what the missing parameter should be. From his perspective, that decision belongs to the side that owns the requirement.
A gap that looks theoretical from the requirements side therefore becomes concrete for the person who has to implement the specification and stand behind it. If the requirement says nothing about what happens above a certain speed, Ibrahim can make an assumption, leave the behavior undefined, set his own limit, or return the question to the requirements side. Each option distributes responsibility differently.
The ticketing system adds a structural element that is easy to overlook. Because an open ticket means that the developer has no green light to continue, reopening one is not a casual act. Ibrahim may consider the gap serious enough to justify stopping, or he may see no legitimate way to continue without an answer. The same fact explains Florian’s frustration, because each reopening returns to him as the person who has to resolve it. Both are responding to a system in which an unresolved question and an interrupted development step are closely connected.
The 200 km/h example also looks different from here. Florian hears a question about drivers, and about drivers the answer appears obvious. In safety-relevant software, however, the question may be what the system should do if such an input occurs anyway, through a sensor fault, corrupted data, simulation, or boundary testing. We cannot know from the case alone whether Ibrahim’s question is technically necessary, but Florian’s answer to himself — that nobody will actually drive that fast backwards — may not answer the question Ibrahim is trying to resolve.
One more detail matters. Florian chose not to answer, which for him meant setting the issue aside. For Ibrahim it meant having neither an answer nor a decision he could use as the basis for implementation. In the ticketing system, reopening the ticket is then the formal way of saying that the issue remains unresolved. Part of what Florian experiences as a cultural communication problem may therefore be produced by the structure of the work and by the way the two sides understand their respective responsibilities.
Person
Ibrahim may work in an especially analytical way, may have learned in earlier projects that unspecified conditions return later as defects, or may dislike making assumptions he could later be held accountable for. The same applies to Florian. His preference for staying with what is currently actionable can come from his role, his experience with deadlines, the number of tickets he has to answer, or his own understanding of efficient requirements management.
Another Austrian manager might welcome Ibrahim’s questions, and another Egyptian project leader might find them excessive. National categories cannot carry the explanation alone.
Culture
Culture enters after the situational and personal possibilities have been opened, and it may still matter a great deal. Different environments teach people different things about authority, accountability, initiative, responsibility, and what happens when someone acts without explicit approval. They can also shape expectations about how work itself should proceed: when a step is considered complete, how much ambiguity can remain before moving forward, and whether returning to an earlier question is understood as necessary refinement or as disruption of an already completed process.
Someone who has learned that judgment under ambiguity is valued may say, “The edge case is unlikely, so I will proceed.” Someone who has learned that responsibility remains with the person entitled to define the requirement may say, “This is not specified, it is not my place to decide it, and I need clarification.” These are not simply different levels of comfort with uncertainty. They reflect different assumptions about where responsibility begins and ends and about what responsible action looks like when something has not been fully specified.
In my own work with teams across the MENA region, I have repeatedly encountered situations in which responsibility for delivery and authority to define what is to be delivered are kept more sharply separate than some European managers expect. People may accept considerable responsibility for execution while still hesitating to change, complete, or reinterpret a requirement that they understand as belonging to another role or organizational level. That observation is particularly relevant here because Ibrahim appears to perceive himself primarily as the deliverer of something that the “client” side is responsible for defining precisely. This perceived role belongs first to the Situation in CuPS because it shapes where he locates decision authority and what he considers a legitimate assumption to make. Culture may nevertheless influence how strongly this distinction is understood, how natural it feels, and what kinds of action appear legitimate within it.
Florian’s interpretation also has to be culturally reopened. In my work with different Central European technical organizations, I have often encountered a strong orientation toward defined processes, sequential responsibility, closure, and the completion of one step before the next one proceeds. Within such a linear approach, a clarification ticket represents a point in a process: a question is raised, an answer is provided, the issue is closed, and development moves forward. Reopening a ticket that Florian believes has already been resolved can therefore appear not simply unnecessary but as a disruption of the expected progression of work. His use of the word “looping” may itself reflect this understanding. What he experiences as returning to a completed point may be experienced by Ibrahim as continuing to refine a specification that is not yet complete.
This makes the cultural tension more interesting than a conventional contrast between cultures with high and low uncertainty tolerance. The two persons may be working with different assumptions about what constitutes responsible progress. Florian’s logic privileges sufficient closure so that the process can continue. Ibrahim’s logic may privilege sufficient clarification: rather than fill a gap in the requirement with his own assumption, he waits for the person he believes is entitled to decide it. From Florian’s perspective, reopening can look like failure to move forward. From Ibrahim’s perspective, closing prematurely can look like failure to resolve what still belongs to the requirement owner.
Culture may also shape how a non-answer is interpreted. Florian may regard his decision not to engage with an unrealistic scenario as sufficient indication that the issue should not block progress. Ibrahim may instead see the absence of an explicit decision as evidence that the requirement remains unresolved. Again, the difference cannot be attributed to culture alone, but cultural experience may influence what each person regards as an adequate form of closure.
The behavior can therefore be influenced by culture without being reducible to it. CuPS replaces the question of whether the behavior is cultural with a more useful one: What combination of cultural, personal, and situational factors makes the behavior of both Ibrahim and Florian reasonable from their respective positions?
Cultural Judgment: Deciding What Deserves Weight
CuPS widens the field of explanations. Cultural Judgment (CJ) is needed for the next step, because listing several interpretations is not yet judgment. Cultural Judgment examines which interpretations are plausible in this situation, what evidence supports them, how much weight each deserves, what remains uncertain, and what action is justified before certainty arrives.
Florian started with one interpretation: the Cairo team asks too many unnecessary questions. Cultural Judgment keeps several alternatives open. The technical interpretation says that Ibrahim has found a real gap in the requirement. The role and accountability interpretation says that he implements rather than defines, and that asking transfers responsibility for an undefined parameter to the person he sees as entitled to decide it. The personal interpretation says that he simply works more exhaustively. The organizational interpretation says that the workflow itself produces reopened tickets because developers cannot settle certain ambiguities on their own and cannot continue while a ticket remains open. The cultural interpretation says that learned expectations about authority, responsibility, initiative, and uncertainty shape how he reads an incomplete requirement.
These explanations are not mutually exclusive, and Florian does not have to find the one true explanation before he acts. Several may be operating at the same time. The disciplined question is not which explanation wins, but which explanations matter here, and how much weight should each receive?
He can also test them at relatively low cost. He can ask Ibrahim what the missing limit would actually change for the implementation. He can check whether other Cairo colleagues reopen tickets in the same way and whether developers at other sites do the same for comparable requirements. He can look at which kinds of requirements tend to be reopened.
If the answers point to a real gap, the technical explanation deserves substantial weight and an intercultural explanation may add little. If Ibrahim could proceed technically but holds back because he believes only the requirements side may decide, role perception and accountability move to the center. If the pattern appears repeatedly even where people clearly have decision authority, cultural or organizational expectations become more plausible.
Cultural knowledge enlarges the range of interpretations available. Cultural Judgment weighs those interpretations in the concrete case by examining what supports them and how much weight each deserves. That moves the expertise from knowing about cultures to judging a particular situation.
What “Looping” Actually Means
Cultural Judgment also lets us look at Florian’s word “looping,” which hides a judgment inside what sounds like a neutral description. A loop returns to where it started. Ibrahim may experience the conversation differently. For him, the specification may become more complete with each round: a question is answered, an implication becomes visible, and a new question follows. From his side the sequence is cumulative, not circular.
So the two may disagree not only about individual questions but about the threshold of sufficiency. Florian asks: do we know enough to continue with the task? Ibrahim may ask: have the relevant uncertainties been resolved well enough for me to implement this responsibly?
Neither standard is better in every situation. In this workflow the disagreement is also costly. A high threshold of clarification slows development. A low threshold may allow unspecified behavior into software where an unresolved boundary condition can later matter.
The issue is therefore not simply that one side asks more questions. The deeper issue is that the two sides may use different criteria for deciding when uncertainty has been reduced enough for action.
Connecting Contradictions
At this point, the case reveals a cultural tension that cannot be reduced to a misunderstanding or solved simply by deciding whether Ibrahim’s 200 km/h question was technically necessary. Two different logics of responsible work appear to be operating simultaneously.
The contradiction can be expressed as progress through closure ↔ achieving high quality demands through iterative clarification. Both logics perform an important function. Closure protects coordination, pace, and the ability of a complex development process to move from one step to the next. Iterative clarification protects specification quality by allowing newly visible implications to be examined rather than suppressed merely because an earlier stage was expected to be complete.
This tension is connected to a second contradiction that the case has already exposed: ownership of delivery ↔ limits of decision authority. Ibrahim is expected to take ownership for what his team delivers, which requires initiative and judgment. At the same time, he does not necessarily perceive himself as entitled to define missing elements of a requirement that belongs to another side. Florian expects enough autonomy for the work to continue, while also expecting the development team not to redefine requirements that are not theirs to define.
The two contradictions reinforce each other. Florian’s process logic makes repeated clarification look like a failure to close and move forward. Ibrahim’s understanding of role authority makes some forms of closure difficult because he does not regard himself as entitled to resolve the remaining ambiguity independently. The more Florian expects closure, the more Ibrahim may feel pressure to decide something that he regards as outside his authority. The more Ibrahim returns unresolved points to the requirements side, the more Florian experiences the process as failing to progress.
This is precisely where Connecting Contradictions becomes useful. The task is not to decide that linear progression is better than iterative clarification, nor that autonomy is better than deference to requirement ownership. Each logic protects something that the project needs. The problem begins when either is treated as sufficient on its own.
If closure dominates, the project may move efficiently while carrying assumptions that were never genuinely resolved. If iterative clarification dominates, the specification may become increasingly precise while development repeatedly stops. If autonomy dominates, developers may silently make decisions that effectively redefine requirements. If deference dominates, responsibility for every ambiguous point returns to the requirements side and the ownership expected from the development team becomes difficult to exercise.
Connecting Contradictions therefore means keeping these logics in relation rather than trying to eliminate one of them. The practical challenge is to create forms of closure that permit progress without pretending that every uncertainty has disappeared, and forms of clarification that preserve legitimate questions without automatically returning the entire process to an earlier stage. At the same time, the team needs enough clarity about decision authority that developers know which uncertainties they are expected to resolve through professional judgment and which genuinely belong to the requirements side.
The 200 km/h example exposes both tensions at once. Florian sees a question that should not prevent the process from moving forward. Ibrahim may see an unresolved specification that he is not entitled to complete himself. Whether the ticket should close therefore cannot be decided simply by asking whether the scenario is likely. The judgment has to consider the technical consequences, the purpose of the clarification, who has legitimate authority to decide, and whether the issue can remain open without blocking the current development step.
The 200 km/h question exposes this tension particularly well. If Ibrahim defines the upper limit himself, has he exercised appropriate engineering judgment or altered a requirement that was not his to define? If he sends the question back to Florian, has he acted responsibly or failed to show sufficient initiative? There is no general answer outside the concrete situation. The judgment depends on the technical consequences, the distribution of authority, and the degree of discretion the project actually intends the Cairo team to exercise.
The earlier tension between progress despite ambiguity and reduction of ambiguity before action still matters, but it is better understood as a consequence of this deeper contradiction. Progress requires people to act without complete certainty, while the limits of their authority determine which uncertainties they are entitled to resolve themselves. Connecting Contradictions does not remove that tension. It makes it possible to work with it deliberately rather than allowing each side to demand something from the other that appears reasonable from its own position but contradictory from the perspective of the system as a whole.
What I Would Recommend Today
If the problem lies in the interaction between closure and iterative clarification, and between delivery ownership and decision authority, the response should not begin by asking Ibrahim to show more initiative or Florian to provide more detailed answers. The practical task is to create a way of working in which progress does not require artificial certainty and clarification does not automatically stop the process.
- The first level is what Florian can change immediately in the interaction itself. When a question appears unnecessary or too hypothetical, he can ask what consequence the unresolved point has for implementation rather than deciding from his own perspective that the question is hypothetical and therefore irrelevant. In the 200 km/h example, “What consequence does the missing upper limit have for your implementation?” would help distinguish a technically blocking issue from an issue that can remain unresolved without preventing the current task from continuing. If Florian decides that the point does not require an answer now, he should nevertheless make that decision explicit and state what Ibrahim is authorized to assume. This creates closure without requiring Ibrahim to infer that silence means permission to proceed.
- The second level concerns the workflow. A system in which every unresolved question is either open and blocking or closed and finished forces the team into a false choice between complete clarification and complete closure. The workflow should allow an intermediate state: an issue can remain documented and unresolved without necessarily stopping the current development step. A distinction between a blocking clarification, an agreed assumption, and a non-blocking open point would preserve the iterative character of technical clarification while protecting the linear progression that the wider development process requires.
- The third level concerns decision authority. Florian and the Cairo team need a shared understanding of where professional engineering judgment is expected, where assumptions may be made and documented, and where a decision must return to the requirements side. This boundary will never remove every ambiguous case, nor should it. Its purpose is to prevent the same action from being interpreted in opposite ways: Florian seeing escalation as lack of initiative while Ibrahim sees it as responsible respect for requirement ownership.
Neither intervention is intercultural in appearance. That is part of the point. The intercultural work occurs in recognizing that what one side experiences as responsible closure may be experienced by the other as premature closure, and that what one side experiences as responsible clarification may be experienced by the other as failure to move forward. Once that tension is understood, the practical response may look like ordinary process design, clearer decision rights, and better communication. The difference lies in the judgment that led there.
Questions for the Team
- When is a clarification sufficiently resolved for development to continue, even if not every open question has been fully closed?
- Which uncertainties should developers resolve through professional judgment or documented assumptions, and which require an explicit decision from the requirements side?
- How should new implications that emerge after an answer be handled so that legitimate iterative clarification does not automatically become either “looping” or a reason to stop the entire process?
What This Case Shows
CuPS widens the field so that culture is considered alongside the person and the situation. Cultural Judgment weighs the resulting interpretations by asking which are plausible, what evidence supports them, how much weight each deserves, and what action is justified despite remaining uncertainty. Connecting Contradictions deals with what remains when two legitimate but competing logics continue to matter simultaneously and neither can simply be dropped.
In this case, that final tension is not simply between speed and thoroughness. It lies between the expectation that the Cairo team should take ownership for delivery and the limits of the authority it perceives itself to have over the requirements it is expected to implement. That tension cannot be solved by telling one side to become more autonomous or the other to provide more detail. It has to be judged repeatedly at the boundary between responsibility and authority.
The original question was why the Egyptian colleagues keep asking questions. On closer examination, that question is too narrow. The more useful question is how people decide that enough is known to act, and what happens when responsibility for acting and authority for deciding do not fall in exactly the same place. That is no longer a question about communication style. It is a question about judgment: where the line between the two sits, and who gets to draw it.
Explore the Cultural Judgment Framework
Cultural Judgment
How culturally complex situations can be interpreted, evaluated, and translated into justified action.
Explore Cultural Judgment →Connecting Contradictions
How to work with apparently contradictory but interdependent logics that remain relevant simultaneously.
Explore Connecting Contradictions →Case Analyses
Further applications of Cultural Judgment, CuPS, and Connecting Contradictions to concrete intercultural situations.
View All Case Analyses →