Hierarchy & Decision-Making

Power distance and the "just push back" trap:

The Netherlands scores among the lowest in the world on Hofstede's Power Distance Index — Dutch workplace culture assumes flat structures, direct challenge, and that titles carry little weight in a technical argument. Inviting pushback is a completely normal, low-stakes request in that context.

Many South and East Asian, Eastern European, and Latin American cultures sit much higher on the same index — where openly disagreeing with a manager, especially in front of others, can feel disrespectful regardless of what was said out loud. A single sentence of permission does not override that internalised norm, especially for someone new to the team who is still establishing trust.

Why "just push back" alone does not work:
1. It puts the entire burden of bridging the cultural gap on the higher-power-distance person
2. It is a one-time verbal statement competing against years of reinforced behaviour
3. It does not specify a safe mechanism — public real-time disagreement is the hardest form of pushback to give

What actually helps:
• Offer private, 1:1, or written channels for disagreement, not just live meetings
• Ask specific technical questions rather than "any objections?" — e.g. "Walk me through what could go wrong with this approach"
• Model the behaviour repeatedly: visibly reward the first disagreements that do surface
• Be patient — psychological safety across power distance is built over months, not stated once

Vocabulary:
• power distance — how much a culture accepts unequal distribution of power/authority
• flat structure — an organisation with few hierarchical layers
• push back — to resist or disagree with a proposal
• psychological safety — a shared belief that the team is safe for interpersonal risk-taking

Consultative vs. consensus vs. autocratic decision-making:

Three common models on global engineering teams:
• Autocratic: one person decides with little or no input — fast but can miss expertise and damages buy-in
• Consultative (common in Germany, much of continental Europe, and many large tech orgs): input is actively gathered from relevant people, but one accountable owner makes the final call and documents the reasoning — sometimes called "disagree and commit" in a milder form
• Consensus (common in some Scandinavian and cooperative cultures, and many US startups): the group must broadly agree before proceeding — high buy-in but can be slow, and can produce watered-down compromises

Why the American colleague read it as "top-down":
US startup culture often equates "we decided together" with the healthiest process, and a single decision-maker can look like an old-fashioned hierarchy. But consultative models are explicitly designed to combine broad input with clear accountability — they are not the same as one person deciding in a vacuum.

The accountability argument:
In consensus models, when a decision goes wrong, responsibility is diffuse ("the team decided"). In consultative models, the decision-maker owns the outcome — which many engineering cultures see as more honest, not less democratic.

Vocabulary:
• consultative decision-making — gathering broad input before one person decides
• consensus — a decision the whole group actively agrees with
• disagree and commit — voicing disagreement during debate, then fully supporting the decision once made
• decision owner — the person accountable for a specific decision's outcome

Making unwritten hierarchy norms explicit:

Unspoken hierarchy expectations are one of the most common sources of cross-cultural friction because neither party may realise a rule exists until it is broken. The American developer was not being disrespectful by their own cultural logic — answering promptly and confidently is often read as engaged and confident in the US. The discomfort came from an unstated norm ("juniors defer to senior views first") that was never communicated.

Two workable fixes — the point is not which one, but making it explicit:
1. Flatten and state it: "I genuinely want first impressions from everyone, regardless of level — please jump in." This works well for teams trying to build a low-power-distance culture deliberately.
2. Structure the order deliberately: seniors share context/framing first, then open the floor to junior input building on that — this respects a high-power-distance default while still gathering everyone's view.

Why silence on the norm is the real problem:
Without an explicit statement, everyone defaults to their own cultural assumption — and assumes everyone else shares it. This produces situations where one person feels disrespected and the other has no idea why.

Vocabulary:
• unwritten norm — an expectation that is understood but never stated
• seniority order — speaking or deciding in order of rank or experience
• open floor — inviting anyone to speak, without a fixed order
• deference — yielding to someone's judgment or authority out of respect

The RFC decision pattern:

The RFC (Request for Comments) model is a widely used engineering decision process, independent of any single national culture — it is common at companies with roots in the US, UK, and Nordic countries alike, and blends well with both consultative and consensus-leaning teams.

How it typically works:
1. A proposal is documented and shared broadly
2. Everyone can comment, ask questions, and raise concerns in writing
3. A designated owner reads all input and makes a final, documented decision
4. A clear window is left for anyone with a serious, unresolved objection to escalate before execution

Why the new hire was confused:
Someone from a strongly consensus-driven background (some Scandinavian cooperative traditions, some open-source communities) may expect group agreement to be required, not just gathered. The RFC model looks similar on the surface — everyone was asked for input — but the decision authority is different: one person decides, not the group.

Why this distinction matters practically:
Confusing "gathering input" with "requiring agreement" leads to real friction: someone who commented with reservations may believe their objection blocks the decision, while the decision-maker believes it was simply noted and outweighed by other factors. Naming the model explicitly ("this is RFC-style — I decide, but flag hard blockers by Friday") prevents this mismatch.

Vocabulary:
• RFC (Request for Comments) — a written proposal process inviting broad feedback before a decision
• decision owner — the person accountable for making and documenting the final call
• hard blocker — an objection serious enough that it must be resolved before proceeding
• cutover — the point at which a system switches from an old to a new implementation