Adopt a new policy
Internal governance, externally auditable.
Org-wide policy changes look like consensus and are usually compliance. The people most affected rarely speak up in the all-hands — they comply, then quietly route around the rule. Gathering private positions first tells you which teams will actually break before you ship the policy, and gives you an auditable record of who flagged what.
Should we adopt this policy across the organization?
Reference the draft inline. Contributors: which teams are disproportionately affected, what we measure to know it's working at 90 days, and the rollback condition if it isn't.
What each contributor weighs
Ask everyone to put these on the table privately, before they see another contributor's position.
- Which teams are disproportionately affected — positively or negatively.
- The specific metric you would watch at 90 days to know the policy is working.
- The rollback condition: what would tell you to reverse it.
- The edge case or team you think leadership is not seeing.
- Remote-work policy
- Compensation philosophy
- AI-tool acceptable use
How this decision usually goes wrong
- Designing for the median employee and breaking the important exceptions.
- Mistaking silence in the all-hands for agreement.
- No measurable success criterion, so the policy can never be judged or reversed.
- Shipping without a rollback trigger, making the change feel permanent and political.
How to run this decision in 48 hours
- Open a room seeded with the question above. Set a 48-hour deadline.
- Paste the opening context — keep it short. Engineers will not read more than 300 words.
- Invite by email. Each contributor submits position + reasoning + risks privately, before seeing anyone else.
- Read the synthesis. Claude maps consensus, dissent, blind spots, and confidence.
- Decide and log. The synthesis is the decision-log entry — no separate write-up.
A synthesis that names the teams who will struggle, the 90-day success metric, and an explicit rollback condition — a policy you can defend as auditable rather than imposed.
Related reading
- Why every distributed engineering team needs a decision log
- Anchoring bias in engineering decisions: what it is and how to defeat it