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.