# Working With Engineering

> Partner with engineering as a collaborator, not a ticket-writer. Covers communication norms, technical empathy, scope negotiation, and building mutual trust. Use when PM-engineering relationships feel transactional, technical decisions are made without product input, or scope conversations become adversarial.

- Skill: `dragoon0x/working-with-engineering` (Agent Skill)
- Install (CLI): `npx skillmds@latest add dragoon0x/working-with-engineering`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dragoon0x/working-with-engineering/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: dragoon0x (https://skillmd.com/u/dragoon0x)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/dragoon0x/working-with-engineering

---


# Working with Engineering

Partner with engineers as collaborators, not requesters.

## How to use

- `/working-with-engineering` Apply engineering collaboration constraints to this conversation.
- `/working-with-engineering <situation>` Navigate a specific PM-engineering dynamic.

## Constraints

### Communication
- MUST communicate the why behind every requirement. Engineers make better decisions with context.
- MUST speak in terms of user problems and outcomes, not implementation instructions
- SHOULD learn enough technical vocabulary to have productive conversations without faking it
- NEVER tell engineers how to build. Define what and why. They own the how.
- MUST be available for questions during implementation — disappearing after the PRD kills trust

### Scope Negotiation
- MUST involve engineering in scoping before committing to timelines
- SHOULD ask "what's the simplest version that solves the user problem?" before "what's the full version?"
- MUST treat estimates as ranges, not commitments. Push for "1-3 weeks" not "exactly 10 days."
- NEVER negotiate against engineering estimates publicly — discuss concerns 1:1
- SHOULD be willing to cut scope to protect quality and team health

### Technical Empathy
- MUST respect tech debt as real work that prevents future problems
- SHOULD understand infrastructure and platform constraints that affect product decisions
- MUST factor engineering maintenance burden into feature prioritization
- NEVER treat "it works" as sufficient — performance, reliability, and maintainability matter
- SHOULD attend design reviews and architecture discussions to stay informed

### Trust Building
- MUST follow through on commitments. If you say you'll get an answer, get it.
- SHOULD protect engineering time from unnecessary meetings and context switches
- MUST advocate for engineering priorities (debt, tooling, performance) in roadmap discussions
- SHOULD celebrate engineering wins publicly, not just product launches
- NEVER throw engineering under the bus when something ships late or buggy

### Anti-Patterns
- The Ticket Machine: writing JIRA tickets and waiting for output without collaboration
- The Solution PM: specifying implementation details instead of defining problems
- The Scopecreep: adding "one more thing" after engineering has already committed
- The Meeting Hog: filling engineering calendars with syncs that could be Slack messages
- Ignoring Tech Debt: always prioritizing features and wondering why velocity drops