Cross-Functional Leadership and Collaboration Questions

Direct answer

I would check the facts first, then bring both teams into the same conversation as peers with the evidence, and let the person who has authority over both decide whether to merge, share or diverge on purpose. I do not decide for them, because I manage neither team, and I assume each had good reasons.

Structured elaboration

1. Verify before raising it. Are the capabilities actually the same? Read their plans, then ask each lead a neutral question: "what problem are you solving, for whom, and what is your timeline?" Many "duplicates" differ in a requirement that matters. A plain opener: "I saw both of you working on a share-link feature. I may be missing context. What problem are you solving, for whom, and by when?"
2. Talk to each lead separately first. Share what I saw, ask what I am missing, and learn their constraints, so neither is surprised in a group.
3. Find the real decider. Usually a shared manager, product director or architecture group (a standing group of senior engineers who set technical standards). Bring them a short note, not a complaint. For example: "Teams A and B each plan a share-link feature, about 8 engineer-weeks each. I have spoken to both leads. Options and costs are below; could you pick a direction by the 20th?"
4. Offer options with costs. (a) One team builds, the other consumes; (b) merge into a joint effort; (c) keep both and agree a shared user-experience contract (a short list of rules both teams follow, so users see one product). For example: both call it "Share", both create links that expire after 7 days, and both show the same "Link copied" message; (d) do nothing, with the cost of inconsistency stated.
5. Protect both teams' standing. Credit the work already done, and make any change a joint decision with a date.

Worked example (illustrative effort)

Each team estimates 8 engineer-weeks. Twice: 16 engineer-weeks. One build plus 1.5 engineer-weeks for the other team to adapt: 8 + 1.5 = 9.5, saving 6.5 engineer-weeks. Add the user cost: two inconsistent behaviours, two support paths. But if Team B ships in a month and Team A's version is nine months away, sharing could delay B, so the recommendation might be "B ships now, A adopts later".

Pitfalls

• Going over the heads of the leads. Give them the first chance to resolve it.
• Assuming duplication is waste: sometimes it is a cheap experiment.
• Raising it in a public forum, which turns a coordination problem into a status contest.

Direct answer

For a nine-month privacy compliance program (a program that changes how the company collects and uses personal data to meet laws such as GDPR in the EU or CCPA in California), I would set up a steering group: the senior group that sets direction and settles decisions the working teams cannot. It has an executive sponsor as chair, one named lead from each function, a monthly 60-minute meeting plus a working group every two weeks, a decision table that gives every decision one owner, and a deadlock rule that sends a stuck decision to the sponsor within a set time.

Membership and roles

• Executive sponsor (chair): accountable for the program outcome, breaks ties.
• Program lead (me): prepares each decision brief, runs the meeting, keeps the decision log (a running record of each decision: date, what was decided, who decided, why). Does not vote.
• Legal lead: interprets the regulatory requirements (what the privacy laws actually oblige the company to do).
• Security lead: owns control design (the technical and process safeguards, such as encryption and access limits).
• Engineering lead: owns delivery and technical feasibility (whether something can be built, and how long it takes).
• Product lead: owns customer-facing changes.
• Marketing lead: owns changes to how customer data is used in campaigns.

Seven seats; each person can commit their function's capacity.

Cadence

• Steering group: monthly, 60 minutes, decisions only.
• Working group: every two weeks, 45 minutes, delivery and blockers.
• Ad hoc: a decision that cannot wait 30 days is decided by its owner and reported at the next meeting.

Which decisions need whom

Each row has exactly one decider. The last row is the only one where the whole group discusses before the sponsor decides, because it trades one function's cost against another's.

Deadlock

If a decision is not settled in the meeting (no one can accept the outcome), the program lead writes the options and each side's cost in a half-page brief. The sponsor decides within 5 working days, the decision and reason go in the log, and the losing side's concerns are recorded. Repeated deadlock on the same topic means the decision rights are wrong, so I change the table.

The deadlock rule applies when a decision straddles two rows, or when a consulted function cannot accept the owner's call on a point of law or security. If a row's owner is clear, that owner decides after consulting and no escalation is needed. A log entry is short. Example (illustrative):

D-014 | 12 March | Consent banner wording
Decision: use the Legal-approved plain-language wording.
Decider: Sponsor (the wording sits between two rows of the decision table, what the law requires, which Legal decides, and the consent flow, which Product decides; the two leads deadlocked on which governs).
Reason: Legal's version meets the stricter regional reading; Product's conversion loss judged acceptable.
Dissent recorded: Product wants to A/B test a shorter version in month 6.

When the program spans several regions

A multinational program has the same decisions repeated in each country, which invites duplicated effort. Each region sends one representative to the working group, not the steering group. One global standard is set once, using the Legal row (what the law requires) and the Security row (how a control is designed) of the table above, and regions add only the local differences their law requires.

Pitfalls

• Everyone attending as a "stakeholder" with no seat in the decision table.
• A steering group that reads status. Decisions are the agenda.
• No decision log, so the same topic returns each month.

Direct answer

A program is a set of related projects pursued toward one larger goal, such as moving all customers to a new payment provider; program management is the job of coordinating the work, dependencies, risks and reporting across those projects. A squad is a small product team that owns one area of the product. A central program office gives consistency and a portfolio view; embedded program managers give speed and context. I would favour a hybrid for a company with many product squads and a handful of large cross-team programs: a small central core owns standards, tooling and the few biggest programs, while program managers embedded in squads run the day-to-day work. Accountability stays clear because every program has exactly one named accountable owner, whoever employs them.

Trade-offs

Which contexts favour each

• Central: regulated work, large programs touching many teams, a young company that has not yet built shared habits, or when leadership needs one view of the portfolio.
• Embedded: autonomous product squads with stable ownership, fast iteration, and mostly self-contained work.
• Hybrid where both conditions hold in different parts of the company.

Moving to a hybrid without losing accountability

1. Define what the centre keeps: the program standards (a common template for status and risk), the tooling, the portfolio review (a regular look at all programs together, to decide where people and money go), and oversight of the programs spanning three or more squads (the centre appoints the single accountable owner for each, often the embedded program manager of the squad doing most of the work).
2. Define what embedded people own: the delivery rhythm of their squad's programs, and dependency tracking into neighbouring squads.
3. Pilot with two squads for a quarter. Worked example: if 3 central program managers cover 12 squads today, the pilot moves 2 of them into 2 squads, leaving 1 central plus the 2 embedded, and shows whether the portfolio view survives.
4. One accountable owner per program is written on the program page, with a dotted-line reporting relationship (a secondary line: the person's manager is in their squad, but they also answer to the central lead for standards and career growth). The common template stays short. An illustrative status entry:

Program: Checkout migration to the new payment provider
Accountable owner: Priya N. (program manager embedded in the Payments squad)
Squads involved: Payments, Cart, Support tools
Status: Amber. Milestone 2 (Cart integration) is one week late.
Top risks: Provider test environment unstable; refund flow not yet specified.
Dependencies: Support tools needs the new refund API by 14 Nov.
Needs from the centre: Portfolio review to rebalance one engineer to Cart.

This program spans three squads, so the centre appointed Priya, embedded in the squad doing most of the work, as its accountable owner and keeps oversight. Priya runs the day-to-day; the central lead sets the template and sees this entry next to every other program's, which is how the portfolio view survives.
5. Measure with simple outcome signals: on-time delivery of program milestones, number of surprise dependencies found late, and squad satisfaction. Review after two quarters and adjust.

Pitfalls

• A hybrid with two bosses and no rule on who is accountable is the worst of both; the one-owner rule prevents it.
• If the centre insists on heavy reporting, embedded managers will game it. Keep the template short.
• What would change my recommendation: if squads share almost no dependencies, I would drop the centre to standards only.

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

I would tell a story where I was not the manager of anyone involved, set direction in writing before building, got each group to agree to a specific trade-off, and could show what changed afterwards. Below is one such story told in the shape an interviewer wants: situation, my actions, result and what I would do differently.

The story (situation, actions, result)

Situation. I was a senior engineer on a four-person team (a small project) asked to ship a usage-reporting feature for customers. It needed product (who owned the priority), a platform engineering team (who owned the data), and finance, a business team that wanted the reports to support invoicing disputes. I had no reports and no budget.

Actions I took.

• Direction: I wrote a one-page brief: the problem (finance spent days reconciling usage by hand), the outcome (customers and finance see the same numbers), what was in version one, and what was not. I reviewed it with each group separately, then together.
• Alignment: I asked each group what they could not live without. Finance needed daily totals matching invoices; product needed a customer-facing view; platform needed no new load on their primary database. I found one shared measure, "report total equals invoice total for the same period", and made it the test everyone could check.
• Decision rights (who is allowed to make which call): product owned scope, platform owned data access, and I owned the schedule. We wrote that on the brief so disagreements had a place to go.
• Trade-offs I accepted: we shipped daily totals instead of real-time (platform's load limit), skipped the self-serve export (product's cut), and finance accepted a one-day lag. I told each group what it was giving up and why before the review. To finance I said roughly: "Real-time totals would put load on the primary database, which platform will not allow. What I can give you is a daily total that matches your invoices to the cent, one day behind. Can the monthly reconciliation work with that?" Finance agreed once the invoice-match check was part of the brief.

Result. We shipped in three two-week sprints (6 weeks) against an initial guess of 8, and finance used the report for the monthly reconciliation. The invoice-match check passed for every customer in the first month's run. A follow-up export came back as a separate request.

Worked example: how I knew it worked

The agreed measure was concrete: report total minus invoice total for each customer and period. Anything non-zero was a defect, listed and reviewed weekly. That turned "is it good" into a countable list.

What I would do differently, and pitfalls

• I would have brought finance in at the start of the brief, not the second week; their first reaction would have saved a rewrite.
• Do not tell a story where you "aligned everyone" with no cost. Interviewers listen for what you gave up.
• Stay specific about your actions ("I wrote", "I asked"), and say "we" only for the team result.