Cross-Functional Leadership and Collaboration Questions

Direct answer

The strongest version of this story names the stall, the specific action I took to restart it, and a measure I set before starting so I could say whether it worked. Here is one told in that shape: a reliability initiative across six teams with no reporting line to me.

The story

Situation. As a site reliability engineer (an engineer who keeps services running reliably), I saw that on-call engineers (whoever is on the rotation to respond to problems, including overnight) were paged too often for alerts that needed no action. A page is an automatic alert that buzzes the on-call engineer's phone. Six teams owned the alerts, each had other priorities, and no one was assigned to fix it. I volunteered to drive it.

Actions.

• Agree what to measure first. From the paging export (the report our paging tool produces listing every page sent), I counted pages per team over a four-week baseline: 84 pages in total (about 21 a week). I classified a sample of 24 (4 per team) as "actionable" or "noise" with each team's on-call, so we shared a definition: actionable means the engineer paged had to do something to protect customers; noise means it cleared by itself or needed nothing. 15 of the 24 were noise (about 5 in 8, so roughly 52 of the 84; this is an estimate, because the sample took 4 pages from each team whatever its volume, so the 52 and the target of about 26 fewer are rounded figures, not exact counts).
• Set the goal with the teams. Each team picked its own noisy alerts to retire or retune, with a shared target: halve the non-actionable pages, roughly 26 fewer per four weeks.
• Progress stalled at week 3. Two of the six teams had done nothing. I asked them privately, in words like "I have not seen movement on your alerts and I would like to understand what is in the way. Is there anything I can take off your plate?" Their answers: one was under a release deadline, the other did not believe the counts. I fixed the second by showing their own raw pages, and negotiated a smaller scope with the first (their five noisiest alerts only).
• Used visible, neutral reporting. A weekly chart of pages per team, shared with all six leads and their manager, without ranking people.
• Escalated once: I took the remaining blocked item to the shared director with two options and a requested decision.

Result. Over the next four weeks the same measure showed 49 pages, a drop of about 42% (84 to 49, so 35 fewer). Fewer overnight pages were the main outcome teams cited when asked.

Worked example: measuring it

(84 - 49) / 84 = 0.417, so about 42% fewer. Because I used the same four-week window and the same counting rule, the comparison was fair. I also checked that actionable pages did not fall, which would have meant we were silencing real problems.

Pitfalls and reflection

• A drop in pages can also mean broken monitoring; count missed incidents too.
• What I would change: agree the owner of ongoing alert quality on day one, because gains faded for the team without one.
• Do not make the stall about lazy people; say what you learned about their constraints.

Direct answer

I would not mandate one platform. I would find out why each team built its own, agree a small shared contract that must be common, leave local choices local, adopt in stages starting with a willing team, give resisting teams concrete help or a time-limited exception, and put one named person accountable for the shared outcome.

Structured elaboration

1. Diagnose (about two weeks). Interview each team: what does their version do that others lack, what did it cost, and what do they fear losing? Build a table of capabilities side by side. Illustrative, for a shared notifications platform (email and push):

2. Draw the line between common and local. The shared contract is the short list of things every team must do the same way so other teams can rely on it. For the notifications platform it might contain: the call shape (send(user_id, template_id, channel)), authentication with the company sign-on token, a delivery-status event named the same everywhere (notification_sent, notification_failed), and the opt-out rule (an opted-out user is never sent marketing messages).

• Common: those interfaces, the security baseline, the monitoring baseline, data formats.
• Local: internal implementation, release cadence, tooling choices that no one else touches.

3. Decision rights. Use DACI (Driver, Approver, Contributors, Informed). Filled in for this platform:

4. Avoid duplicate effort. Keep one shared backlog of platform gaps. Rule: no new investment in a team's private copy of a capability the platform will cover, unless it is fed back.

5. Adopt gradually, in levels of a standard. Staging a standard resolves the trade between safety and speed: a strict rule slows fast teams, a lax one lets failures through, so each level adds only what the team can absorb. Take monitoring as the example. Level 1: emit baseline metrics (one quarter). Level 2: alerts on service-level objectives, the reliability targets for a service (second quarter). Level 3: the full standard where customer impact is high (third quarter, and only for those services). Fast teams get the floor first, not the whole rule at once.

6. Handle resistance by cause. Risk: give a rollback plan and a parallel run (old and new systems run side by side until their results match). Cost: give migration engineers or a funded window. Learning curve: pairing, docs, and a point person (one named contact who answers migration questions). Real gaps: take their requirements into the platform. If it still fails, grant a dated exception and escalate only for safety issues. Illustrative wording: "Team B keeps its own scheduler until 30 June, when its planned rewrite lands; on that date the exception ends and it migrates. Owner: Team B lead. Reviewed by the architecture lead on 1 June."

The same method applies to a shared machine learning infrastructure: show the team the pain it removes (queue times, duplicated feature pipelines), and pilot with one model.

7. Reconcile teams with different KPIs (key performance indicators) and release cadences. Put the shared goal in both teams' own goals with the same measure, state who gets credit, name one accountable owner, and use feature flags (switches in the code that turn a feature on or off without a new release). The faster team ships its code on its own schedule with the flag off, and turns it on once the slower team's side is ready.

Worked example

Illustrative: five teams. Quarter 1: pilot with 1 team. Quarter 2: add 2. Quarter 3: 1 more team migrates and the last team holds a signed exception until its planned rewrite. Check: 1 + 2 + 1 = 4 teams migrated, plus 1 with a dated exception, which accounts for all 5.

Trade-offs and pitfalls

• Mandates win compliance, not commitment; adoption by value lasts.
• Too much commonality kills autonomy; too little recreates duplication.
• Exceptions need an expiry, or they become the norm.

Direct answer

Two terms first. A model's score is the number it outputs for each case, here from 0 to 1, higher meaning more likely fraud. The threshold is the cutoff the decision owner picks: orders scoring at or above it get acted on (declined or sent to review). Lowering the threshold flags more orders, including more borderline ones.

I would split accountability into two named owners with a written contract between them. The team that builds the model owns whether the model behaves as promised. The team that makes the decision owns the rule that turns a model score into an action. Every bad outcome is then traced to one of those owners, or to a named gap, instead of being argued about.

Ownership model

• Model owner is accountable for model quality against the agreed measure, monitoring for drift (the world changing so the model's inputs or accuracy shift), retraining, and telling the decision owner about changes before they ship.
• Decision owner is accountable for the threshold, the action taken (decline, review, approve), human overrides, and the business outcome of the decision.
• Data providers upstream of the model are named in the contract too, so a broken input feed has an owner.

Interface agreement (a short written contract, reviewed quarterly)

1. What the score means (for example "estimated probability the order is fraud") and what it does not mean.
2. Expected performance on a named measure, measured on a weekly labeled sample, with a minimum the model owner commits to. The measure here is precision: of the orders the model flags, the share that are truly fraud. The promise is stated at a named cutoff ("of orders scoring 0.8 or higher, at least 90% are fraud"). A labeled sample means a set of cases whose true outcome has been checked by a person: each week a fraud analyst reviews 200 randomly chosen orders that scored at or above the contract cutoff (0.8), whatever threshold the decision owner currently acts on, using chargeback records and customer contact, and marks each one fraud or legitimate. Sampling at the contract cutoff, not at the decision owner's live threshold, keeps the measurement about the model alone. Chargebacks can take weeks to arrive, so the weekly sample is labeled by analyst review and customer contact, and is re-checked against chargebacks once they land.
3. Inputs, freshness, and availability expectations.
4. Change notice: a new model version runs in shadow mode (it scores real orders alongside the old model, but its scores are not acted on) for an agreed period and is announced before it takes effect.
5. Who may change the threshold, and that the model owner is told before it moves.

Dispute process

After any bad outcome, hold a blameless review (focus on how the system allowed the result, not on who to blame) within a week, using one four-way question: was it (a) the model out of contract, (b) the decision rule or threshold, (c) an upstream input, or (d) a case neither contract covered? For (d), the review must assign an owner and amend the contract before it closes. If the two teams still disagree on the classification, a named arbiter, such as the common director, rules within five working days.

Worked example (illustrative numbers)

A fraud score feeds an order-decline rule owned by the payments-operations team. The contract is set at a score of 0.8: at least 90% of orders scoring 0.8 or higher must be truly fraud. Customers complain about wrongly declined orders.

• Case A, the model missed its promise. The weekly sample is 200 orders scoring 0.8 or higher, and 142 were fraud. Precision is 142 / 200 = 71%, below the 90% promise. The model owner owns the fix (investigate drift, retrain, roll back).
• Case B, the decision rule moved. The weekly sample shows 186 of 200 are fraud, so precision at the 0.8 cutoff is 93% and the model met its contract. But the decision owner had lowered its threshold from 0.8 to 0.5 without notice, so it now also declines orders scoring between 0.5 and 0.8, which the model never promised were fraud. A sample of those declines might show only 40 fraud out of 100, so 60 legitimate customers are wrongly declined. The model's 93% is intact because it is measured at 0.8; the complaints come from the rule change. The decision owner owns the outcome, and the review amends the contract so threshold changes require notice.

Same complaint, two different owners, decided by evidence.

Trade-offs and pitfalls

• Do not give the model team the business outcome, or they will refuse to ship; do not give the decision team model internals, or they will refuse to trust it.
• A contract with no measured numbers is decoration; the weekly sample is what makes it enforceable.
• Leave a visible owner for gaps. Unowned gaps are where blame lives.
• I would revisit this if the decision is regulated or affects people's access to services, since a human sign-off role and audit trail would then be required.

Direct answer

A few terms first: go/no-go is the decision on whether to release to production; a runbook is a step-by-step guide for handling known problems; a rollback is returning to the previous working version; being paged means an automatic alert wakes the person who is on-call (the engineer responsible for responding to problems out of hours); model drift means the model's inputs or accuracy shift over time as the world changes; the evaluation bar is the agreed minimum score a model must reach on a test before release.

Three Accountables on one decision means nobody is accountable: each can assume another will stop a bad launch, arguments about authority replace arguments about evidence, and the decision stalls or gets made informally. Leaving operations out means the people who will be paged at 3 a.m. find out about the model after it is live, with no monitoring, no runbook and no rollback path. I would fix the chart by naming one Accountable for go/no-go, making operations Responsible for readiness and Consulted on the decision, and get adoption by using the chart in the very next launch decision.

What goes wrong

• Diffusion of accountability: with three As, a failure has three owners and no one to ask why.
• Deadlock or a quiet veto: if the three disagree, who decides? The one who is most senior or loudest, which is not a process.
• Duplicate or missing checks: each A assumes the others verified the evaluation, the data and the rollback.
• Operations surprised: no monitoring on model drift (the model's inputs or behaviour changing over time), no on-call knowledge, slow recovery. Operations is often the only group that can actually stop a bad deploy fast.
• Trust damage: blame after an incident falls on whoever is easiest to find.

The corrected chart

I would put exactly one person in the A column for each decision, the one who answers for the outcome and who, for the operational rows (readiness, go/no-go, rollback), is the person the on-call engineer escalates to when it breaks (the Accountable is the service owner; Operations staff are the ones paged first and carry the Responsible work):

Each row has one A. Operations is Responsible for readiness and for rollback, and Consulted on go/no-go with a checklist item it must tick (an alert routes to a human, a rollback has been rehearsed).

Getting people to use it

1. Build it with them. In a 45-minute working session, ask each person to say what they believe they are accountable for. Illustrative exchange: "Priya, for the go/no-go row, who do you think decides?" "I assumed the data science lead." "And you?" "I assumed it was me." That overlap, spoken aloud, is what the session is for. Gaps and overlaps become visible and the new chart is theirs.
2. Use it right away: the next go/no-go meeting reads the Accountable and the checklist aloud. Illustrative wording:

Facilitator: "Accountable for today's go/no-go is the engineering manager, Sam."
Facilitator: "Checklist. Alert routes to a human on-call?" Operations: "Yes, tested Tuesday."
Facilitator: "Rollback rehearsed?" Operations: "Yes, took 6 minutes."
Facilitator: "Evaluation bar met?" Data science lead: "Yes, results attached."
Sam: "All ticked. Go."

3. Put the checklist in the release process, so the chart is enforced by the pipeline, not by memory.
4. Review after the first incident or launch, and ask whether anyone was surprised.

Trade-offs and pitfalls

• Accountable is not the same as having a veto on everything: Consulted people still shape the call. Name the criteria that make a "no-go" automatic (for example, no rollback plan).
• If the engineering manager is too close to the delivery date, an independent reviewer from operations can hold a formal right to flag a no-go to the sponsor. I would add that only if the first launches show pressure to skip checks.

Direct answer

My example is standardizing how services emit telemetry (the logs, metrics and traces that show what a running system is doing) across nine teams that each used their own field names and formats. I started with a pilot team, made the standard cheaper to adopt than to resist, set up a small governance path for changing the schema, and reported adoption with one number everybody could check. Teams that preferred their own approach were heard first, given a route to propose changes, and then asked to meet a minimum core while keeping their local extras.

Actions and reasoning

1. Find out why teams differ before asking them to converge. In short interviews I asked each team what their format did for them. Two teams had dashboards that depended on it; three had never thought about it. That split the resisters into "real constraint" and "habit", which need different handling.

2. Pilot with one willing team. A pilot proves the standard is workable, produces a migration guide and a shared library, and gives later teams a peer to ask rather than a mandate to obey. I picked a team that was respected and had a modest roadmap.

3. Standardize the minimum, not everything. The standard is a schema: an agreed list of field names and the type of value each holds. The required core is six fields: a service name, an environment (such as prod or staging), a timestamp format, a message, a trace identifier (one ID stamped on every log line produced by a single request, so lines from different services can be joined) and a severity level (the message is the human-readable text of the log line). Anything else stays free-form under a team namespace (a prefix such as team_checkout. that marks a field as that team's own). A small standard is easier to accept and easier to enforce.

Illustrative before and after for one log line:

Before (one team's format):
{"svc":"checkout","msg":"payment failed","ts":"03/14/2026 10:02:11","lvl":"ERR"}

After (required core, plus a local extra under the team namespace):
{"service":"checkout","environment":"prod","timestamp":"2026-03-14T10:02:11Z",
 "trace_id":"a1b2c3d4","severity":"ERROR","message":"payment failed",
 "team_checkout.retry_count":2}

With a shared trace_id, an on-call engineer can search one ID and see the request's lines from every service in order.

4. Incentives that cost the team less than they save. A shared library that emits the core fields; dashboards and alerts that work automatically for compliant services; and the on-call benefit of one query working across all services during an incident. Where the incentive was weak I used a calendar fact: the central observability tool (the shared system where all services' logs and metrics are stored and searched) would stop ingesting, meaning accepting and storing, non-compliant logs after an agreed date.

5. A governance path for schema changes. The governance path is simply the defined route by which anyone can propose a change and by which it gets decided. It has a short written change request, a 5-business-day comment window for affected teams, one named owner of the schema (from the platform team) who decides, and a version number on the schema so a change never breaks a consumer silently. An illustrative request:

Title: Add optional field "customer_tier" to the core schema
Proposed by: Payments team
Why: Support needs to filter incidents by customer tier
Impact: Optional field, no existing consumer breaks
Comment window: closes 5 business days after posting
Decision: Schema owner (platform team)
Version: 1.2 to 1.3 (additive change)

6. Measure and report adoption. Adoption rate is services emitting all required fields divided by total services. Illustrative: 42 of 60 services is 70%. I posted the rate monthly with a list of which teams were in progress, not a ranking designed to shame.

Handling the teams that preferred their own approach

• Real constraint (a legacy pipeline, a regulatory format): grant a time-boxed exception with an owner and an end date, or adopt a translation layer (a small adapter that converts their old format into the standard on the way out, so the team changes nothing internally).
• Preference or habit: show them the pilot results and the library, and ask for their objections in the change request process so the standard can improve.
• Persistent refusal: escalate to the sponsor with the facts (cost to them versus benefit to everyone else), not with a complaint.

Trade-offs and pitfalls

• A standard imposed before listening produces compliance in name only; a standard negotiated forever never ships. The pilot plus the comment window balances them.
• A rule without a measure decays. Without the monthly adoption number, the standard would have been forgotten by the next reorganisation.
• One thing I would do differently: involve the on-call engineers from the start, since they feel the benefit most.