---
name: jamestorrevillas/cross-functional-collab
source: https://app.decimal.ai/s/jamestorrevillas-cross-functional-collab@1/SKILL.md
source_sha256: 0e859551486c
---

# Cross-Functional Collaboration

## The Translation Problem

Developers think in systems. PMs think in outcomes. Designers think in experiences. Executives think in risk and cost. None of these are wrong — they're just different lenses on the same reality.

**Your job:** Translate fluently between all of them.

---

## Working with Product Managers

### What PMs Need From You
- Honest estimates (not optimistic, not padded)
- Technical risk flagged early — surprises are worse than bad news
- Alternatives when you can't build exactly what they ask
- Business impact framing when you need to deprioritize tech debt

### What You Need From PMs
- Clear acceptance criteria before you start
- Priority when scope is too large for the sprint
- Access to users when requirements are ambiguous
- Decision authority on trade-offs they create

### Handling Unrealistic Requests
```
WRONG: "That's not possible"
RIGHT: "I can build [what they asked] in 3 weeks, or 
        I can build [simpler version that achieves the same goal] 
        in 3 days. Which would you prefer given the timeline?"
```

Always offer an alternative, not just a no.

---

## Working with Designers

### Collaboration Principles
- Review designs before implementation starts — not after
- Flag technical constraints early: "This animation would cost 3x more than a simpler one"
- Suggest technically feasible alternatives that preserve design intent
- Implement exactly what's designed, or discuss changes before deviating

### Common Friction Points
| Design asks for | Technical reality | How to bridge |
|---|---|---|
| Pixel-perfect animation | Expensive on low-end devices | Discuss progressive enhancement |
| Complex custom component | Library component exists | Show the library option, let them decide |
| Real-time updates everywhere | WebSocket complexity | Agree on which features justify real-time |

---

## Translating Technical Decisions to Business Language

| Instead of | Say |
|---|---|
| "We need to refactor the auth module" | "Our login system has reliability issues that affect 5% of users. Fixing it takes 1 week now or 1 month when it fails in production." |
| "We have technical debt" | "We've accumulated shortcuts that are slowing us down. We're shipping 30% slower than 6 months ago because of them." |
| "We need to upgrade our database" | "Our current database won't handle the load at 2x our current user base. Upgrading now costs X. Waiting until it fails costs 5x." |

---

## Disagreeing Professionally

When you disagree with a non-technical decision:
```
1. Understand first — "Help me understand the reasoning behind this"
2. State your concern clearly — "My concern is [specific risk/impact]"
3. Propose an alternative — "What if we tried [approach] instead?"
4. Accept the decision — if they proceed anyway, commit fully
5. Document your concern — brief note in the ticket/PR
```

Disagreeing → discussing → deciding → committing is healthy.
Disagreeing → grumbling → passive resistance is not.