# How do you work with other engineering teams?

**Cross team collaboration** works when teams turn shared work into explicit agreements. Start with one outcome, identify the dependencies and handoffs, name an owner on each side, write the interface and acceptance evidence, and agree how risk will be raised. Good collaboration is not constant harmony or more meetings. It is the ability to make and revise commitments without surprise.

        
## Why does work between engineering teams become difficult?

        
Each team sees a different part of the system. A product team may need an identity change for a customer launch. The identity team sees security review, migration risk, and several other consumers. Both can be reasonable while making incompatible plans. Trouble begins when either side treats its local view as the complete picture.

        
Queueing makes the gap worse. A request can look like one ticket to the product team and require design, implementation, review, rollout, and support from the platform team. If the requester asks only for a delivery date, hidden work remains hidden. If the provider answers only that it is busy, the customer consequence remains hidden.

        
Strong collaboration gives both teams enough context to negotiate. The requester explains the outcome and the cost of delay. The provider explains constraints, alternatives, and confidence. Together they can reduce scope, change sequence, or escalate a priority choice. They do not need identical incentives, but they need a shared decision surface.

        
## What agreement should teams make first?

        
| Question | Useful answer | Weak answer |
| --- | --- | --- |
| What result matters? | Customers can use the new access flow | Finish ticket 418 |
| Who owns each side? | Named product and identity engineers | The teams |
| What is the interface? | Request, response, errors, and version | We will connect later |
| What proves acceptance? | Agreed cases pass in a test environment | Code is merged |
| How is risk raised? | Owner updates confidence and names a decision | Mention it in the next meeting |

        
The first agreement should be small enough to test. Before building the complete access flow, the teams might validate one request and one failure response through the real boundary. This exposes mismatched assumptions while change is cheap. A detailed plan does not replace contact with the interface.

        
## What are the five practices in this series?

        

          - [Manage team dependencies](https://isilta.com/blog/how-to-manage-dependencies-between-teams/) by naming owners, confidence, sequence, and escalation before dates become promises.

          - [Improve an engineering handoff](https://isilta.com/blog/how-to-hand-off-work-between-teams/) with acceptance evidence, operating context, and a receiving owner who can refuse incomplete work.

          - [Run a cross team meeting](https://isilta.com/blog/how-to-run-a-cross-team-sync-without-status/) around decisions, conflicts, and changes instead of reading status aloud.

          - [Say no to another team](https://isilta.com/blog/how-to-say-no-to-another-team/) by explaining the constraint, protecting the relationship, and offering a useful next choice.

          - [Build shared context between teams](https://isilta.com/blog/how-to-share-context-across-squads/) through concise decision records, examples, and direct access to the people who understand the system.

        

        
These practices reinforce one another. Dependency agreements create the input for useful handoffs. Shared context makes a no easier to understand. A focused sync resolves the decisions that written updates cannot. Managers should improve the weakest link around real work instead of launching a broad collaboration program.

        
## How should a manager respond when teams disagree?

        
Ask each side to state the shared outcome, its constraint, and the decision it needs. This moves the discussion away from motives. The product team may need a launch this quarter. The platform team may need to avoid a breaking schema change. A manager can then test options such as a temporary adapter, smaller scope, or a later launch.

        
Do not settle every dispute by seniority. That teaches teams to escalate before exploring. Let the owners compare evidence and consequences first. Step in when the choice crosses team authority, when incentives conflict, or when delay costs more than the discussion. Record the decision so the same argument does not restart.

        
## How do you make ownership visible?

        
Give each dependency or handoff one named owner on each side. The requesting owner explains the need, consequence, and latest useful date. The providing owner explains what can be promised and what could change. A channel, board, or document can support them, but a location is not an owner. When everyone is responsible, nobody knows who should act when the date moves.

        
Write the agreement where both teams work. Include the expected result, interface, acceptance evidence, decision owner, review date, and escalation path. Keep it short enough to read during planning. A large coordination document that nobody updates creates false confidence. A clear paragraph with current names and dates is usually more useful.

        
Ownership must include authority. A contact who cannot adjust scope, reserve review time, or bring a decision to a manager is only a messenger. Managers should identify which decisions the owners can make directly and which require leadership. That boundary prevents days of polite relay between people who cannot resolve the issue.

        
## What should managers ask in 1 on 1 conversations?

        
Ask where another team's work creates uncertainty, waiting, or repeated rework. Engineers may avoid raising these issues in a group because they do not want to blame peers. A 1 on 1 can reveal that an engineer is spending hours translating vague requests, chasing approvals, or repairing changes after an incomplete handoff.

        
Listen for relationship risk as well as process risk. A person may know exactly what needs to be said but fear sounding difficult to a senior engineer in another group. Help them prepare a factual message that names the shared outcome, current constraint, and requested decision. Join only when your authority is needed. Taking over every conversation prevents engineers from building working relationships.

        
Return to the concern after action. Ask whether the agreement became clearer and whether behavior changed. A manager who collects frustration but never closes the loop teaches people that raising cross team problems has no value. Even when the answer is no, explain the decision and help the engineer adapt the plan.

        
## How do you keep coordination from becoming more meetings?

        
Use written updates for facts that do not require discussion. A useful note states what changed, what remains blocked, what evidence exists, and which decision is needed from whom. Readers should be able to respond without attending a call. Save live time for conflict, ambiguity, tradeoffs, and choices that need several perspectives at once.

        
Every recurring meeting should have a distinct purpose, owner, and exit test. If participants mostly read ticket status aloud, replace the meeting with a shared view and an exception rule. If the meeting resolves interface decisions quickly, keep it and record those decisions. Attendance is not collaboration. Reduced waiting and clearer commitments are better evidence.

        
Protect focus by grouping questions. One complete request with examples, logs, and desired timing is kinder than five interruptions across a day. The receiving team can then assess the request against its own work. Urgent incidents need a faster path, but ordinary coordination should not borrow the language or disruption of an incident.

        
## How should teams learn from a missed commitment?

        
Start with the sequence, not blame. Ask what each team believed, when information changed, how that change was communicated, and which signal arrived too late. A dependency can fail even when both teams worked hard. The useful question is which part of the agreement or feedback loop allowed surprise.

        
Look for structural causes. The provider may have accepted work without capacity. The requester may have hidden an immovable launch date. The interface may have changed after implementation began. A manager may have rewarded local delivery while ignoring costs imposed on another group. Naming these conditions leads to better prevention than calling for more ownership in the abstract.

        
Choose one correction and observe it on the next real piece of work. Add an earlier interface review, a visible confidence level, a smaller first delivery, or a direct escalation path. Do not respond to one miss with a complex process for every collaboration. The correction should reduce the chance or cost of the same surprise.

        
## Which signals show that collaboration is improving?

        
Watch waiting time, late scope changes, reopened work, missed review dates, and the number of decisions that need manager rescue. Pair those signals with conversation. Ask engineers whether requests arrive with enough context, whether they can challenge dates safely, and whether another team tells them about risk early. Counts without experience can hide quiet frustration.

        
Do not rank teams by response speed. A platform group facing many requests will look slow even when it makes sound priority choices. Measure the path around a shared outcome. Did both sides agree before building? Could each side explain the other's constraint? Did the result integrate with less surprise? These questions encourage system improvement rather than local score keeping.

        
Healthy cross team collaboration does not remove disagreement. It makes disagreement earlier, more specific, and safer to resolve. Teams can say that a date is uncertain, an interface is unsafe, or a request is not the best use of capacity without damaging the relationship. Managers create that condition through clear goals, visible choices, and consistent follow through.

## What are frequently asked questions?

### What makes cross team collaboration work?

It works when teams share an outcome, name owners, document dependencies and interfaces, expose uncertainty early, and use direct escalation for unresolved tradeoffs.

### How often should engineering teams meet?

Meet only when a decision, conflict, or complex discussion needs live attention. Use written updates for routine facts and set an exit test for recurring meetings.

### Who owns a dependency between teams?

Each side needs an owner. One owns the request and its business context, while the other owns the response, delivery confidence, and technical constraints.

### How can managers improve trust between teams?

Managers can reward early risk sharing, make priority choices visible, prevent surprise commitments, and address repeated behavior without turning every miss into blame.

### What should teams document?

Document the shared result, interface, owners, acceptance evidence, important dates, current confidence, decisions, and escalation path.

Related: [managing team dependencies](https://isilta.com/blog/how-to-manage-dependencies-between-teams/), [engineering handoffs](https://isilta.com/blog/how-to-hand-off-work-between-teams/), [cross team meetings without status](https://isilta.com/blog/how-to-run-a-cross-team-sync-without-status/).