Stakeholder Management and Cross-Functional Alignment Questions

Direct answer

I would name one framework and apply it to each call: DACI (Driver, Approver, Contributors, Informed). The Driver runs the decision, exactly one Approver makes it, Contributors are consulted before it, and Informed people are told after. The closely related RACI (Responsible, Accountable, Consulted, Informed) is better for who does the work than who decides, and the core rule is the same: one accountable person per decision. It usually breaks down when there are two approvers, when "consulted" quietly becomes veto, or when the chart is never updated.

Structured elaboration

For each key call, write one row, agree it in advance with everyone named, and publish it where the team works.

Notes: a gate such as legal is one Approver on a defined question; it is not a vote on everything. Contributors get a deadline to respond. Set a rule: no reply by the deadline means no objection.

Worked example

Pricing call: Monday the Driver circulates a one-page proposal, Thursday noon is the comment deadline, Friday the Approver decides and posts the decision and reasoning, and sales and customer success are informed the same day so they are not surprised by a customer.

Where it breaks down

• Two Approvers, or "the committee decides", so nothing is really decided.
• Consulted people who assume their input is a veto.
• No deadline for Contributors, so the decision stalls.
• The Informed group is forgotten and hears from a customer first.
• The chart is written once and never updated when scope or people change.
• The Approver is unavailable and no delegate is named.

Trade-offs and pitfalls

• A chart is a tool for conversation, not a shield. Agree it with the people in it.
• Over-formalising small decisions creates bureaucracy: apply it to the calls that matter.

Direct answer

A strong story shows three things: you understood the stakeholder's real goal, you made a specific decision using evidence about the constraint, and you delivered the "no" (or "not like that") in a way that kept the relationship and offered a path. Below is the shape, then an example story you can adapt. Use your own facts.

Structure of a strong answer (STAR: Situation, Task, Action, Result)

• Situation: who asked, what they asked for, and why it was urgent. One or two sentences.
• Task: what you were accountable for (protecting the product and the customer, while helping the stakeholder win).
• Action: how you decided (what you asked engineering, which options, which criteria) and how you communicated (format, order, wording, what you offered instead).
• Result: what happened to the stakeholder's goal and the system, plus what you learned. Keep results qualitative unless you can state real numbers.

Worked example (illustrative story skeleton)

Situation. The head of sales asked for a custom bulk-export feature within two weeks, because a large prospect wanted it before signing. Task. I owned the product roadmap and had to protect the core app while helping close the deal.

Action, decision. I asked engineering for sizing. The export would query the live production database, and a large customer's export could slow the app for everyone. We laid out three options: (1) build the full feature in two weeks (real risk to production); (2) have an engineer run a scripted export for this customer against a read-only copy of the database now, and build the proper feature next quarter; or (3) decline. I chose the scripted option using three criteria: does it meet the customer's actual need by their date, how large is the damage if it goes wrong, and can we undo it. The scripted export was contained and reversible.

Action, communication. I met the sales lead in person, not by message. I opened with their goal: "I want this deal to close." Then in plain terms: the full feature this fast could slow the product for every customer; here is what we can deliver by your date; here is what it will not do. I asked them to check that the scripted export satisfied the prospect's stated need, and wrote the agreement into a short follow-up note with the date for the real feature.

Result. The prospect accepted the interim export and the deal proceeded, there was no production incident, and the proper feature shipped the following quarter. The sales lead later brought me requests earlier, which was the relationship result I cared about.

Trade-offs and pitfalls

• Do not tell a story where you simply said no and were right. The senior signal is an alternative that served their goal.
• Avoid technical jargon with a non-technical stakeholder; translate "table locks" into "it could slow the app for everyone".
• Say how you decided, not just what. Interviewers listen for criteria such as blast radius (how much can break), reversibility, and cost of delay.
• If the story ended badly, that is fine if you show what you would change.

Direct answer

Bring both leadership teams one decision pack with measured demand, the real impact on the losing unit, a small set of options, mitigations, and a phased timeline with checkpoints, and pre-discuss it with each leader separately before a joint meeting. You are influencing senior leaders without formal authority over them, so you rely on shared data, a fair process, and something concrete for the unit that gives up capacity. If they cannot agree by a set date, the decision goes to the executive committee (the senior leadership group that settles cross-unit funding, or the shared executive above both units) as a two-option memo, and both units are told before it goes.

Throughout, "capacity units" means slices of the shared compute platform; picture one unit as one reserved server core, so 1,000 units is 1,000 cores (the numbers are illustrative). Utilization is the share of an allocation actually used, a floor is a guaranteed minimum, and a reserve is unallocated buffer kept for surprises.

What to bring (quantified trade-offs, mitigations, phased timeline)

1. Measured capacity and demand: current allocation, actual utilization, and what the requesting unit needs and why (the business outcome).
2. Impact on the giving unit: which services, what service-level objective (SLO: a target such as availability) they might miss, and what their real peak demand is.
3. Options: for example take it all from the giving unit, take part from unallocated reserve, or fund extra capacity.
4. Mitigations: move flexible batch work off-peak, guarantee a floor, add monitoring.
5. Phased timeline and rollback trigger: shift in steps, with a checkpoint before the next step, and a return date.
6. Decision rights and escalation path: who decides and by when.

Worked example (illustrative units)

The platform has 1,000 capacity units: unit A 400, unit B 400, shared reserve 200. A needs 250 more for the quarter. Taking all 250 from B cuts B from 400 to 150, a 62.5 percent cut, which is unacceptable. Better: 150 from B and 100 from the reserve. B goes from 400 to 250, a 37.5 percent cut (150 / 400). After the shift: A 650, B 250, reserve 100; 650 + 250 + 100 = 1,000. Suppose B's measured peak for its critical services is 230, so a guaranteed floor of 250 covers it. Phasing: weeks 1 to 4 move only the 100 from reserve; weeks 5 to 8 move the 150 from B only if A's ramp (its planned growth in usage) is on plan and B's critical services stay inside SLO (rollback trigger: if B's critical-service peak exceeds 240 units, 96 percent of its 250 floor, or B misses its availability SLO in any week, stop and return capacity); then hold; return capacity in week 14 (a quarter is 13 weeks, so week 14 is the first week of next quarter), with B first in line for the freed capacity next quarter.

A one-page decision pack, filled in (illustrative):

Ask: move 250 units to Unit A this quarter (13 weeks)
Why: A's launch in week 9 needs it
Measured: A uses 380 of 400 (95 percent); B uses 210 of 400, critical peak 230
Options: (1) 250 from B, B falls to 150 (62.5 percent cut)
         (2) 150 from B + 100 from reserve, B falls to 250 (recommended)
         (3) buy 250 extra units
Mitigations: B floor of 250, batch work moved off-peak
Timeline: weeks 1-4 reserve only; weeks 5-8 B's 150 if checks pass; back in week 14
Rollback trigger: B critical peak above 240 or an SLO miss
Decide by: two weeks before A's ramp, else executive committee

Escalation path

State it up front: leaders decide by a fixed date, chosen about two weeks before A's ramp. After that, the request goes to the executive committee, which decides shared funding across several products, with a joint memo giving both units' positions in their own words and your recommendation. Never escalate by surprise.

Trade-offs and pitfalls

• Framing it as A's need against B's loss makes it a fight. Framing it as one company outcome plus a fair, reversible process works better.
• Numbers should come from measured usage, not each unit's ask.
• What would change the plan: if B's cut would breach a customer commitment or SLO on critical services, buying extra capacity beats shifting it.

Direct answer

In plain terms: sales says deals are slipping because a competitor has a feature we lack, and engineering says building it fast would hurt quality. I would not decide in the first meeting. I would spend a few days learning how many deals really depend on this feature and what the smallest credible response is, then put five or six options on the table (including ones that are not building it), choose with the accountable leader, and tell both sides the reasoning together with the rules that keep this from becoming precedent. My default recommendation is a bounded slice that answers the specific reason deals are stalling, shipped behind a feature flag (an on/off switch in the product that lets you release to chosen customers first), with the full version scheduled and dated. That flips if the evidence shows most deals are not actually blocked by this feature.

Structured elaboration: what to learn first

• Sales: for each slipping deal, is the feature a written requirement from the buyer, or one talking point? What exactly did the competitor ship (a demo, a limited launch, or a mature product)? What does the buyer actually do with it?
• Engineering: best, likely, and worst-case estimates; which roadmap items get displaced (planned work that would be pushed back to make room); what "rushed" would break (tests, performance, security review).
• Product and support: would existing customers use it, or is it deal-specific?

Options on the table

The usual first moves are the thin slice, the workaround, and positioning; a full parity build (matching the competitor's whole feature, called parity) and doing nothing are the ends of the range, not the starting point.

Worked example (illustrative numbers)

Five deals, each worth roughly $120,000 in annual recurring revenue (ARR: the money a customer pays per year under a subscription), so $600,000 is said to be at risk. Investigation finds only two name the feature as a written requirement: 2 x $120,000 = $240,000 genuinely at stake, not $600,000. The full build is about 12 engineer-weeks (one engineer working full time for one week is one engineer-week), the slice about 4, so the slice is one third of the effort and covers the $240,000 that is actually at stake. The slice covers exactly what those two buyers wrote. I recommend the slice, released to those buyers first, plus a dated commitment for the full version next quarter and sales training on positioning for the other three.

Handling the side that loses

• Sales, if the slice is less than they wanted: tell them what they can promise, the dates, and that their evidence changed the decision. Review the result at 30 and 60 days with the actual deals.
• Engineering, if the slice still displaced work: name what was protected (scope bounded, cleanup time reserved, deferred item has a date).
• Set a rule so this is not precedent: competitive-response requests go through the same evidence checklist and the same accountable decider. A checklist could read: (1) the buyer's written requirement, quoted; (2) deal value and close date; (3) what the competitor actually shipped; (4) engineering range and what gets displaced; (5) whether existing customers would use it. A request that cannot fill in items 1 and 2 waits for the normal roadmap.

Trade-offs and pitfalls

• The slice can satisfy neither side. If the 30-day review shows the deals did not move, stop investing rather than escalate the build.
• Do not let urgency skip the learning step.

Direct answer

I would first find out whether the backend authentication limit is a hard constraint (something the identity system genuinely cannot do) or a limitation of how it was built today. Then I would get design and engineering to write down what the user needs from the flow and what the limit forces, compare options against agreed criteria, and decide with one named decider. I side with engineering when the limit is a genuine security or platform rule and no cheap way around it exists. I side with design when the limit is only a current implementation choice and the user cost is measurable.

Structured elaboration

1. Turn the opinion into facts. Ask engineering exactly what the auth limit is. Example: the sign-in confirmation must happen on the identity provider's own page (the identity provider is the service that verifies who you are and holds your login, like a "Sign in with" page), which cannot appear inline in our page. That page is served from the provider's own web address and refuses to display inside another site's page (that is, inside a frame embedded in our layout), so that attackers cannot build look-alike sign-in screens. It can only open as a full-page redirect or in a separate pop-up window layered over our page; so the "modal" engineering asks for means that pop-up window, not the provider's page embedded in our own modal box. The "backend authentication limit" is this rule inside the server-side login system. Ask design what user problem the inline flow solves: for example, users lose their place and abandon the task when the page changes.
2. Agree the criteria first: task completion, how often users meet this flow, cost and time to remove the constraint, security risk, and how easy the choice is to reverse.
3. Widen the options. Modal, inline, or a hybrid: inline form with the authentication step in a modal that returns to the same saved state.
4. Test cheaply. A clickable prototype of both, shown to five or so users, tells you more than an argument.
   Scoring the options against the criteria (qualitative, illustrative):

The hybrid wins on task completion, the criterion that matters most here, and its extra cost is bounded and reversible.

5. Decide and record who decided, what criteria decided it, and what would make you reopen it.

Worked example

A customer edits their payout bank details. Design wants an inline form so nothing interrupts the task. Engineering says the extra sign-in confirmation needs a hosted page that cannot be embedded. Options: (a) a modal-style flow that moves the whole form into the pop-up, (b) redirect and lose the form, (c) hybrid: inline form saved as a draft, confirmation in the provider's pop-up window (the modal), and the user returns to the completed form. Choice: (c), because the security step is non-negotiable (engineering wins on that step) while the draft-saving fixes design's real problem of lost context (design wins on the rest).

Trade-offs and pitfalls

• Do not let it become a taste contest: decide by user impact and cost.
• Do not overrule engineering on a real security constraint just to preserve a design ideal.
• Do not accept "it is not possible" without asking what exactly is impossible.