Cross-Functional Leadership and Collaboration Questions

Direct answer

I would write a one-page charter that fixes the problem, the outcome, the limits of the group's authority and the date it ends; invite the people who produce, consume and repair the data rather than everyone interested; and get recommendations implemented by turning each one into a funded item in the owning team's plan, backed by an executive sponsor. The group recommends and tracks, the teams own the work.

The charter

An illustrative excerpt (the numbers are examples, not benchmarks):

Purpose: Reduce downstream incidents caused by bad data in the datasets feeding finance reporting (orders and customers first).
Outcome (end of two quarters): Every dataset in scope has a named owner, a written quality
  check for completeness and freshness, and an alert that reaches the owner.
In scope: The 12 datasets feeding finance reporting. Out of scope: Personal data policy.
Authority: The group recommends standards and owns the shared checks and template on the data platform. Each team decides how to meet the standards.
Sponsor: Head of Engineering; resolves disputes within 5 business days.
Cadence: 45 minutes every two weeks; ends after 6 months unless renewed.
Decisions: Proposals pass when no member objects with a reason; the chair decides otherwise.

The sponsor is a senior leader with authority over the teams involved who publicly backs the group and settles disputes the group cannot, which is how a chair with no reporting line still gets decisions to stick.

Definition used: data quality means the data is fit for its use, checked on dimensions such as completeness (nothing missing), freshness (recent enough), validity (right format and range) and uniqueness (no duplicates).

Who must participate

Use a simple test: who creates the data, who relies on it, who repairs it, and who can say yes to the work?

• A producer from each team that owns a source dataset (they can change the code).
• Two or three major consumers (analytics, finance, a machine learning team) who feel the pain.
• A data platform representative who owns tooling.
• The sponsor, who attends the first meeting and receives a short written update each month.

Keep it to about eight people; the rest are informed.

Making recommendations land

1. Name the owner of each recommendation inside the team that must do it, and get them to accept it in the meeting, not afterwards.
2. Size it in person-days (one person working one full day) so the team can plan it. For example, adding a freshness check to one dataset might be 2 person-days; the team's manager can then see it is a small item that fits in the next planning cycle. The check itself might be: raise an alert, meaning an automatic message to the dataset owner's channel, if the orders table has not been updated in the last 6 hours.
3. Start with the incident evidence: two or three recent outages traced to bad data persuade more than a policy.
4. Make the easy path the right path: a shared set of checks and a template teams can adopt in an afternoon.
5. Track in a one-table dashboard. Review monthly with the sponsor. Illustrative extract:

If the full table covers 3 of the 12 datasets with both a check and an alert, that is 25%, a number the sponsor can watch rise.

Trade-offs and pitfalls

• A group with authority to mandate would work faster but earns resentment; I would ask for authority only over the shared platform.
• Charters that list every dataset fail. Start with the 12 that matter and widen later.
• If after a quarter no team has funded its items, escalate to the sponsor using the dashboard rather than lowering the bar.

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.

Direct answer

I would separate "who owns the dataset" from "who uses it", pick the owner with a short set of explicit criteria, and write the guarantees down as a data contract (a short written agreement between the team that produces a dataset and the teams that use it, stating what each side promises): the owner promises specific things, consumers promise specific things, and conflicting demands are resolved by tiering the guarantees or splitting the offering. To make it last, the owner goes in a registry, changes follow a process, and the guarantees are measured and reviewed on a schedule.

Structured elaboration

1. Pick the owner by criteria, agreed before naming anyone. Typical criteria: who produces the data and controls its write path (the code that creates and updates it), who has the domain knowledge to judge correctness, who carries the on-call burden when it breaks, and who has the budget. Ownership means accountable for correctness, availability and change; it does not mean the only user.
2. Surface the conflicting guarantees. Ask each team for the decision that fails if the guarantee is missing. Often one wants freshness (data updated within minutes) and the other wants stability (no schema changes without notice, fully reconciled numbers). Those are different products.
3. Resolve the conflict by tiers. Offer a fast, provisional view (quick figures that may be corrected later) and a slower, reconciled view (figures checked against the official records and corrected until the totals match), each with its own promise. Where that is not possible, the sponsor decides which need wins and records why.
4. Write the contract. Illustrative terms:

5. Keep it settled six months later. Record the owner in a catalog or registry (a searchable list of datasets and who owns each), add an automated check for each promise, put a review in the calendar at three months, and make any ownership change go through the same decision-rights step: name who decides before arguing the merits. The on-call rota (the schedule of who gets paged when the dataset breaks) is part of the owner's commitment.

Worked example

Team A (analytics) wants data reconciled to the ledger, daily. Team B (fraud) wants every event within minutes. Both claim the dataset. The platform team that writes the events becomes owner; it publishes a provisional stream (illustrative terms: updated within 15 minutes, figures typically within 1% of the final numbers) for B and a reconciled daily table (complete by 06:00 each day, totals matching the ledger exactly) for A. If the two teams cannot accept this, the sponsor, here the head of data, decides and records why. The disagreement turns into two contracts and no team loses its core need.

Pitfalls

• Giving ownership to the loudest team rather than the one that controls the write path.
• A contract no one monitors decays; wire alerts to the promises.
• Ownership by committee; one named team, with the others as consumers.

Direct answer

With no reports, I run the year on three things: a regular sponsor rhythm (a sponsor is the senior executive who funds and backs the program) built around decisions, a wave plan (migrating in batches, not all at once) that lets resistant engineering leads join on terms they helped shape, and milestone ownership with a visible tracker and pre-agreed escalation triggers.

Structured elaboration

Keep executive sponsors engaged

• A monthly 30-minute sponsor review. Each one ends with one or two asks, because sponsors stay engaged when they have something to decide. Example ask: "Approve two migration engineers for the billing domain for six weeks. Without them its wave moves from Q3 to Q4."
• A one-page status. Illustrative excerpt: "Month 6. Domains migrated: 6 of 20 (30%), plan was 6. Risks: sales-data freeze date at risk (amber). Asks: two migration engineers for billing."
• Early visible value: migrate one valuable domain first (a domain is one business area's data, such as sales or billing) and report the benefit.

Handle engineering lead resistance

• Ask what they fear: migration cost, losing control, risk to their roadmap. Illustrative opener: "Before I propose dates, what would make this migration painful for your team? I would rather build the plan around your roadmap than around mine."
• Give them a seat in design decisions on the platform, and a wave slot that fits their roadmap.
• Fund or staff migration help; do not leave it as unfunded work.

Maintain accountability for milestones

• Each domain migration has one named owner on the receiving team and a date that owner agreed to. Agree the shape of each milestone with the lead in advance: the date, the order of work and what counts as done.
• A shared tracker everyone can see. Illustrative row: Billing | owner: Sam | wave 3 | freeze date: 12 Sept | status: amber | next step: engineers approved. A freeze date is the day a team stops changing its old system so the data can be moved.
• Escalation ladder: a milestone more than 2 weeks late goes to the lead's manager; more than 6 weeks late, or two misses in a row, goes to the sponsor.
• Status colours have definitions: green on time, amber up to 2 weeks late with a recovery plan, red beyond that.

Worked example

Illustrative: 20 domains over 12 months. Quarter 1: build the foundation (the shared base platform every domain moves onto) and migrate 2 pilot domains. Quarter 2: 4. Quarter 3: 6. Quarter 4: 8. Total 2 + 4 + 6 + 8 = 20. At the end of Quarter 2, 2 + 4 = 6 are done against a plan of 6. In Quarter 3, one lead reports a freeze that moves their domain: that is amber if it moves 2 weeks, and I take it to their manager if it moves more. I also publish the benefit delivered to sponsors, in plain terms: for example "reporting now runs from one source for 6 domains".

Trade-offs and pitfalls

• Waves reduce risk but lengthen the period when two systems coexist, which costs duplicated operations.
• Sponsors disengage after a strong kickoff; do not rely on goodwill, give them asks.
• Skipping the escalation ladder at the start makes the first escalation feel like an accusation.

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.