Cross-Functional Leadership and Collaboration Questions

Direct answer

I would pick a real example, say retiring a legacy authentication token format that eight teams still depended on. The pattern: write one short plan that names, per team, the code change, the process change and the runbook change; agree the "why" and an end date with a sponsor (the senior person who owns the outcome and can settle disputes); give every team one named owner; and track everything in a single shared table reviewed weekly. I got participation by making each team's cost small and visible, and by taking away their excuses (a migration guide, a test environment, office hours, a fixed weekly slot where teams drop in with questions), not by escalating.

Situation, actions, result (illustrative story skeleton)

Situation. A security finding meant the old token format had to stop being accepted by an agreed end date, week 12 of the plan. Eight teams owned services that issued or checked it. Nobody reported to me; I was the program lead, the person coordinating the effort without authority over the teams.

Actions I took, in order

1. One page of scope per team. Three kinds of work for each: code (switch to the new library), process (add a check to the release checklist so the old format cannot return), and runbooks (the written steps the on-call engineer, the person who responds first when an alert fires, follows for "token rejected" incidents and for rotating keys). A runbook is a how-to document followed during an incident.
2. A sponsor and a date. The director who owned the security finding agreed the end date and agreed to take a blocked team to the weekly leads meeting. I rarely had to use that, but teams knew it existed.
3. A per-team reason, not a general appeal. Two teams had a quarter full of customer commitments. I offered them a smaller first step (accept both formats, switch later) rather than argue priority.
4. A tracker everyone could see. One table, one row per team, one owner, status, and next date.
5. A 30-minute weekly sync for blockers only, and a short written update afterwards.

The counts agree: 5 + 2 + 1 = 8 teams. Team 8's blocker was already specific (one named request with a deadline, the agreed end date), so it met my rule for escalating and went to the sponsor on the day it was raised; the environment was granted within the week.

Result. All eight teams finished before the end date, and the old format was switched off. I then ran a short retrospective (a meeting after the work to review what went well and what to change) and noted that I should have asked for the test environment before kickoff, not at week 8.

The same pattern on an AI-feature delivery

Suppose the initiative is shipping an AI-powered search feature that needs data, a model, a front end, legal review and support training. The work is the same shape:

• Coordinate deliverables with a dependency list: each deliverable has an owner, a due date and the deliverable it blocks (for example, the front end cannot finish until the model API is stable).
• Technical blockers (model latency too high, missing training data) go on the tracker with an owner and a decision date; non-technical blockers (privacy review not scheduled, data-sharing approval pending) are treated as equally real and escalated just as fast.
• Processes added to stay on schedule: a weekly dependency review, a launch checklist with named sign-offs, and a risk list reviewed in the same meeting.

An illustrative tracker for the feature at week 4 of 8:

One row is done, one at risk, one waiting, one blocked on scheduling and one on track: 5 deliverables.

Trade-offs and pitfalls

• Escalating early wins dates but spends goodwill; I escalate only after a team has a named blocker and an agreed deadline.
• A tracker nobody reads is worse than none: keep the status definitions plain and review it live.
• Do not hide a slipping team. Naming the blocker kindly in the shared table is what unblocks it.
• A story with no "what I would do differently" sounds rehearsed, so end with one real lesson.

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

Dozens of small items fail because each team sees its piece as tiny and unowned. I would group them into a handful of themed workstreams (each a slice of the program with one owner and one theme), name one accountable lead per workstream and one overall program lead, pick a single sponsor who cares about reliability, and show progress through the outcome leadership cares about: fewer incidents and better SLO attainment (SLO is service-level objective, the reliability target for a service; attainment is how much of the time the service actually met it, such as 99.93% against a 99.9% target).

Structure the effort

1. Inventory and de-duplicate the items into one list with owner team, size, and the incident or risk each addresses.
2. Bundle into themes by shared cause, such as "deploy safety", "dependency timeouts and retries", "alerting and on-call", and "data backup and recovery". Illustrative: 36 items grouped into 4 workstreams of 9 each.
3. Rank by evidence: tie each item to past incidents or near-misses (problems that were caught before customers noticed, or that almost happened) from the last two quarters, so the order is not an opinion.
4. Fit each item into the owning team's own plan: each team is asked for one or two items per sprint (its fixed one- or two-week work cycle), not a special project, so none feels like a tax.

Who to ask to own it

• A program lead (me or a named delegate) who runs the weekly sync and keeps the single list, with no claim to authority over teams.
• One workstream owner per theme, chosen from the team with the most items or the deepest expertise. Ask them directly and tell their manager why: the ask is a visible, valued role. Sample first conversation: "You already have the most deploy-safety items and the best view of them. I am asking you to own that theme: keep the list, rank it with me, and present progress monthly. It is about 2 hours a week, I do the tracking, and I will tell your director it is a leadership role. Could you take it?"
• A sponsor at director level, such as the head of engineering or reliability, who agrees that the work counts and resolves trade-offs against roadmap work.

Showing it is working

• Items completed vs planned per workstream, each week.
• Incident count and minutes of customer-visible downtime for the failure classes the workstreams target.
• SLO attainment for the affected services.
• A "prevented" story: an incident that would have happened but the fixed item stopped.

Worked example (illustrative)

Last quarter's incident review lists 14 incidents; 9 trace to causes covered by items in the backlog. That is the opening argument: "9 of 14 incidents map to work already identified." Each month the program lead reports how many of those items are closed and whether incidents of those classes recur.

Pitfalls

• Treating the list as a to-do list and shipping the easy items first; rank by incident evidence.
• Over-reporting item counts, which rewards trivial closures. Pair them with outcome measures.
• Asking teams for large blocks of time; the small-item approach works only if requests stay small.
• With no sponsor, the items remain low priority forever.

Direct answer

I would make the case with the platform's own demand data and the product teams' own delay costs, propose a "you build it, you run it" shared-responsibility model (service teams operate their own services on a paved road the platform provides), and shift ownership in stages with written agreements. Ownership truly moves only when on-call, runbooks and roadmap commitments move, not when a slide says so.

Making the case

Terms: on-call means being the engineer who gets automatically paged (alerted by phone) when a service breaks and who must respond; a paved road is the supported, ready-made way to do a common task (templates, tooling), so teams do not build their own; an SLO (service-level objective) is a stated reliability target, such as "99.9% of requests succeed".

• Pull a month of requests. Illustrative numbers: 60 requests per week to five platform engineers, 70% of them routine (new environments, access, standard config), so 60 x 0.7 = 42 are routine and 18 need real platform expertise.
• Show product teams that the queue is their delay: the same data shows how long their requests wait.
• Offer a trade: the platform builds self-service for the 42 routine requests, and in return service teams own their service's operation and reliability.
• Note the load behind it: 60 requests a week across five engineers is 12 each, every week, before any project work.

Illustrative wording of the pitch: "Today your requests wait in a queue that takes 60 requests a week, and 42 of those are routine. If we give you self-service for those, you stop waiting, and in return your team runs your own service and carries its pager. We will keep our time for the 18 requests that need real platform expertise."

What I would put in place

1. Self-service paved road: templates and tooling so routine requests need no ticket.
2. Service readiness checklist: a service is handed to its owning team with a runbook (step-by-step instructions for handling known problems), dashboards, alerts and a stated reliability target (SLO, service-level objective).
3. On-call by owner: the team that ships a service is paged for it; the platform is paged only for platform faults.
4. Intake rule: a request queue with a weekly triage, a published "what we do and do not do" list, and an escalation path for genuine exceptions.
5. Platform office hours instead of ticket-by-ticket help, to move expertise sideways.
6. Phased transfer: start with two willing teams, learn, then extend, so the platform is not demanding change from everyone at once.

Applying the model when an SRE team supports an ML team's model service

When a site reliability engineering (SRE) team supports a machine-learning (ML) team's model service (the running system that answers requests using the model), the same shape applies: shared objectives (both teams carry the same serving SLO, meaning the reliability target for answering requests, and the same latency target for response time or freshness target for how recent the model's data is), runbook ownership (the ML team writes the model-specific runbook, the SRE team owns the platform and paging tooling), a monthly review cadence over incidents and SLO attainment, and incentives that reward the ML team for operational health, not only model accuracy.

Worked example (illustrative numbers)

Assume a routine request takes about 1.5 hours of platform time.

• Quarter one: two teams adopt the shared-responsibility model and together send 20 of the 60 weekly requests. At 70% routine, 14 of those move to self-service. The platform's weekly load drops from 60 to 46 requests, freeing 14 x 1.5 = 21 hours a week, about half an engineer's week, for the hard requests and the next paved-road item.
• Quarter two: four more teams adopt, sending another 30 requests a week, of which 21 are routine. Cumulative routine requests moved: 14 + 21 = 35 of the 42. Weekly load is now 60 - 35 = 25: the 18 hard requests plus 7 routine ones from teams not yet adopted. Freed time is 35 x 1.5 = 52.5 hours a week, a little over one engineer's week.

Trade-offs and pitfalls

• Pushing operations onto teams without tooling and training just moves the service desk into every team.
• Two terms behind the plan: the intake rule is the published way requests enter the queue and get triaged weekly, and an escalation path is the named person to go to when a request is urgent or stuck.
• If leadership does not protect service teams' capacity for operations work, ownership drifts back.
• Measure success by fewer routine tickets and by services meeting their targets, not by a headcount of teams "migrated".

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.