home / skills / refoundai / lenny-skills / cross-functional-collaboration

cross-functional-collaboration skill

/skills/cross-functional-collaboration

This skill helps you navigate cross-functional collaboration by diagnosing friction, clarifying expectations, designing team structures, and strengthening

npx playbooks add skill refoundai/lenny-skills --skill cross-functional-collaboration

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
4.4 KB
---
name: cross-functional-collaboration
description: Help users work effectively across functions. Use when someone is navigating PM-engineering relationships, resolving cross-team conflicts, building product trios, or improving handoffs between design, engineering, and product.
---

# Cross-functional Collaboration

Help the user work effectively across functions using frameworks from 57 product leaders who have built high-performing cross-functional teams at companies from Linear to Airbnb.

## How to Help

When the user asks for help with cross-functional collaboration:

1. **Diagnose the friction** - Identify whether the issue is role clarity, communication patterns, or structural
2. **Clarify expectations** - Help define what each function expects from the others
3. **Design the right structure** - Recommend team composition and meeting rhythms
4. **Build relationships** - Emphasize the human elements that make collaboration work

## Core Principles

### Share credit generously
Camille Fournier: "Engineers sometimes think that they don't get the credit for their work because the PM takes all the glory. So making every effort to be credit sharing and inclusive of the engineering team." Let engineers present their own work to executives and customers.

### Use 'Yes, and' thinking
Adam Grenier: "If you approach it with that 'Yes, and,' it's often still true. Both of these things can be true at once. You could have a different goal than I have." Validate different team goals simultaneously rather than creating false dichotomies.

### Write expectations for each other
Nikita Miller: "Have PM, Design, Engineering, and Data leaders write down expectations for their counterparts. Create a 'contract' between roles to clarify shared responsibilities." Revisit these definitions every 3-6 months.

### Include engineers in discovery
Christine Itwaru: "Early on, we started bringing in engineers to customer meetings more and more. When we started doing it, the response from the engineering team was great." Direct customer exposure builds technical empathy.

### Don't play telephone
Camille Fournier: "If you put yourself in this in-between position and you're playing telephone between stakeholders and engineers, that is very annoying and it's a waste of time for everyone." Connect stakeholders directly to engineers when technical depth is needed.

### Work directly with engineers daily
Marty Cagan: "If you're not working every day with a set of engineers on solving problems, you are not a product manager." Remove intermediaries like 'product owners' who act as mediators.

### Build real relationships
Ebi Atawodi: "Do you know your engineering manager's birthday? Do you know their work anniversary? Do you know why they're doing the job they're doing?" Strong partnerships are built on personal human connection.

### Code is the common language
Amjad Masad: "The common language that everyone shares is code. What if the language becomes actually working prototypes and working applications?" Use functional prototypes rather than static mocks to reduce handoff friction.

### Embrace the 'product trio'
Teresa Torres: "The trio is the product manager, the designer, and the software engineer. If you've never worked in a well-functioning trio, this breaks people's brains." Resolve disagreements by seeking more data or better options, not by pulling rank.

## Questions to Help Users

- "What does each function expect from the others - have you written it down?"
- "Are engineers involved in customer discovery or just receiving specs?"
- "When there's a conflict, who is the tiebreaker and how quickly do they act?"
- "Do you know the personal career goals of your engineering and design partners?"
- "Are you acting as a translator or connecting stakeholders directly to engineers?"

## Common Mistakes to Flag

- **Credit hoarding** - PMs taking glory for work engineers built
- **Playing telephone** - Acting as an unnecessary intermediary between stakeholders and engineers
- **Excluding engineers from ideation** - Treating them as resources rather than creative partners
- **Unclear role boundaries** - Not defining who owns what leads to everything falling on the PM
- **Ignoring the human element** - Strong collaboration requires knowing your partners as people

## Deep Dive

For all 72 insights from 57 guests, see `references/guest-insights.md`

## Related Skills

- Running Effective 1:1s
- Having Difficult Conversations
- Delegating Work
- Managing Up

Overview

This skill helps product leaders and team members work effectively across functions to reduce friction, speed delivery, and build durable partnerships. It teaches diagnosis of collaboration problems, sets expectations between product/design/engineering, and prescribes structures like product trios and discovery practices. The guidance emphasizes relationship-building, shared credit, and practical handoff improvements.

How this skill works

I diagnose the source of cross-functional friction—role ambiguity, communication breakdowns, or structural issues—and recommend targeted interventions. I help teams write and align expectations, design team composition and meeting rhythms, and introduce practices such as including engineers in discovery and using working prototypes. I also surface common mistakes and human-centered steps to rebuild trust and momentum.

When to use it

  • Navigating PM–engineering or PM–design tensions
  • Resolving cross-team conflicts or stalled decisions
  • Setting up or improving product trios (PM, Designer, Engineer)
  • Designing handoffs between design, engineering, and product
  • Improving discovery practices and technical empathy

Best practices

  • Diagnose friction first: identify whether the problem is people, process, or structure
  • Write down expectations between functions and revisit every 3–6 months
  • Include engineers early in customer discovery and prototype with working code when possible
  • Share credit publicly—let engineers present to execs and customers
  • Avoid acting as a single intermediary; connect stakeholders directly to engineers when technical depth is needed

Example use cases

  • A PM asking how to stop being the middle person and create direct stakeholder–engineer connections
  • A team forming a product trio and needing norms for decision-making and responsibilities
  • An engineering manager seeing low morale from lack of credit and wanting a public recognition approach
  • A cross-functional group seeking meeting rhythms and handoff rules to reduce rework
  • A lead wanting to document role contracts to prevent scope creep and unclear ownership

FAQ

How do I decide who breaks ties in cross-functional disputes?

Define a fast tiebreaker in advance based on outcomes (e.g., product success vs. technical constraints). Name a clear decision owner for each domain and set SLAs for escalation.

What if engineers resist attending customer meetings?

Start small: invite one engineer to a single customer call, debrief together, and surface concrete technical insights. Highlight wins and scale participation gradually.