Cross-Functional Leadership and Collaboration Questions

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

Conflicts that return every week usually mean the program never settled who decides and never recorded what was decided, so each disagreement is argued fresh. I would diagnose by sorting the repeated conflicts by cause, then put in place decision rights (a written rule for who has the final say on each kind of decision), a short decision cadence and a written decision log, and I would check in three months by counting how many conflicts are repeats.

Diagnose first

Read the last 6 to 8 weeks of meeting notes (long enough to see what repeats) and tag each recurring conflict with one cause:

• Unclear ownership: two teams think the decision is theirs.
• Unmade decision: everyone agrees it is open, nobody is tasked with closing it.
• Conflicting goals: each team is rewarded for something different.
• Missing information: people argue because no one has the data.
• Overturned decisions: a decision was made and then reopened by someone with more power.

The distribution tells me what is missing. Mostly ownership means fix decision rights; mostly conflicting goals means go to the sponsor.

What I would put in place

• Decision rights: for each contested decision type, one Approver (the person who makes the final call) and a Driver (the person who prepares the case and options). This is the DACI pattern: Driver, Approver, Contributors (heard, not voting), Informed (told the outcome).
• Cadence: a weekly 30-minute decision session. Contested items go here, not into side threads (chat or email conversations among a few people, where others cannot see or weigh in).
• Written artifacts: a one-page decision brief and a decision log that records the outcome and the reason. A decision counts as reopened only with new information.
• Escalation rule: an item unresolved after two sessions goes to the sponsor.

A brief fits on one page. Example (illustrative):

Question: Who owns the release-date call when QA and Product disagree?
Options: (A) Product decides, QA advises. (B) QA holds a veto on severity-1 bugs only.
Recommendation: B, because it matches who carries the risk.
Decide by: Friday session. Approver: Engineering director. Driver: me.

The log then gets one line: "Decided B on 14 Oct. Reason: severity-1 bugs reach customers. Reopen only with new data."

Worked example (illustrative)

Take the most recent four weeks of the notes as the baseline: 12 conflicts raised, 7 of them topics already discussed before. 7 / 12 is about 58% repeats. After three months I would expect repeats to fall to about 1 or 2 per month and the median time to a decision to shorten. To keep the bases the same, compare shares and not raw counts: if about 12 conflicts are still raised in a month, 1 or 2 repeats is roughly 8% to 17% (1 / 12 to 2 / 12), against 58% at baseline, and if the number raised also falls, recompute the share rather than comparing 7 with 2. Use the same definition both times: a repeat is a topic that was already discussed and agreed or closed and is raised again without new information. The baseline above has no log yet, so it counts topics already discussed in the notes; once the log exists, recount on the logged-as-decided definition and compare like with like. If repeats stay high, the Approver is not being respected or the decision log is not being used, which is a sponsor conversation.

How I would tell it worked

• Repeat rate: conflicts that return after being logged as decided.
• Time to decision: median days from raised to closed.
• Escalations: the number should first rise (hidden issues surface) and then fall.
• Team view: a short two-question survey ("do you know who decides X", "do decisions stick").

Pitfalls

• Rights imposed without the sponsor's backing will be ignored.
• Some conflict is healthy debate; the aim is conflict that ends.
• Too much documentation: one page per contested decision is enough.

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

A healthy cross-team initiative is one where milestones are on forecast, blockers and decisions are not aging, each team has confirmed capacity, and the teams actually understand what they owe each other. I would use a one-page weekly view where every row has a threshold and a named action it triggers, so the page is for deciding, not for admiring.

The view (one row per signal)

Thresholds are illustrative starting points; adjust them to the program's pace. Overall status is the worst row on the page: any red row makes the program red, and amber with no red makes it amber, so one aging blocker cannot be averaged away.

Worked example (week 5 of 12)

8 milestones in total, 4 due by now, 3 done: milestone 4 is one week late and counts amber. Three open blockers, oldest at 7 working days: red, escalate to directors. Two undecided decisions, oldest 6 days: amber. Alignment pulse on "I know what my team owes others in the next four weeks": five leads score 5, 4, 4, 5, 3; average is 21 / 5 = 4.2, but the lowest is 3, so I talk to that lead before reading anything into the average. Capacity: Teams B and C both claim the same two engineers, so one team is short but neither is on the critical path: amber. The pulse's lowest score of 3 is amber. The outcome measure is flat at 29 against a baseline of 30: amber. Overall status for the week is red, because the blockers row is red; the other amber rows are the next ones to watch.

Audience-specific views

• Engineers: blockers, dependencies, who is waiting on whom, this week's integration points.
• Product: scope trade-offs, milestone forecasts, customer-facing dates.
• Executives and sponsors: three lines (status, top risk, the ask), the outcome measure, and any escalations due. Filled in for the week-5 example: "Status: red (blockers aged 7 working days, escalated to directors); also amber: milestone 4 one week late, one decision aged 6 days, the capacity dispute, one lead scoring 3 on the pulse, and the outcome flat. Top risk: 3 blockers open, oldest 7 working days. Ask: decide the capacity dispute between Teams B and C by Friday. Outcome: median onboarding 29 days against a baseline of 30 and a target of 20."

The stakeholder risk indicators (such as a sponsor who has missed two check-ins, or a team that missed its capacity commitment) sit on the sponsor view because only the sponsor can act on them.

Avoiding a vanity report

• Show forecasts, not only completed work, since percent complete hides slip.
• Report bad news in the same format and place as good news.
• Pull data from the teams' own tools to avoid creating reporting work.
• Retire any row nobody has acted on in a quarter.

Pitfalls

• Counting tasks done as health; outcomes matter more.
• Averaged pulse scores that hide one unhappy team.
• A status that is green until it turns red; the amber rows exist to remove surprise.

Direct answer

In 30 days I would diagnose first, decide second, and reset third: listen widely and inventory the work in the first 10 days, make explicit decisions about scope, owners and sponsor in the next 10, and take a re-baselined plan (the plan with its dates and scope reset to a new official version) to a steering group for sign-off in the last 10. I would also decide whether the initiative should continue at all.

Structured elaboration

Days 1 to 10: diagnose

• Read the charter (the founding document that states the goal, scope and owners), the plan and the decision history.
• Talk to the sponsor, team leads, and the people doing the work; ask what they think went wrong and what they would drop.
• Inventory every work item, status and dependency. List the milestones that slipped and why.

Days 11 to 20: decide

• Scope: sort items by one test, "does the outcome the sponsor still wants fail without it?". Must: yes, or another must item depends on it. Should: it adds value but the outcome survives without it. Cut: it has no owner or no longer ties to the outcome. Then freeze scope and add a change rule (change control: nothing is added without approval). Illustrative wording: "Any new item needs a named owner, a cost, and something of equal size removed, approved by the sponsor in the weekly forum."
• Owners: one accountable owner per workstream (one strand of the work, such as data migration or training), named and agreed.
• Sponsors: one executive sponsor accountable for the outcome and available for decisions. Illustrative conversation: "I need one person who can say yes or no to scope and dates within two days. If that is you, I need that decision time weekly. If not, who?" If no one will take it, stop or pause the work.
• Governance: a short regular forum with decision outputs, not status readouts.

Days 21 to 30: reset

• Present the plan, with outcome-based milestones and risks, to the steering group, the senior forum overseeing the program. A milestone says what is delivered, not what activity is done. Bad: "Integration work complete." Good: "Orders from 3 pilot stores flow through the new system with no manual fixes for a full week." Get a signed decision, worded on the slide as: "Continue with the reduced scope, shrink further, or stop. Recommendation: continue with 22 items."

Worked example

Illustrative: the inventory finds 60 work items. After review: 22 must, 18 should, 20 cut (22 + 18 + 20 = 60). Only the 22 are committed; the 18 become a ranked list funded only if capacity appears. The 20 cut are listed, and the people who had been working on them are told in person before the steering group meets, so nobody learns of the cut from a slide. Timeline check: 10 + 10 + 10 = 30 days. Root causes named: scope growth without change control, milestones defined as activities, and a steering group that heard updates without making decisions.

Trade-offs and pitfalls

• Cutting scope costs goodwill with teams whose work is removed; tell them early and explain.
• Do not blame the prior leader; focus on the system that allowed the drift.
• The hardest decision is stopping; a rescue that never asks whether to stop is not a rescue.