Leading Cross-Functional Projects Without Authority
Takeaway: Cross-functional projects rarely fail because people refuse to cooperate; they fail because no one owns the governance, so the operator's real job is to supply the structure, clarity, and accountability that a shared project otherwise lacks.
A chief of staff spends a large share of their time running work that crosses departments. A pricing change touches finance, sales, product, and legal. A reorg touches every function. A new reporting cadence touches all of them at once. In almost none of these cases does the operator have formal authority over the people doing the work. That's the defining condition of the role, and it's also the reason cross-functional projects are where operators earn or lose their reputation.
The good news is that the failure pattern is well documented, which means it's avoidable. Behnam Tabrizi studied 95 cross-functional teams across 25 leading corporations and found that nearly 75 percent were dysfunctional, failing on at least three of five measures: staying on budget, staying on schedule, meeting specifications, meeting customer expectations, and staying aligned with company goals (Harvard Business Review). The striking part is why. The teams didn't fail because the members disliked each other or wouldn't pitch in. They failed because of weak governance: unclear ownership, vague goals, no accountability, and a lack of organizational priority.
That finding should change how you approach the work. Your job isn't to be the most charismatic person in the room. It's to install the structure the project is missing.
The governance gap is the real problem
Tabrizi's data makes the point sharply. Teams with strong governance succeeded 76 percent of the time, while teams without it succeeded just 19 percent of the time (Harvard Business Review). Governance here doesn't mean bureaucracy. It means a small number of things being explicit that are usually left implicit: who decides, who does the work, what "done" looks like, and who is accountable when it slips.
When a cross-functional project drifts, it's tempting to read the problem as a people problem. The engineering lead isn't responsive. Marketing keeps changing the ask. Finance went quiet. Sometimes that's true. Far more often, each of those people is behaving rationally inside a project where the goal is fuzzy, their role was never defined, and nothing they're being asked to do is a stated priority for their own boss. Fix the structure and most of the "people problems" dissolve.
This is the operator's opening. You may not command any of these functions, but you can be the person who supplies the missing scaffolding, and nobody will fight you for that job.
Start with a real charter, not a kickoff meeting
The most common mistake is to launch a project with a meeting and a shared document and assume alignment follows. It doesn't . Before the first working session, get four things written down and agreed.
The objective, stated as an outcome. Not "improve onboarding" but "reduce time-to-first-value for new customers from 14 days to 7 by the end of Q3." A vague goal is the single most reliable predictor of a dysfunctional team in Tabrizi's data. If you can't state the objective as a measurable outcome with a date, you're not ready to start.
The sponsor. Tabrizi found that executive sponsorship is one of the strongest differentiators between projects that work and projects that stall. A senior leader who has publicly said this matters gives you something to point to when a function deprioritizes the work. Name the sponsor, confirm they will spend real attention on it, and use their standing rather than pretending you have your own.
Decision rights. Write down who decides what. The most useful move is to separate the people who are consulted from the person who actually makes the call. Ambiguity here is what produces the endless re-litigation that kills momentum. When a decision is made, the decision log should say who made it and why, so it stays made.
Roles. A lightweight responsibility map, even a simple one that marks who is responsible, who is accountable, who is consulted, and who is informed, prevents the two failure modes at once: work with no owner, and work with three owners who each assume someone else has it.
None of this requires authority. It requires the discipline to write things down and the standing to ask people to agree to them, which you build by being useful rather than by being in charge.
Convert the objective into owned commitments
A charter aligns intent. Delivery comes from commitments. The operator's job in the working phase is to translate the shared objective into specific pieces of work that specific people have agreed to own by specific dates, and then to keep that list honest.
The mechanism matters less than the consistency. A single visible tracker that everyone reads from, updated in public, does more for a cross-functional project than any amount of one-on-one chasing. When the status is legible to the whole group, social pressure does much of the accountability work that you can't do through formal authority. People don't want to be the row that's red while everyone else is green.
Two habits keep the tracker credible. First, every item has one name next to it, never a team name. "Marketing to review" isn't a commitment; "Priya to review by Thursday" is. Second, you update it whether the news is good or bad. A tracker that only shows progress is a marketing document. A tracker that shows slippage early is a management tool, and it's the thing that lets you raise a problem while there's still time to fix it.
Influence is how you get the commitments, not a substitute for structure
Structure tells you what needs to happen. Getting busy people who don't report to you to actually do it is where influence comes in, and it's worth being deliberate about. The exchange model from Allan Cohen and David Bradford is the practical frame: people cooperate when you understand what they value and offer something that helps them get it (Cohen and Bradford, Influence Without Authority). For a cross-functional lead, the currency you control is often exactly what a stalled contributor needs: air cover on a competing priority, a cleaner decision so they stop redoing work, visibility with the sponsor, or simply removing three other things from their plate so this one can move.
Match the case to the person. A finance lead usually wants the numbers and the risk stated plainly. An engineering lead usually wants a clear spec and to not have the scope move under them. A sales leader usually wants to know how this helps them hit the number. The same request, framed in the other person's terms, converts far more reliably than a generic ask framed around your principal's wishes. This is a large enough topic that it has its own playbook, but the short version is that you lead cross-functional work by making cooperation easy and worthwhile, not by leaning on proximity to the boss.
That last point deserves a warning. The fastest way to poison a cross-functional project is to invoke borrowed authority, to signal "the CEO wants this" to force compliance. It works once and costs you the relationship. The stronger position is to make the request stand on its own merits, and to reserve the sponsor for the small number of decisions that genuinely need escalation.
Drive to a close, then actually close it
Cross-functional projects have a tendency to trail off rather than end. The launch happens, attention moves on, and the last 15 percent never gets done. Part of the operator's job is to force a clean close: confirm the objective was met against the number in the charter, capture what was decided so it doesn't get re-opened, hand off any ongoing ownership to a named person, and tell the sponsor and the group it's finished. A visible ending does two things. It banks the credibility you earned, and it teaches the organization that projects you run get finished, which makes the next group of contributors easier to enlist.
FAQ
What is the single biggest predictor that a cross-functional project will fail? A vague objective combined with unclear ownership. Tabrizi's research found weak governance, not unwillingness to cooperate, is the core issue (HBR). Both are fixable before the work starts.
Do I really need a sponsor if I have the CEO's backing informally? Yes, and you should make it explicit. Informal backing evaporates the first time a function has to choose between your project and its own quarterly goals. A named sponsor who has publicly prioritized the work gives you something durable to point to.
How do I hold people accountable without authority? Make status legible to the whole group in one shared tracker, put a single name on every item, and update it honestly, including the misses. Public visibility does the accountability work that a reporting line otherwise would.
When should I escalate to the sponsor versus handle it laterally? Handle anything that's a matter of coordination, sequencing, or persuasion yourself. Escalate only genuine conflicts of priority between functions that can't be resolved at your level. Escalating too often spends the sponsor's attention and signals you can't run the work.
How do I lead cross-functional projects without owning the teams? Supply the governance the project is missing rather than leaning on influence. Before the first working session, write down and get agreement on a measurable objective, a named executive sponsor, explicit decision rights, and a lightweight roles map. Then run one shared, public tracker with a single name on every item, updated honestly including the misses. Weak governance, not unwillingness to cooperate, is what sinks most cross-functional work (Harvard Business Review).
If you want a running start, join The Brief, our free newsletter for exec-ops professionals, and get our cross-functional project charter and responsibility-map template, a one-page format for setting objective, sponsor, decision rights, and roles before the first working session.
