Cross-Functional Brokering: When Ops Becomes the Connective Tissue

It's 4:47 PM on a Thursday. The Slack DM lands from your VP of Sales: "hey can you jump on a quick call, Sales and CS are fighting about the upgrade quota credit again."

You're not on the Sales team. You're not on the CS team. You don't own the comp plan and you don't own the renewal motion. You're going to be on that call for 90 minutes, and at minute 87 someone is going to say "okay, can Ops just figure out a fix and send it around?"

Welcome to the job nobody hired you for.

The Operations Manager job description talks about process design, vendor management, KPIs, dashboards. What it does not say — but everyone on the leadership team quietly expects — is that you are the connective tissue between every function that won't talk to each other directly. Sales and CS. Finance and Sales. IT and Marketing. Product and CS. You will get pulled into every cross-team fight that has no clear owner, and your performance review will silently include "did the company stop bleeding from these wounds."

This playbook is about how to do that role without becoming the permanent dumping ground for everyone else's unowned work.

The Broker Mindset

Here's the mental shift that took me three years to actually internalize: you are not the decider. You are the translator.

Sales speaks in pipeline coverage and quota attainment. CS speaks in NRR, GRR, and at-risk accounts. Finance speaks in GAAP, deferred revenue, and audit trails. IT speaks in tickets, change windows, and "did anyone test this in staging." Product speaks in roadmap weight and engineering capacity.

Five tribes, five vocabularies, five sets of incentives. Most cross-functional fights are not actually disagreements about facts. They're two functions talking past each other because nobody is converting one dialect into another.

That conversion is your job. And the second you pick a side, you lose the job.

If you side with Sales on the quota credit fight, CS will stop trusting your working groups. If you side with Finance on a revenue recognition issue, Sales will route around you. The broker's leverage comes from neutrality. You have to be the person every function trusts to represent their position fairly to the others, even when you privately think one side is being ridiculous.

There's a tactical version of this: absorb the process, never the decision. You will run the meeting. You will build the doc. You will write the recap. You will not own the outcome. The outcome belongs to the two VPs who actually have P&L on the line. Your job is to make sure they have a clean enough path to a decision that they can't avoid making one.

The "Who Owns This?" Mapping

Before you can broker anything, you need a brutally specific answer to one question: who owns each recurring workflow that crosses team lines?

Build a RACI per workflow. One page. Five columns. No ambiguity. If two teams both think they're Accountable for the same workflow, you've just found the actual problem, and you've found it before the next 4:47 PM Slack DM.

Here's a real example for the lead-to-opp handoff:

One Accountable per row. Always. If you have two names in the Accountable column, you have a fight waiting to happen. Surface it before the fire, not during.

Build one of these for every recurring cross-team workflow:

• Lead handoff (Marketing → SDR → AE)
• Renewal forecasting (CS → Finance → Sales)
• Churn save (CS → Sales → Product)
• Billing dispute (Finance → CS → Sales)
• System change request (IT → affected functions)
• New hire onboarding (HR → IT → manager → Ops)
• Customer onboarding handoff (Sales → CS, see below, this is the classic)

A typical mid-size company has 8 to 12 of these. You can knock out the whole set in a quarter if you make it your side project. Nobody else will do it, and the day you have all 12 mapped is the day your job changes.

Running a Cross-Functional Working Group

When something cross-team is actively broken, you'll get pulled into a meeting. That meeting will, by default, be:

• 60 minutes, recurring weekly
• 8 to 12 people, including 4 you've never met
• Status updates from each function
• No decision
• A follow-up meeting scheduled for next Thursday

This is the format that ensures nothing gets fixed. Refuse it.

Here's the format that actually works:

60 minutes max. If you can't get to a decision in 60 minutes with the right people in the room, you don't have a working group, you have a status meeting. Status belongs in async docs, not on calendars.

Three people max. One person per affected function. Anyone who needs to be Consulted gets the doc beforehand and the recap after. Anyone who needs to be Informed gets the recap. They do not get the meeting.

Decision-or-cancel rule. If no decision is reached by minute 55, the meeting is canceled and the issue escalates to VPs. Not "let's reconvene." Not "let me check with my team." Canceled. Escalated. The threat of escalation is what forces the decision.

No recurring slot until the decision is made. Working groups exist to resolve a specific issue, then disband. The minute they go on the calendar weekly, they become a status update theater.

A working group agenda that fits on a sticky note:

Working Group: Quota Credit on Mid-Cycle Upgrades
Date: 2026-05-02
Attendees: VP Sales, VP CS, RevOps (broker)

1. (10 min) State the problem in one sentence. Confirm we agree.
2. (15 min) Each function presents their position. 5 min each. No interruptions.
3. (20 min) Three options on the table. Pros, cons, who pays what.
4. (10 min) Pick one. Or escalate.
5. (5 min) Recap, owner, deadline. Done.

Decision-or-cancel rule applies. Minute 55, we either have a call or this goes to the CRO and CCO tomorrow.

That format saves about 4 hours of meeting time per cross-functional issue versus the default. Across a year, with 8 to 12 of these issues, you'll save your leadership team 32 to 48 hours of meetings, and you'll cut decision cycle time from 3 weeks to roughly 4 days.

Escalation Triage

Not every fire is your fire. The fastest way to lose this job is to absorb every cross-team failure that lands in your DMs. The second fastest way is to push everything back and become known as the Ops person who won't help.

The triage rule: absorb the process, never the decision.

When the Slack DM hits, ask yourself two questions:

1. Is there a single function that is clearly Accountable for this decision?
2. Do they have the information they need to make it?

If yes to both, push back. Politely, with a specific reason, and with a path forward.

"This is a Sales-CS decision on the comp plan. I don't own quota policy. Can you and Mike (VP CS) take 15 minutes tomorrow? I'll send a doc with the three scenarios so you walk in ready to decide."

You're not refusing to help. You're refusing to own the decision. You're offering to do the prep work, which is the broker's actual value-add.

If no to question 1 (if it's genuinely unowned, or if two functions both claim ownership), that's when you absorb. But absorb the process only.

"Fine, I'll run the working group. We'll do it Thursday at 2 PM, 60 minutes, you and Sarah, decision-or-cancel. I'll send the prep doc Tuesday. The decision sits with you two. I'm just driving the agenda."

The pattern: you make it easy for them to decide. You do not decide on their behalf. The day you start deciding on behalf of VPs is the day you become the convenient scapegoat for every bad cross-team outcome.

The "Nobody Owns Customer Onboarding Handoff" Classic

This is the most common cross-functional black hole I've ever seen, and I'd bet $100 it's broken at your company right now.

The shape of the problem:

• AE closes the deal Friday at 5:30 PM. High fives.
• The customer expects a kickoff call "next week."
• CS picks up the account... when, exactly? When the AE updates the CRM stage? When Finance issues the first invoice? When the customer emails support asking when their kickoff is?
• The 72 hours between "deal closed" and "CSM owns it" belongs to nobody.

In that 72 hours, the customer's enthusiasm peaks and starts decaying. They were excited Friday at 5:30 PM. By Wednesday, they've moved on to other priorities. The kickoff call lands in a colder room than it had to.

Companies that fix this handoff see an 8-15% lift in 90-day retention and a measurable bump in time-to-first-value. That's not a marketing stat I'm pulling out of the air. It's the range I've personally watched play out across four mid-size SaaS companies that mapped this workflow and assigned single-threaded ownership.

Here's how to fix it:

Step 1: Map the handoff in 90-minute increments. Hour 0 (deal signs) through hour 168 (one week post-close). For each window, who is Accountable? What artifact has to exist? What does the customer experience? Most companies discover that hours 12 through 60 are completely unowned.

Step 2: Assign single-threaded ownership. One name. Usually a Customer Onboarding Manager if you have one, otherwise a designated CSM. They are Accountable from the moment the AE marks the opp Closed-Won until the kickoff call happens.

Step 3: Instrument the SLA. Kickoff call scheduled within 48 hours of close. First customer-facing email within 4 hours. CRM and onboarding tool sync within 1 hour. Build a dashboard. Review it weekly with Sales and CS leadership. The dashboard, not the meeting, is what makes the SLA real.

Step 4: Run the working group to lock the design. 60 minutes, 3 people (VP Sales, VP CS, you), decision-or-cancel. Walk in with the map and three ownership options. Walk out with one.

This is the highest-leverage cross-functional fix in most B2B SaaS companies. If you do nothing else from this playbook, do this one.

The Post-Mortem Playbook

Cross-team failures are going to happen. A botched product launch. A missed renewal that everyone assumed someone else was watching. A Salesforce update that broke lead routing for six days. The question is not whether they happen. It's whether you learn anything from them.

Run a blameless post-mortem within 5 business days. Not 30. Not "next quarter." Five business days, while the memory is fresh and the people involved still care.

Three questions, in this order:

1. What was the decision path? Who decided what, when, and based on what information? Reconstruct the timeline. Be specific.
2. Where did it break? Was it a missing decision, a wrong decision, or a correct decision that was poorly executed? Different breaks need different fixes.
3. Who owns the fix? One name, one deadline, one specific artifact (updated RACI, new SLA, system change, training).

A skeleton template:

Post-Mortem: {Incident Name}
Date of incident: 2026-04-12
Date of post-mortem: 2026-04-17
Owner (broker): Camellia (Ops)
Attendees: {3-5 people directly involved}

Timeline (be specific, use timestamps where possible):
- 04-12 09:14: ...
- 04-12 11:30: ...
- 04-12 14:02: ...

What was the decision path?
{2-3 paragraphs reconstructing who decided what.}

Where did it break?
- Missing decision? Yes/No. Detail.
- Wrong decision? Yes/No. Detail.
- Execution failure? Yes/No. Detail.

What we're changing:
1. {Specific fix} — Owner: {name} — Deadline: {date}
2. {Specific fix} — Owner: {name} — Deadline: {date}

What we're NOT changing (and why):
{Things people will ask about that we deliberately left alone.}

Blameless rule: this doc names decisions, not people. Names appear in the timeline for clarity, not in the "what broke" section.

The doc lives in a shared folder. Not in someone's DMs. Not in a Slack thread. A folder, with a consistent file naming convention, that anyone on the leadership team can find six months later when the same issue is about to happen again.

The blameless framing matters. The minute a post-mortem becomes a witch hunt, people stop being honest, and you stop learning anything. The point is not to figure out who screwed up. The point is to figure out what about your process let a screw-up cause this much damage.

Brokering Is a Real Job

Here's the thing nobody told me when I started doing this work: brokering is a real job. It's not overhead. It's not "the soft stuff." It's the highest-leverage role in mid-size companies, and it's almost always uncredited because the work is invisible when it's done well.

Done well, brokering looks like nothing. Meetings are short. Decisions get made. Cross-team fights don't recur. Onboarding handoffs are smooth. The renewal forecast doesn't have any "wait, who owns this account?" moments. Everyone assumes the company just runs that way.

Done badly, brokering looks like 4:47 PM Thursday Slack DMs every week, three-month decision cycles, and a leadership team that quietly resents each other.

The Ops IC who masters this becomes the person every VP trusts. You'll get pulled into the strategy room, not because you have a title that says you belong there, but because you're the only person who can see the whole system and explain it in five different dialects. That's the path from Operations Manager to Director of Operations. It runs straight through the brokering role, and most people miss it because they think it's not their job.

It is your job. Now you have a playbook for it.

Learn More

• The Operations Manager Job Description
• RACI Templates for Revenue Operations
• Running Decision Meetings That Actually Decide
• Lead-to-Opp Handoff SLA Design
• Path From Ops Manager to Director of Operations