By Priya Sharma · Updated May 25, 2026

The cross-functional teams handbook

Horizontale.ai collects practical patterns for running cross-functional work — the projects, programs, and initiatives that span engineering, product, design, marketing, sales, finance, and ops. The material is opinionated and based on what actually works at companies between 50 and 5,000 people.

What “cross-functional” really means

A cross-functional team is one whose members come from different functional reporting lines but who work toward a shared outcome. The classic example is a product squad: a PM, two engineers, a designer, sometimes a researcher or data scientist. Each member has a functional manager (head of engineering, head of design) but the day-to-day work coordination happens within the cross-functional team.

The model exists because most meaningful business outcomes — launching a product, opening a new market, integrating an acquisition — require coordinated effort across functions that single-discipline teams cannot deliver alone. The challenge is that the structure creates two reporting lines (matrix), which is well-known to be hard to operate.

The recurring problems

Most cross-functional teams struggle with the same handful of issues:

• Unclear decision authority — who actually approves what? Functional managers? The PM as proxy? The senior-most person in the room? In matrix organizations this is rarely written down, so it gets relitigated every meeting.
• Conflicting priorities — the engineer’s functional manager has a roadmap, the team’s PM has a different roadmap, and the engineer is being asked to commit to both. Sequencing becomes politicking.
• Meeting overhead — coordinating five functions takes more meetings than coordinating one function. Without explicit constraints, calendar load grows until the team spends more time syncing than building.
• Accountability gaps — when an outcome misses, was it the engineer’s fault for missing the deadline, the designer’s fault for late mocks, the PM’s fault for changing scope, or marketing’s fault for an unrealistic launch date? In practice, no one’s fault often becomes everyone’s fault, and the team learns nothing.

What this handbook covers

The pages on this site walk through the patterns that consistently work for the problems above. Specifically: writing a RACI matrix that the team actually uses, running cross-functional meetings without expanding them to 45 minutes by default, structuring weekly status updates that surface decisions instead of just listing activities, and managing the matrix tension between functional managers and team leads without it becoming a daily friction.

None of the material is novel — most of it is conventional management wisdom that gets ignored because the people who need it are too busy to read it. The goal here is to make it cheap to find and use.

Who this is for

Engineering managers who lead cross-functional work, product managers running squads, program managers, chiefs of staff, and operators who keep getting put in charge of “the big cross-functional initiative” without explicit authority to do so. If you have ever been in a meeting and thought “we are not actually deciding anything,” this site is for you.