Cross-Functional Leadership and Collaboration Questions

Direct answer

I would propose a written service commitment (an internal agreement, often an SLA/SLO pair). The service-level agreement (SLA) is the promise made to consumers. The service-level objective (SLO) is the tighter target the platform steers by internally, so it reacts before the promise is at risk. For example: promise 99.9% availability, internal target 99.95% with measured definitions, a graduated response when it is missed that trades platform feature work for reliability work, and obligations on the consumers too. The aim is that a miss triggers a pre-agreed process, not an argument.

What is promised

• A small number of measurable targets: for example availability of the main API, latency at a stated percentile (the 95th percentile, or p95, is the time that 95 out of every 100 requests beat), and time to respond to and resolve support requests, each with a precise definition and one agreed data source. Written out, one line of the commitment looks like this (illustrative): "Orders API availability: at least 99.9% of minutes in each 30-day window count as up, where a minute is up if at least 99% of requests in it return a non-error response; measured by the shared dashboard from gateway logs. Latency: p95 under 300 ms over the same window."
• Change notice: breaking changes announced with a minimum lead time.
• Consumer obligations: rate limits respected (caps on how many requests a consumer may send per second), retries with backoff (a failed call is retried after growing waits such as 1, 2, 4 seconds, not instantly and repeatedly), capacity forecasts shared. Guarantees that depend on well-behaved clients must say so.

What happens on a miss

An error budget is the allowed amount of unreliability implied by the target. For 99.9% availability over 30 days: 30 x 24 x 60 = 43,200 minutes, times 0.1% = 43.2 minutes. In consumer terms, that is the most time per month that, say, checkout calls to the platform may fail before the promise is broken. The tighter internal target of 99.95% leaves half of that, 21.6 minutes, which is why the first alert below fires at 21.6 minutes.

1. At about half the budget burned (21.6 minutes, the point where the internal 99.95% target is missed), the platform lead posts a status note, consumers are told, and the platform moves the open reliability fixes to the top of its next sprint. This is the early reaction the tighter internal target exists to buy; the full feature pause in step 2 is the stronger response once the promise itself is at risk.
2. When the budget is fully burned, the platform pauses planned feature work and spends capacity on the causes until the service is back inside budget, and the platform lead presents a remediation plan to consumers within an agreed number of days.
3. Repeated breaches over two consecutive periods go to the common director, with a request for capacity or a change in scope.

Worked example (illustrative)

Two incidents in a 30-day window last 30 and 25 minutes, so 55 minutes against a 43.2-minute budget: 55 / 43.2 is about 127% consumed. The rule triggers feature pause and a plan. Importantly, if a consumer's own retry storm (a flood of retries from many clients that overloads a service already in trouble) caused one incident, the review records that, and that incident is classified by the agreement's rules, which both sides signed.

Avoiding blame

• One shared dashboard that both sides agreed on beforehand.
• Blameless reviews with a standard template (what happened, what contributed, what changes), published to everyone.
• A monthly joint review where consumers can raise needs before they become complaints.
• Credit the platform for meeting targets, too, so the relationship is not only about misses.

Trade-offs and pitfalls

• Promising 99.99% to calm people down when the platform cannot deliver it makes things worse; commit only to what is funded.
• If the platform is understaffed, the agreement must also state what it will not do; otherwise the commitment is unfunded.
• A penalty paid to consumers (service credits, meaning money or usage handed back after a miss) rarely helps internally; the real remedy is protected reliability work.

Direct answer

First with the customer: acknowledge the problem in plain words within one business day, name one technical owner and one commercial contact, and commit to an update schedule I can keep. Internally: I would not try to win by escalating louder. I would turn the customer's pain into evidence engineering can rank (tickets, affected accounts, revenue at risk), agree a single plan with sales, support and engineering that separates a short-term mitigation from a root-cause fix, and then install an escalation path so a recurring issue is routed automatically next time.

Structured elaboration

1. Customer first (days 0 to 2). A call, not an email, from me with the account owner: restate the problem back in their words, say what we do not yet know, and give the next-update date. Agree one named technical owner they can reach. Do not promise a fix date yet. Sample wording: "You told us the order sync keeps failing and we have not fixed it. That is on us. Here is what we know: it has failed 14 times in 90 days, about once a week. Here is what we do not yet know: the root cause. Priya, an engineer, owns the diagnosis and you can reach her directly. I will call you again on Thursday with the diagnosis result and a workaround if we have one, and I will give a repair date only once we have diagnosed it."

2. One shared picture (days 1 to 3). A single page all three functions edit: timeline of the incidents, the customer's business impact, what has been tried, who owns each next step. Sales owns the relationship, support owns incident handling and communication, engineering owns the diagnosis. I own keeping the page current and the cadence.

3. Two timelines. Mitigation (a workaround or manual fix the customer can use this week) and root cause (the proper repair, with an estimate once engineering has diagnosed). Giving them separate dates keeps the customer from waiting on the hard one.

4. Get engineering to re-rank. The item was deprioritized because its cost looked higher than its benefit. Bring new evidence: number of tickets, other customers with the same symptom, revenue at risk, renewal date. Ask the engineering manager to re-rank it against what it displaces, rather than asking them to add it on top.

5. Prevent a repeat. Propose an escalation rule such as: the same defect class reported three or more times in 30 days, or a top-tier account hit twice in 60 days, goes automatically to the engineering manager and product owner for a ranking decision within a week.

Worked example (illustrative numbers)

The customer has reported the integration failure 14 times over 90 days, about 1.1 tickets a week (14 divided by roughly 12.9 weeks). Their annual contract is $480k and renews in four months. I show engineering a table: 14 tickets, 3 other accounts with the same error signature (the identifying error code and message that two failures share, which points to the same cause), $480k renewal at risk. Engineering spends one day on diagnosis and finds the cause is a retry bug in the order-sync job. Only then does Priya, the named engineer, estimate a mitigation (retry plus a cleanup script) at 3 days and the root-cause repair at about 3 weeks, which is the first point at which I give the customer dates, consistent with not promising a repair date before diagnosis. We choose: mitigation now, repair scheduled with a date before the renewal conversation, and I tell the customer both dates.

Trade-offs and pitfalls

• Promising a root-cause date before diagnosis is the fastest way to lose the customer for good.
• Escalating to executives can win this item and teach engineering to distrust the channel. Use evidence first, escalation if re-ranking is refused.
• Sales will want to give concessions (credits). That is a commercial decision for their leader, not something I commit to on their behalf.
• I would change my approach if the problem turns out to be a customer-side configuration: the work then moves to support and documentation.

Direct answer

The charter lists who attends and when, but says nothing about what the committee is for or who decides, so it will become a monthly status meeting where disagreements are noted and not settled. I would add a mandate (the written list of decisions this committee owns), decision rights, thresholds (rules for which matters come to the committee at all), a decision log and an exit review (a scheduled check on whether the committee should continue), and judge after two months by measuring decisions made, how fast, and how many were reopened.

What is wrong with it

1. No purpose or decision list. Without it, any topic is on the agenda.
2. No decision rights. Who decides a roadmap trade-off, the chair, a vote, the sponsor? Silence means whoever speaks last, or nobody.
3. No thresholds. What size of change comes to the committee versus being handled by a team?
4. A status template instead of a decision template. Status can be read offline.
5. No escalation path or deadlock rule, no record of decisions, no quorum rule, no review of whether the committee should continue.

What I would add

• Mandate: the decisions this committee owns (for example, ordering of platform roadmap bets and cross-team capacity trade-offs).
• Decision table: for each type of decision, one decider and who is consulted. A DACI shape fits: Driver (prepares the case), Approver (makes the call, exactly one per decision), Contributors (give input), Informed (told the outcome).
• Thresholds: for example, anything that moves a milestone by more than 2 weeks or needs another team's staff comes here; everything else stays with the team.
• Agenda: decision briefs sent 3 working days ahead; status read beforehand.
• Decision log with date, decision, owner, reasoning. One entry (illustrative): "D-007, 4 Feb: platform team keeps the migration in Q2, the reporting feature moves to Q3. Approver: chair. Reason: migration blocks two other teams. Reopen only on new information."
• Quorum and deadlock rule: a quorum is the minimum attendance at which the meeting may decide, for example (illustrative) the chair plus at least 4 of 6 members. Below that, decisions wait or go by written sign-off. If a decision is unresolved, the chair decides within 5 working days.
• Exit review: at month 6, check the log against the mandate. If most items are status or decisions teams could have made alone, shrink the committee or end it.
• Tiers of authority when the company works across several regions: keep three tiers distinct so effort is not duplicated, and write each tier's decisions into the charter. The steering committee sets priorities and funding; an architecture group (senior engineers who set shared technical standards) sets those standards; regional working groups deliver. Each tier has a written list of what it decides.

How I would know after two months

I would count, from the log:

• Share of agenda time spent on decisions versus status.
• Median days from "raised" to "decided".
• Decisions reopened later.
• Whether teams report fewer escalations outside the committee.

Illustrative data: 8 decisions raised, taking 5, 12, 3, 21, 8, 6, 14 and 9 days. Sorted (3, 5, 6, 8, 9, 12, 14, 21), the median is (8 + 9) / 2 = 8.5 days. One of 8 was reopened, which is 12.5%. As an example target (illustrative, set it with the sponsor at the start): median under 10 days and at most about 1 in 8 reopened, so this period would count as working. If the median grows over the next period and the same items return, the problem is decision rights, not attendance.

Trade-offs and pitfalls

• More process can slow small decisions; thresholds protect teams' autonomy.
• A chair who always decides alone gets speed but loses buy-in; reserve it for deadlock.
• Do not judge success by satisfaction alone; people can enjoy a meeting that decides nothing.

Direct answer

A RACI chart assigns each activity four possible roles: Responsible (does the work), Accountable (the one person answerable for the outcome, who can say yes or no), Consulted (gives input before the decision) and Informed (told afterwards). The rule I hold to is exactly one Accountable per row. Where two teams both expect to be accountable, I settle it by asking who bears the consequence and who can actually act, write the answer down at kickoff, and give the other team a Consulted role with a defined gate when the law or money requires it.

The RACI for the payment launch

Terms used in the chart: a ledger is the company's official record of money in and out; reconciliation is checking that two records agree (here, that what the payment provider says it processed matches the ledger); a chargeback is when a customer disputes a charge with their card issuer and the money is pulled back from the company; the card network (such as Visa or Mastercard) is the body whose rules govern those disputes; the sponsor is the senior leader who backs the project and breaks ties no one else can; a gate is a checklist item that must be ticked before a decision can proceed.

Cells marked A/R mean the same team is both Accountable and Responsible.

Every row has one A. Eight rows, five columns.

Resolving the contested rows

• Refund and chargeback policy. Product, Finance and Support each expected to own it. A worked trace of the dispute:
  • Product said: "refunds are a customer experience question, so we should own it." Support said: "we apply it every day, so we should own it." Finance said: "it is our money."
  • The test is two questions. Who bears the consequence if it is wrong? Finance: a too-generous policy loses money directly, and a flood of chargebacks can bring card-network penalties. Who can actually act on it? Finance can set refund limits and reserve funds for disputes; Product and Support cannot.
  • Result: Finance is Accountable; Product is Responsible for drafting it with customer experience in mind; Support is Consulted because they apply it every day.
• Launch go/no-go. Engineering expects to say "it works", Product expects to say "ship it". Product is Accountable because it owns the customer and commercial outcome; Engineering is Responsible for bringing the evidence (test results, monitoring, rollback plan), and Legal and Finance are Consulted with a checklist item each that must be ticked before the decision, so their concerns are a gate and not an afterthought.
• Method: a 30-minute kickoff walk through the chart; objections are heard once, one sponsor decides ties, and the chart is stored with the project plan.

The same method on two other handoff chains

Reporting handoffs (six activities). The conflicts here come from "the pipeline team assumed the dashboard team checked the numbers".

Pre-sales to delivery. The conflict is a salesperson promising what product and engineering have not agreed.

Trade-offs and pitfalls

• A row with two As is a row with none. A row with no R means nobody does it.
• Too many Cs slows the launch: consult only those whose input could change the decision.
• A chart nobody opens is decoration, so I would review it at each weekly check-in for the first month.

Direct answer

Without line authority (the power to assign work or judge performance), you lead through clarity, shared incentives and visible evidence. I rely on six levers: a goal people agree is worth their time, a shared measure of progress, a small proof of concept, informal sponsors, incentives and credit, and clear asks. When those are not enough, I escalate with options and a specific decision requested, instead of with a complaint.

The levers

1. A shared goal tied to what each person is already measured on. Everyone has their own priorities. If the effort helps a team hit its own goal (fewer incidents, faster onboarding, a customer renewal), it competes better for their time.
2. Shared metrics. One number everyone can see, such as "time from signup to first report" or "percentage of services migrated", replaces arguments about opinions.
3. A small proof of concept (a quick trial that shows the idea works before anyone commits). A one-week prototype or pilot with one willing team shows what the effort is and lowers fear. People say yes to something they can see.
4. Informal sponsors. Find the respected person on each team, someone with influence but no formal authority over the work, who understands the goal. They carry the message in rooms you are not in.
5. Incentives and credit. Name contributors publicly, give their manager the story for performance reviews, and take on the unglamorous work (notes, tracking, chasing) so their time goes to what only they can do.
6. Clear asks. "I need a 2-hour review by Thursday from someone who knows the billing code" gets answered. "Can you help with this initiative" does not.

Example

A product manager wants a data scientist's churn model (a model that predicts which customers are about to cancel) surfaced in the app, but the data scientist, an engineering team and customer success report separately. The PM runs a one-week pilot with 200 customers flagged as high risk (illustrative). Customer success contacts each flagged customer before their renewal date, and the shared measure is "share of flagged customers who cancel". Illustrative result: 60 of the 200 cancelled (30%), against 90 of 200 (45%) among comparable high-risk customers the previous month, when nobody was contacted. That is a rough before-and-after comparison, not a controlled test, so the PM says so and offers to hold back a random group next time. Most of the work was manual: customer success received the flagged list as a weekly export, so contacts came days late. The PM then asks the engineering lead's skip-level manager (the manager of the lead's manager) to name the work a priority, after telling the lead first:

"In the pilot, 30% of flagged customers cancelled against 45% the month before, with outreach as the only change we know of. A live feed instead of a weekly export would let customer success contact all 200 earlier in the week. Can you confirm this as a priority this quarter?"

The PM credits all three teams in the quarterly update. The pattern carries over to a purchasing change that needs legal, finance and engineering: the ask is small ("a 2-hour contract review by Thursday"), dated, and backed by a shared number such as "days to approve a new vendor".

When the levers are not enough

1. Check the cause. Is the person overloaded, disagreeing with the direction, or lacking a reason to care? Each needs a different fix.
2. Go to the person's manager with a clear trade-off: "To hit the date, either this team gives 2 engineers for 3 weeks or we cut feature X. Which do you prefer?"
3. Escalate to the sponsor with the evidence and options, after telling the person you are doing it. Surprise escalation damages trust for the next program.

Pitfalls

• Treating influence as persuasion alone. If the work is not in anyone's priorities, charm will not fix that.
• Escalating too early, which spends goodwill, or too late, which spends the schedule.
• Taking credit. Your standing for the next program depends on how this team felt afterwards.