Nobody owns the seam
Cross team projects fail in the gaps between teams, where no one's name is on the work. What I do at the start of every collaboration to make sure the seam has an owner, and how I keep product, design, and sales from being surprised.
The project had two engineering teams, a product manager, a designer, and a launch date. Each team built its half on time. Each half worked. The integration between them, which was not on either team's board because it was not either team's feature, took five weeks and pushed the launch into the next quarter.
Nobody had done anything wrong. Nobody had owned the seam.
Name the seam owner on day one
Every collaboration I run now starts with a written list of the seams: the places where one team's work meets another's. The API contract between two services. The handoff from design to build. The moment sales gets the demo. Each one has a person's name next to it, and that person is accountable for the seam working, not for the pieces on either side.
That role is often thankless. The seam owner does not get to build much. They spend their time finding the mismatch between what one team assumed and what the other built. It is the most valuable job on a cross team project and I say so, publicly, at the kickoff.
One document, one status
Cross team projects generate parallel realities. Each team has its own board, its own standup, its own sense of where things are. The product manager has a third view. Sales has a fourth, based on a conversation from a month ago.
I collapse those into one page. The goal, the seams and their owners, the dates that matter, and a single status line per workstream that is updated weekly by the people doing the work. Every stakeholder reads the same page. When someone in a meeting says something that conflicts with the page, the page wins or the page gets fixed, in that meeting.
Working with product
The best product managers I have worked with wanted to know what was possible, what it would cost, and what the engineering team believed about the problem. The worst wanted a date and a yes.
I give product three things. Early involvement in scoping, before the requirements are written, because the cheapest time to change a plan is before it exists. Honest estimates with the range attached, and the reason for the range. And engineering opinions about the product, offered as opinions, because the team that builds the thing usually knows something about the customer the roadmap missed.
What I ask for in return is stable priorities within a sprint, and a conversation, not an announcement, when they need to change.
Working with design
Engineers and designers fight about the same thing every time: the moment when the design is "done." Engineers want it frozen so they can build. Designers want it open so it can improve.
My fix is to name the freeze date and to put an engineer in the design reviews before it. When the person who will build the thing has been in the room for the design choices, the handoff stops being a handoff. And when design wants to change something after the freeze, they know exactly what it costs, because they have watched the build.
Working with sales and the business
Sales does not need to understand the architecture. They need to know what they can promise and when, and they need to hear about changes before their customer does. So the seam between engineering and sales gets its own owner, usually me, and its own rule: any date that sales has told a customer is a date I know about, and any change to it reaches sales the same day I learn it.
The projects that went best with sales were the ones where a salesperson sat in the demo of the pilot and saw the thing work before they sold it. That took an hour and it saved a quarter of expectation management.
The AI rollout across functions
Taking the AI first operating model beyond engineering was a cross functional project by definition, and the seams were everywhere. Product wanted to use the tools for specs and had no review process for the output. QA wanted generated tests and had no rule for what counted as coverage. Sales wanted the quote generator and had never seen a pull request.
Each of those seams got an owner from engineering, paired with someone from the other function, and each pair wrote the one page that said what good looked like for that function. The seam owners were the reason the rollout worked outside engineering, and every one of them had been the person nobody wanted to be on the first project I described at the top of this piece.