Cross-Functional Leadership and Collaboration Questions

Direct answer

A quick vocabulary check: an API is the interface other software uses to talk to a service; clients are the programs or customers that call it; deprecation is announcing that something will be switched off on a given date; SRE (site reliability engineering) is the team that keeps services running reliably.

Use DACI for a single, important decision where you need one person to decide (should we retire this API version?). Use RACI to organise the many pieces of work that follow once the decision is made (announce it, migrate clients, switch it off). DACI answers "who decides"; RACI answers "who does what and who answers for each piece".

The two frameworks

• RACI: Responsible (does the work), Accountable (the one answerable for the result), Consulted (gives input first), Informed (told after). Many project-management sources say each task should have only one Accountable.
• DACI: Driver (runs the process and drives to a decision by the agreed date), Approver (the one person who makes the decision), Contributors (people with knowledge who recommend but do not vote), Informed (affected people who are notified). Atlassian's guidance is explicit that there is exactly one Approver ("the one person (yes: one!) who makes the decision"); a single Driver is the usual practice rather than a stated rule.

Applying it to retiring an old API version

Step 1: the decision (DACI). "Retire version 1 of the public API on a given date?"

• Driver: the product manager for the API, who gathers usage data and sets the decision date.
• Approver: one person, the head of the platform group that owns the API.
• Contributors: SRE (operational savings), support (customer impact), security (risk of keeping old code), the largest client-facing teams, documentation.
• Informed: customers, sales, partner teams, via the announcement later.

What the Driver sends the Approver is a one-page brief. Illustrative:

Decision: Retire version 1 of the public API on 31 March 2027?
Options: (1) retire on that date, (2) extend by 3 months, (3) keep indefinitely
Usage: 3% of calls, from 4 known clients (named in the appendix)
Cost of keeping it: a separate deployment and its own on-call rotation
Recommendation: Option 1, after direct outreach to all 4 clients
Decision needed by: 14 November. Approver: Head of Platform

Evidence the Driver brings: the share of traffic still on version 1, the list of clients that call it, and the cost of keeping it running. Illustrative: if 3% of calls still use version 1 and they come from 4 known clients, the Approver can decide with specific names to contact.

Step 2: the execution (RACI).

Each row has one Accountable.

Pitfalls

• Using RACI to decide leads to arguments about who is Accountable; the decision is the thing needing an owner.
• Too many Contributors makes DACI a committee. Cap them at those with information the Approver lacks.
• Atlassian's DACI guidance describes the Approver as "the one person (yes: one!) who makes the decision", which is why the Approver here is one person and not the platform group.
• Write the decision down, with the date and reasoning, so it is not reopened without new evidence.

Direct answer

I would use three tiers so most decisions never leave the team, give each cross-team decision exactly one person with the final say, put a clock on every stage so a stuck decision moves up automatically, and write each outcome as a short decision record. Teams stop relitigating because the decision, the reasoning and the person who made it are in one place, and reopening needs new evidence.

Which decisions stay local and which need agreement

Ask two questions: does the choice affect another team's work, and is it hard to undo?

A decision is "cross-team" when another team would have to change its code, data or plan because of it.

Who has the final say

For each cross-team decision there is one Approver (the same idea as the single decision-maker in DACI, a framework with four roles: the Driver runs the process and chases the decision, the Approver makes it, Contributors supply knowledge and recommendations, and Informed people are told the outcome). Rule: the team that owns the thing being changed decides, after hearing the affected teams. If two teams co-own it, the architect group's rotating chair decides (the architect group is a small standing set of senior engineers, one from each team, who look after shared technical standards). Everyone else is a contributor who can recommend but cannot veto. The Driver is the proposing team's engineer, who runs the steps below and chases the decision date.

How a stuck decision escalates

The Approver normally decides at the end of the live discussion; escalation applies only when an affected team still disagrees after hearing the Approver's reasoning, or the Approver has not decided by the deadline. The maximum time from proposal to decision is 5 + 2 + 5 = 12 business days, so no decision is stuck for longer than about two and a half weeks.

How the outcome is recorded

Use an architecture decision record (ADR, a format popularised by Michael Nygard) with sections for Title, Context, Decision, Status and Consequences, plus the names of the Approver and the date. Illustrative entry:

Title: Orders events use the v2 schema
Context: Billing and Fulfilment each parse orders differently; two incidents in a quarter.
Decision: Orders publishes a versioned v2 event; consumers migrate within 60 days.
Status: Accepted (Approver: Orders tech lead, decided at the end of the live discussion, step 2)
Consequences: Billing must change its parser; v1 is deprecated after the window.

Reopening a record needs new evidence (a failed assumption or a changed constraint), stated in a new record that supersedes the old.

Trade-offs and pitfalls

• Too many cross-team items recreates the committee it was meant to replace; I would review the tier criteria after one quarter.
• "Owner decides" can feel unfair to a consumer team, so the consequences section and the written comment step show their input was heard.
• Without the clock, escalation depends on someone feeling brave, and decisions drag.

Direct answer

I would not argue about whose estimate is right. I would run a short, joint, evidence-gathering step that both teams trust, then decide on the facts with Marketing, because by then the question is no longer "who is right" but "what do we do about a real number". The decision rule: if the evidence shows the gap fits in the schedule's float (spare time), protect the date as is. If it uses up the float, protect the date only by cutting scope or adding a safeguard that Marketing accepts. If it exceeds the float and no acceptable cut exists, move the date early and once, with a clear new commitment.

Step 1: Find out what is true (within the first week)

• Define "ready" with the partner team: not "code merged" but "behaves correctly against our system with production-like data" (test data that matches real customer data in volume and messiness, not three tidy sample rows).
• Joint spike: a spike is a time-boxed investigation (a few days at most, with a question to answer, not a feature to build). Engineers from both teams spend it on the riskiest integration points, the places where the hidden complexity is suspected.
• Integration smoke test: a quick, basic check that the main path works from end to end, run in a shared test environment, producing a pass or fail with logs both teams can read.
• Frame it as help ("let us make sure we both find out early") so the partner team does not feel audited.

Step 2: Establish the facts about the date

Ask Marketing what is truly fixed: a press event, paid media, a partner announcement? What would it cost to move, and what would it cost to launch with fewer features? Often "locked" means "expensive to change", which is negotiable.

Step 3: Options and contingency

1. Protect the date with reduced scope: launch without the feature that depends on the partner component, behind a feature flag (a switch to turn it on later).
2. Protect the date with a fallback: launch with a simpler workaround integration.
3. Move the date by the amount the spike supports, plus a margin.
4. Add capacity: usually weak; new people take time to learn, so it rarely helps in a few weeks.

Worked example: decide and communicate (illustrative numbers)

Suppose launch is 6 weeks away; the partner says no more work, our engineers suspect 2 to 4 more weeks, and we need 1 final week for integration testing and launch checks. So code must be complete by week 5. Suppose the spike finishes by the end of week 1. If it shows 1 more week of work, code completes at week 1 + 1 = week 2, well ahead of the week 5 cut-off, so we protect the date. If it shows 4 more weeks: work starting at week 1 completes at week 1 + 4 = week 5, which is exactly the cut-off, with no float, so any further slip breaks the date; I would then offer Marketing option 1 or 3. If it shows 6 weeks, code completes at week 1 + 6 = week 7, and with 1 week of testing the launch is ready at week 8, two weeks past the date, and the date must move or the scope must shrink. The decision belongs to the person who owns the launch commitment; I bring the options and a recommendation and escalate through the agreed chain if the two teams disagree on the numbers: first the two team leads, then their directors, then the launch owner, each with a short time limit (say 2 days). I present both numbers, not accusations.

Pitfalls

• Telling Marketing "it might slip" with no range; give a date, a confidence level and the next checkpoint.
• Using the partner team as the villain, which damages the next dependency.
• Padding the date secretly instead of showing the reasoning.

Direct answer

I would give every shared outcome exactly one accountable owner, make the contributions of each team explicit, and change what happens after a failure: look at the system and the agreements, not the person. Accountability and blame are different things. Accountability means someone is answerable for the result and has the standing to fix it; blame asks who to punish.

Structured elaboration

1. One owner per outcome. In a RACI table (Responsible does the work, Accountable is answerable for the result, Consulted is asked first, Informed is told), each row has exactly one A. Shared "ownership" by three teams means no one owns it.
2. Outcome vs component. The outcome owner is accountable for the end-to-end result (for example, checkout availability); each component team is responsible for its piece and for honouring its interface (the agreed way another team's code calls it, such as which requests it accepts and how it answers).
3. A shared measure. One service-level objective (SLO, a target such as "99.9% of checkouts succeed") for the outcome, plus an error budget (the allowed amount of failure; at 99.9% success over 1,000,000 checkouts a month, 0.1% or 1,000 checkouts may fail) so the discussion is about numbers, not stories.
4. Blameless reviews. After a failure, a review asks "what made this action reasonable at the time, and what in our process let it through", and ends with action items, each with one owner and a date. A sample sentence from such a review: "The client retried immediately because the error message said 'try again', and the server had no limit on retries; both were reasonable given what each team could see." Blameless does not mean consequence-free for ignoring agreed actions; repeated unowned actions are themselves a finding.
5. Fix the seams. Most finger-pointing happens at the seams, the boundaries where one team's work hands over to another's and nobody owns the join. List the seams (retries, timeouts, which team's pager an alert goes to) and give each an owner.

Worked example: checkout spans three teams

In the table, EM means Engineering Manager.

Every row has exactly one A. After the next incident, the review finds a retry storm: when a request fails, many clients retry it at once, and the extra load makes the failing service fail more. Here Mobile's client retried instantly (backoff means waiting longer between retries, for example 1, 2, 4 seconds), and the Payments API published no retry limit or backoff guidance. Before the incident the table had no row for the retry contract between them, so no one owned that seam; the review adds the row shown above, with Payments as the single A. Result: an action for Payments (publish the retry limit and backoff guidance) and one for Mobile (add backoff to the client), each with an owner and date, and no one is named as the cause. Every row, including the new one, still has exactly one A.

Trade-offs and pitfalls

• Making the Payments EM accountable for the outcome gives them influence over teams they do not manage; pair it with a sponsor who backs the role.
• Too many single owners can recreate silos; keep a joint review each month.
• A blameless culture fails if leaders blame in private. Say how you will react before the first incident.

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.