Cross-Functional Leadership and Collaboration Questions

Direct answer

An executive sponsor is the senior leader who backs a program: they say publicly that it matters, settle disputes above the team leads' level, and protect its resources. Lukewarm sponsorship (agreeing in principle but doing little) is a risk I treat as a deliverable: I turn "supportive in principle" into three specific, small, visible acts by the sponsor, make the ask small enough to be easy, and keep the sponsor's time for decisions only they can make. The tool for not over-escalating is a rule that every request to the sponsor arrives with a recommendation and has been through lower levels first.

Securing real sponsorship

1. Find out what they care about. In a first conversation, ask what success and failure look like for them in the next 12 months and what would make them regret backing this. Tie the program's outcome to their goal. Sample wording: "What would you want to be true in 12 months for this to have been worth your name on it? And what would make you regret backing it? I want to shape the program around that, and I will keep asking for your time to a small, fixed amount."
2. Make the ask concrete. Three requests:
   • State the program's priority publicly to the teams at kickoff and in one later all-hands (a meeting of the whole organization).
   • Act as final decision-maker in the decision-rights charter (a one-page document listing which decisions each person or level makes, so no one has to guess), with a stated response time.
   • Make the participating teams' commitments appear in their own goals (such as their OKRs: objectives and key results, the quarterly goal format), so the work is not extra.
3. Keep the burden small. A 30-minute monthly check-in (12 sessions = 6 hours) and a 60-minute quarterly steering review (a recurring meeting where the sponsor and team directors review progress and make the decisions only they can; 4 sessions = 4 hours): about 10 hours of sponsor time across the 12 months, which is an honest, visible cost.

The ask itself, in words: "I am asking for three things. One, a few minutes at kickoff saying this is a priority. Two, that you are the final decision-maker when the leads cannot agree, and that you answer within 3 working days. Three, that each team's share of the work appears in its own quarterly goals. Everything else I will handle. The only standing time I need is a 30-minute check-in each month and a 60-minute steering review each quarter, about 10 hours across the year." An excerpt of the charter this points to (illustrative):

Using them without over-escalating

• Escalate only through the agreed ladder, and only decisions that have timed out below.
• Bring a one-page brief: decision, options, recommendation, deadline.
• Maintain a visible tally of "asks made, decisions delivered" so the sponsor sees low drama and high return.
• Share good news with them regularly. Sponsors become advocates when they are told things are working, not only called when they are on fire.

Worked example (illustrative)

In month 2, a team lead declines to commit two engineers, saying their director has not asked. Under the charter this swap is the director's decision with a 2-working-day response time, so the program lead first asks the director directly with the same one-page brief. Two working days pass with no answer, so the decision has timed out below. Only then does the program lead go to the sponsor, not to complain in general but with a note: "Decision needed by Friday: Team X's two engineers for Q2. Option A: commit now, and the milestone holds. Option B: defer, and it moves by about six weeks. I recommend A." The sponsor replies in a line to the director. The ask cost one message, came only after the lower level timed out, and could be traced to a milestone.

What would change my call

If after two clear asks the sponsor still will not act, I report it as program risk with a date impact, and I scope the program to what can succeed without their backing, instead of pretending the sponsorship exists.

Pitfalls

• Asking for "support" with no specifics.
• Surprising the sponsor with bad news in a public forum.
• Using the sponsor as the first response to friction; they become a bottleneck and you become the person who cannot solve things.

Direct answer

A blocked decision moves up one level when it has gone unresolved for a fixed time, not when someone gets frustrated. Each level gets a short, published timebox (a fixed amount of time after which the decision must move up). Executives are pulled in when the decision is beyond delegated authority, would move a committed date, or the lower levels have run out of time. The rules are agreed at kickoff, so escalating is routine and not an accusation.

Escalation ladder (illustrative timeboxes in business days)

Maximum time from block to decision: 2 + 2 + 3 + 2 = 9 business days.

Triggers

• Unresolved past its timebox.
• Critical-path impact: the delay would move a program milestone by a week or more, measured against that milestone's remaining float (spare time). A milestone with more float than the ladder's 9-business-day maximum does not trigger this early. (The critical path is the chain of dependent tasks that sets the earliest finish date, so any slip on it slips the whole program.)
• Needs money, headcount or policy outside the level's authority.
• Any one-way-door decision (one that is hard or costly to reverse, such as signing a multi-year vendor contract or publishing an external API), which goes to Level 2 immediately.

Pulling executives in early

Skip levels when the block threatens a committed external date, or when two directors have already said they cannot agree. Always escalate with a one-page brief: the decision, the two options, the cost of each, the recommendation, and the date by which a decision is needed. Filled in for the example below:

• Decision: how Payments gets event streaming for the Q3 launch.
• Option A: adopt a managed streaming service (a hosted product run by a vendor): 4 weeks to adopt, higher monthly bill.
• Option B: extend the platform team's in-house queue (a messaging system we build and run ourselves): 10 weeks, cheaper to run.
• Recommendation: A, because the 6-week difference moves the customer launch; fund a follow-up to improve the in-house queue.
• Needed by: Day 9 of the block, or the launch date moves.

Worked example: blocked platform decision

Payments wants a managed streaming service (a hosted product run by a vendor; 4 weeks to adopt). The platform team wants to extend its in-house queue (a messaging system the company builds and runs itself; 10 weeks, cheaper to run). Day 0: block raised. Day 2: the engineers cannot agree. Day 4: the leads' session also ends split. Day 7: directors agree on the criteria but not the answer. Day 9: the sponsor decides for the managed service because the 6-week difference moves a customer launch; the in-house team gets a funded follow-up to improve the queue. The decision record states the reasons so the losing side can see them. Why this case used the full ladder and did not skip levels: adopting the managed service on a month-to-month plan can be undone by going back to the in-house queue, so it is a two-way door, and the customer launch date was a plan, not yet promised to the customer in writing, so the skip-level rule for committed external dates did not apply. In the same way, the Q3 launch had float for the 9-day maximum wait, so the critical-path trigger did not fire early; only the choice of the slower option (10 weeks against 4) would have moved the launch. Had Payments been signing a multi-year contract, or had the date been promised in writing, the block would have gone straight to Level 2 on day 0.

Incident-blocks-roadmap ladder

Incident work and roadmap work compete, so a separate ladder applies. Severity is the label for how serious an incident is. Severity 1 (customer-facing outage, for example payments failing for everyone) preempts planned work, meaning it takes over the team's time immediately, automatically and with a 15-minute response; Severity 2 (a major feature degraded for some customers) gets a response within 1 hour and preempts at the team's judgment; Severity 3 and lower (minor or cosmetic issues with a workaround) go to the backlog and are ranked weekly against the roadmap by product and engineering leads. If incident work displaces planned work for more than 5 working days, the program lead re-plans and tells the sponsor. These numbers are illustrative; set them from your own on-call practice.

Pitfalls

• Ladders without timeboxes are just waiting lists.
• Escalating without a recommendation hands executives homework.
• Always tell the lower-level owners the outcome and the reasoning.

Direct answer

For a program across five teams (engineering, legal, security and product, none reporting to me), the first two weeks must produce a shared outcome and scope, named owners with decision rights (who gets the final word on which decision), a dependency map with dates, and an agreed escalation path. I would put the people who can commit their team's time in the kickoff, and keep the follow-up working group (the smaller group that meets regularly to do the work) from becoming a status meeting by making it a decisions-and-blockers meeting with a fixed agenda.

What must be agreed by the end of week two

1. Outcome and success measure in one sentence the sponsor signs.
2. Scope boundary: what is in, what is explicitly out.
3. One accountable owner per deliverable, and a named decider per open decision (a short RACI table: Responsible, Accountable, Consulted, Informed, with exactly one Accountable per row).
4. Dependencies with dates and owners, including what legal and security must review and how long they need.
5. Escalation path: what slips or disagreements go to whom, and after how many days. For example (illustrative): a missed date or a disagreement between two team leads is raised with me the same day; if it is still open after 3 working days it goes to the sponsor, who decides within 2 more working days.
6. Cadence and rules: when the group meets and what it is for.

Who must be in the room

• The sponsor, to say why this matters and to back the escalation path.
• One person per team who can commit that team's capacity and decide for it, not an observer. Legal and security should be there from the start, because their requirements change the plan.
• A note-taker and timekeeper (could be me with a delegate), so I can facilitate.

Facilitating the kickoff

Teams rarely volunteer their constraints in writing, so the plan breaks later when a hidden one appears. In the kickoff I ask each team, out loud and before any planning, two questions: what must you have from others, and what would stop you? Saying it in front of the sponsor turns a vague worry (for example, "security review usually takes a while") into a dated dependency with an owner (security review: 10 working days, starts when the design is frozen).

Worked kickoff agenda (90 minutes)

10 + 25 + 20 + 15 + 10 + 10 = 90.

Keep the working group from becoming a status meeting

A status meeting reports what already happened. The working group's weekly 45 minutes is for what needs a decision: 5 minutes on decisions needed since last week, 15 on blocked items, 15 on decisions made live, 10 reading back commitments (5 + 15 + 15 + 10 = 45). Status goes in a shared tracker read beforehand. If an item has no decision or blocker, it is not discussed. I end by reading the commitments back.

Pitfalls

• Inviting representatives who cannot decide forces a second meeting for every decision.
• A kickoff that ends without owners and dates feels productive and produces nothing.
• Too many attendees: if a team is not blocked or deciding, it can skip that week.

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

For a six-month (about 26-week) program spanning product, mobile, web, data engineering and legal, I would build one shared dependency map in the first two weeks, turn each dependency into a dated commitment owned by a named person, and agree in advance what happens when a date is missed. The point is that a miss is discovered and handled in days, not discovered at the milestone review.

Surface dependencies

A dependency is something one team needs from another before it can finish its own work.

1. Start with the outcome, work backwards. The outcome is "every product event is defined once, collected one way, and reaches the data pipeline with the right consent handling". Ask each team: what do you need from others to finish, and what do others need from you?
2. Run one 90-minute mapping session (all five teams, one board). Each team writes its deliverables on cards and draws arrows to what it needs. Legal's cards matter early: consent and retention rules shape the event schema that everyone else builds.
3. Mark the critical path: the chain of dependencies that sets the earliest possible end date. Mobile releases ship through app-store review on a release train (a fixed release schedule). If the mobile train leaves every two weeks, missing the cut-off by one day costs 14 days, so mobile dependencies get the earliest dates.

Get real commitments

• Ask for a date with an owner, not an estimate from a meeting. "By when can you give us X, and what would make that date wrong?" The second half surfaces assumptions.
• Give teams the date range first. A team commits to a window ("weeks 6 to 8"), then narrows once it has scoped the work. A single early date given under pressure is the one that gets missed.
• Write them in one tracker visible to all five teams and the sponsor. An illustrative row: Legal | personal-data field list | owner: A. Moreno | window: weeks 3 to 4, committed: week 4 | assumes privacy counsel is available.
• Check commitments against capacity: if data engineering is committed to three programs in the same weeks, ask its lead to rank them before accepting the date.

When a team misses

Agree this at kickoff, so it is a process and not an accusation:

• Day 0: the owner flags the slip to me as soon as they know. Early flags are rewarded.
• Within 2 working days: a 20-minute conversation about the cause and a new date. I check what the slip does to the critical path.
• Slip under 1 week with float (slack): absorb it and tell the downstream teams.
• Slip of 1 to 2 weeks with float: absorb it only if the float covers the whole slip, tell the downstream teams and the sponsor in the next two-week report, and treat a second slip from the same owner as a pattern to escalate.
• Slip that moves the critical path or exceeds 2 weeks: I take it to the owner's manager and the sponsor with options (cut scope, borrow capacity, move the end date).

Worked example (illustrative)

Legal's sign-off on which fields count as personal data is due in week 4. The data schema depends on it (weeks 5 to 7), then mobile and web instrument events (weeks 8 to 11), mobile must make the train that leaves in week 11. Legal says it will be one week late. The arithmetic: from the end of week 4 to the end of week 11 is 11 - 4 = 7 weeks, and the work needs schema 3 weeks (weeks 5 to 7) plus instrumentation 4 weeks (weeks 8 to 11), 3 + 4 = 7, so the float is 7 - 7 = 0. A one-week slip needs 8 weeks in a 7-week gap, so mobile misses the week-11 train, and the next train two weeks later costs 14 days. That is one week of delay becoming two on a path where mobile has no float, so the cheapest response is to let engineering begin the fields legal has already cleared, rather than moving the program end date.

Trade-offs and pitfalls

• Heavy tracking becomes its own tax; keep one tracker and one weekly 30-minute check.
• Escalating the first miss damages the relationship; escalate the pattern or the critical-path impact.
• A missed date from a team with no capacity is a planning problem, so fix it with prioritization and not with pressure.