Technical decisions that need a stakeholder

Some technical decisions are for engineers to make. Others require a stakeholder — product, security, compliance, executive — to sign off. Getting the line wrong causes friction later.

Written October 2024 from experience leading technical decisions across teams.

What's usually engineer-only

• Code structure and internal API design.
• Library choices within a team's scope.
• Testing strategy and coverage.
• Local performance optimisation.
• Refactoring within an existing service.

What usually needs a stakeholder

• Choice of data store. Because operational cost, backup posture, and compliance implications all reach beyond engineering.
• Choice of external vendor. Because contracts, cost, and lock-in are business decisions.
• Change to authentication or authorisation model. Because security posture is not just engineering.
• Cross-team API contracts. Because the affected teams need input.
• Migration between major architectures. Because the cost is high enough to be a strategic decision.

The failure modes

• Engineers making stakeholder-scope decisions in isolation. The decision gets reversed later; the work is wasted; the stakeholder feels blindsided.
• Stakeholders making engineer-scope decisions. The stakeholder overrules the team on something they don't have context on; the team disengages.
• Ambiguity about which is which. Nobody knows if the decision is theirs; the decision stalls.

The clarity move

Every project should have a short list of decisions that need stakeholder input, agreed upfront. Everything else is engineer decision. Ambiguity resolved by conversation, not by resentment.

This is one of the higher-leverage moves an engineering leader makes. Getting it right saves months of friction. Getting it wrong is one of the most common causes of team dysfunction.