Ask for Advice, Not Permission (2015)

Advice vs Permission Framing

• Many see “ask for advice, not permission” as a useful psychological reframing: it encourages ownership while reducing gatekeeping and blame-shifting.
• Others argue the distinction is overblown; in practice “asking” is just collaboration, and people don’t micro-parse whether it was labeled advice or permission.
• Some prefer this framing to “ask forgiveness, not permission,” which is criticized as a license for rash or arrogant decisions.

Responsibility, Blame, and “Backstabbing”

• Large subthread on teammates who approve a design, then later—often in front of management—denounce it and distance themselves.
• One view: if you had a chance to review and said it was fine, you share responsibility and shouldn’t later act as if the flaws were obvious.
• Counterview: late discoveries, shifting priorities, or poor initial context can make issues visible only at implementation time; not all late criticism is malicious.
• There is strong concern about “sociopathic” behavior: setting peers up to fail, then using hindsight criticism to advance politically.

Experience Level and Autonomy

• Broad agreement that high autonomy works best with experienced, “sober” engineers; extending the same to juniors can be risky.
• Examples given of juniors pushing unsafe or sweeping changes (large PRs, risky tech choices) and seniors being painted as “gatekeepers” when they push back.
• Others argue enthusiastic juniors are preferable to obstructionist seniors, but concede that safety-critical or complex systems need tighter controls.

Feedback Culture and Process

• Many note people avoid giving critical feedback to adults; others say in some cultures unsolicited critique is common.
• Suggested mitigations: explicit design reviews, user stories tied to design, third‑party review, glossaries, office hours, and structured decision records.
• Complaints about Agile practices that bury design decisions across sprints, enabling 11th‑hour re-litigation by senior engineers who skipped earlier discussions.

Management Practices and “Disagree and Commit”

• “Disagree and commit” is cited as a counter to backstabbing: argue hard during design, then support the agreed plan and own its outcomes.
• Some managers describe inviting broad participation (design sessions, triage, postmortems), then enforcing team decisions and forbidding unilateral sniping.

Limitations and Edge Cases

• Commenters stress exceptions: legal exposure, actions that harm others, or areas with strict accountability still require explicit permission.
• Several caution against treating any of these slogans as universal rules; context, power dynamics, and company culture are decisive.