Working with people
Cross-team asks
Other teams have roadmaps and review queues. Make saying yes the path of least resistance.
Other teams are not obstacles. They are systems with their own roadmaps, pages and review queues. Your job is to make cooperation the path of least resistance: understand their incentives, send a complete ask, and write the agreement where it will survive leave.
Concept
A cross-team ask is a request to people you do not manage. The pattern is the same as influence without authority: homework, small slice, draft, shared upside, dated reply.
The big idea
A growth team measured on experiments will resist a multi-week migration. A platform team measured on reliability will resist a risky launch near quarter end. If you do not name their constraint, your ticket reads as "please drop your scoreboard for ours."
The analogy is asking a neighbor to borrow a tool: you show up when they are home, you say when you will return it, and you do not ask them to rebuild their shed. The analogy breaks when three teams must sequence work — then you need a drawn dependency graph and a named integration owner, often you.
Walking through it
Understand their incentives. Name the constraint in the ask: "I know you're frozen for the launch — can we schedule the API change for the week after?"
Make asks easy. Include what you need, why, the smallest slice that unblocks you, links, and a proposed default if they do not reply by date D. Offer to write the first draft of their side (doc section, interface PR, test plan). People say yes to work that arrives half-done.
Prefer public channels and docs over private lobbying. Cross-team agreements that live only in DMs evaporate when someone goes on leave. A short RFC comment or ticket with both teams tagged becomes the record.
Mind the dependency graph. If three teams must sequence work, draw it. Ambiguous ownership ("we'll sync") is how launches slip. Name an integration owner.
Working with PMs and designers is the same skill with different vocabulary: share options early, translate engineering risk into product risk, and avoid surprising them in the sprint review.
If your team has no norms yet, propose two lightweight ones: decisions written down with owner and date, and design disagreements resolved with options-plus-recommendation rather than endless threads.
Common mistakes
- Surprise Friday tickets. No heads-up, no draft, a deadline that is your launch, not theirs.
- We'll sync. No owner, no sequence, no date. Draw the graph.
- DM-only agreements. The person goes on leave and the launch story disappears.
Check yourself
- What five pieces belong in a cross-team ask?
What you need, why, the smallest unblocking slice, links, and a default if they do not reply by date D.
- Three teams must ship in order. What do you produce besides tickets?
A drawn sequence and a named integration owner.
Key takeaways
- Name the other team's constraint in the ask.
- Send work half-done: draft, links, smallest slice, dated default.
- Write agreements in public; name an owner for the dependency graph.
Further learning
Next: glue work.
Related
Influence without authority
Shrink the ask, do their first draft, name shared upside, and escalate with options rather than a complaint.
Collaboration and disagreement
Build trust before you need it, disagree with data and options, and make cross-team asks easy to grant.
Working with product managers and designers
Product sense for engineers — shaping scope, trade-off conversations, feasibility spikes, and building the right thing with PMs and designers.