Advocacy and Constructive Dissent Questions

Direct answer

Disagreeing with the chief technology officer (CTO) in front of the board is a credibility test as much as a technical one, so the pitch has to be built entirely on business framing, not architecture preference, and has to be honest about where the CTO's concerns are legitimate, not just where mine are.

10-minute pitch outline

1. Business case and customer impact (1.5 minutes): the specific customer or revenue problem multi-region deployment (running the service from more than one geographic data center) solves, for example latency for a named growing customer segment, or a contractual data-residency requirement we currently can't meet, stated as a concrete named gap, not a general "it would be better."
2. Cost estimates and return on investment (ROI, the value returned relative to what's spent) (2 minutes): the infrastructure and engineering cost of the build, compared honestly against the cost of the status quo, for example lost or at-risk revenue from the customers the current single-region setup can't serve, so the board sees both sides of the ledger, not just the ask.
3. Performance and latency improvements (1.5 minutes): the expected latency improvement for the affected customer segment, framed relative to a stated current baseline, and explicit that this benefits a specific segment, not uniformly all customers.
4. Security and compliance implications (1.5 minutes): both the benefit (meeting a data-residency requirement) and the new risk (a larger attack surface and more complex access control across regions), addressed together so it doesn't look like I'm hiding the downside.
5. Rollout phases and timelines (2 minutes): the end state I am asking the board to endorse in principle is three regions, the one we run today plus two, sized to the customer segment and the residency requirement named in step 1. What I am asking them to fund today is phase one only: one additional region serving that segment, with an explicit go/no-go checkpoint before either of the remaining two is started, rather than a single big-bang cutover or an open-ended commitment to all three.
6. Recommendation with fallback options and risks (1.5 minutes): my recommendation stated plainly, alongside the CTO's stated concern acknowledged by name, plus the fallback if the pilot region underperforms: we stop at two regions total, the one we have plus the pilot, and close the remaining latency gap for the rest of the segment with read replicas and edge caching instead of continuing to the three-region end state. Naming the stopping point inside the pitch is what makes the ask reversible, and a reversible ask is an easier yes than a cheaper one.

Where I agree with the CTO, stated explicitly in the pitch

If the CTO's concern is operational complexity or cost risk, and it usually is, I state that concern accurately to the board myself before the CTO has to, which signals I'm arguing from the strongest form of their objection, not a straw version of it, and I address it directly with the phased, checkpointed rollout rather than dismissing it. This is folded into items 4 and 6 rather than given its own slot, because a 10-minute budget has no spare minute in it and a separate "here is what the CTO thinks" segment would read as ceremony rather than as agreement.

Worked example

In a comparable pitch, the CTO's stated concern was operational overhead: doubling the on-call and deployment surface. I addressed it directly in the pitch by proposing the phased single-region pilot with an explicit go/no-go gate at three months tied to the on-call load actually observed, not projected, which gave the CTO a concrete off-ramp if the operational cost proved too high, and the board approved the pilot phase with that gate attached. The three-region end state stayed in the pitch as the direction, not as an approval I was asking for that day, which mattered: if I had only ever described one extra region, stopping at one would have been the plan rather than a fallback, and the board would have had nothing to decide at the gate.

Trade-offs and pitfalls

Overselling the benefit to win the board vote in the room risks a credibility cost later if the pilot underdelivers, so I keep the stated latency and revenue numbers conservative and tied to the specific customer segment rather than extrapolated company-wide. I also avoid any framing that positions this as "the CTO is wrong"; the honest framing is two people who weigh a real trade-off differently, and the board's job is to pick a risk level, not referee a personality conflict. The related pitfall is presenting a fallback that is identical to the plan: if the phased rollout starts at one extra region and the fallback is also one extra region, the board has been handed a choice with one option in it, and the first person to notice stops trusting the rest of the pitch.

Bottom line: lead by naming the burden you're creating for on-call engineers explicitly, then bring a concrete "here's what we're taking off your plate" package before you ask for buy-in, rather than presenting the cost savings and hoping the operational cost gets waved through.

Building empathy into the advocacy:

• Acknowledge the real cost first, specifically (more paging surface, a less familiar failure mode), not a generic "we know this adds complexity."
• Runbooks: a step-by-step guide for the top failure modes, written or reviewed by the Site Reliability Engineers (SREs) who'll actually use it at 2am, not handed to them finished.
• Automation: auto-remediation for the most common failure, and alerting tuned specifically so it doesn't add noise to an already busy on-call rotation.
• Training: a walkthrough or game-day exercise before go-live, so the first time an engineer sees this failure mode isn't during a live incident.
• Staged rollout: start with the lowest-traffic service, with an SRE embedded in the design review from the start, not brought in after the architecture is finalized.

Presentation order: show the compensating plan to the SREs privately first and incorporate their input, then present to engineering managers jointly with the SRE feedback already folded in. A plan the SREs helped write lands very differently than one presented to them as a fait accompli.

Worked example: proposing a move from a managed queue service to a self-hosted one to cut cost. The compensating package: two runbooks for the two most likely failure modes, an auto-restart script for the most common one, a week of shadowing the current on-call rotation before cutover (the point where live traffic actually switches from the old system to the new one), which is how the proposing team learns what load it is about to add rather than how the SREs learn the new system, plus the part that actually discharges the training commitment: a game day on the self-hosted queue itself in staging, where we induce the two failure modes the runbooks cover and the on-call engineers work them with the runbook in hand while someone watches which steps are wrong. Shadowing the rotation they already run teaches them nothing about the system being introduced, so without the game day the training leg of the package is empty. The package closes with a rollback plan tested in staging. The SREs flag during review that the auto-restart script needs a rate limit to avoid masking a real problem, and that gets added before the proposal goes to the engineering managers.

Trade-offs and pitfalls: the runbooks, automation, and training all cost real engineering time, so the net savings after that investment is smaller than the headline number, say so plainly. If the SRE feedback reveals the plan genuinely doesn't cover their real risk, be willing to shrink the scope (fewer services migrated at first) rather than pushing the original plan through anyway. Watch for the version of this package where the training line is shadowing, a walkthrough deck or a recorded demo: none of those put an engineer in front of the new system's failure mode before an incident does, which was the whole point, and SREs read a training plan that does not involve the new system failing as a plan written to be listed rather than used.

Direct answer

Once you are overruled, the job shifts from winning the argument to minimizing the damage if you turn out to be right, and making sure that if you were right, it surfaces on a schedule you control rather than by accident during an incident.

Immediate actions

Document the decision, your specific concern, and the alternative you proposed, in a neutral "for the record" tone rather than an "I told you so" one, so there is a clean trail without it reading as a grudge. Look for the cheapest mitigations you can add without relitigating the decision itself, for example an internal API boundary that keeps a future change cheaper, or a cost alarm that gives early warning. Align explicitly with the decision-maker on what "long-term cost" actually means in this case, so you are both watching the same signal later rather than arguing about definitions after the fact.

Six to twelve month plan

Instrument the specific cost signal you were originally worried about, whether that is infrastructure spend trend or engineering hours going into workarounds, and report it on a fixed cadence. Agree jointly with the decision-maker on a small number of KPIs (Key Performance Indicators, the specific quantities you will track over time to tell whether things are getting better or worse) and, separately, on the threshold value for each one that would trigger reopening the conversation. Keeping those two things separate matters: the KPI is the measurement, the threshold is the line you both agree in advance counts as bad enough to act on.

Pick the threshold values from something outside the argument rather than from your own forecast, or the checkpoint will read as a number you reverse-engineered to be crossed. The usable anchors are the status quo (the trend line as it stood before the decision), the number the decision was justified on (if the case for the chosen path assumed cost growth would stay flat, flat is the threshold), and the point at which the cost exceeds what the alternative would have cost to build. Write down which anchor each threshold came from.

Keep investing genuinely in the chosen path so the team is not quietly rooting for it to fail, since that is the "commit" half of disagree and commit (the principle of voicing your objection once, then fully supporting whatever the team decides), not just the "disagree" half. Schedule a formal checkpoint at a fixed future date regardless of how the trend looks by then.

Worked example

I was overruled on a proposal to modularize a service, with leadership choosing to keep it as a single deployable for cost and schedule reasons. I wrote a short, neutral decision record capturing the trade-off and my cost projection so it would not be relitigated from memory later. I also added a lightweight internal boundary at the module level anyway, a small effort that did not change the decision but made a future split cheaper if the risk materialized. I proposed, and got agreement on, two jointly-owned KPIs: infrastructure cost growth rate and time-to-ship for new features. The thresholds came from the case for the decision itself rather than from my forecast, since leadership had argued the single deployable would hold delivery speed steady, so "time-to-ship materially worse than the pre-decision baseline" was a line they had effectively already endorsed. We set a nine-month checkpoint. At that checkpoint, time-to-ship had degraded noticeably as new features kept stacking into the same deployable, matching the original concern. I brought the pre-agreed KPI, not a new argument, to reopen the conversation, and the team funded a phased modularization, helped in part by the boundary work already in place from go-live.

Trade-offs and pitfalls

Quietly under-investing in the chosen path, hoping to be proven right later, reads as sabotage even when it is not intended that way, and it damages trust permanently once noticed. Picking KPIs that are really just a restatement of what you originally wanted to be true, rather than negotiating them jointly with the decision-maker, turns the checkpoint into private ammunition instead of a shared, credible trigger. The same applies to the thresholds: a line drawn from your own projection is your argument wearing a number, while a line drawn from the case the decision was approved on is something the decision-maker has already agreed to.

Direct answer

Influence here comes from making staying expensive and visible while making leaving cheap and supported, not from asserting that the legacy system is bad; most teams keep using it because leaving looks harder and riskier than staying, so the plan has to change that calculation.

Plan to influence stakeholders

• Quantify the cost of keeping the system in terms stakeholders already track: recurring on-call load, a backlog of unpatched security issues, engineer-hours per quarter spent working around its limitations, and the infrastructure cost of running it alongside newer alternatives.
• Map every dependent concretely: which teams call it and what they actually use, since it is common for a dependency to use only a small slice of a legacy system's functionality rather than the whole thing. Do this before proposing any migration path, because the audit routinely finds callers who need no migration at all, only a deletion, and those are the cheapest teams to move and the best early proof that the plan is not a tax on everyone.
• Offer more than one migration path, since dependents rarely have identical needs: some may need nothing but to remove a call they no longer use, some may only need a thin compatibility shim, others a genuine rewrite of their integration, phased with a clear cutover date and a read-only window before hard shutoff.
• Provide real incentives and support for migrating teams: dedicated migration help, a shared library, or even doing the first pull request for them, tied to something the migrating team already wants (a performance or reliability improvement), not framed as a favor to the requester.
• Mitigate risk with a parallel-run period comparing old and new behavior before cutover, a rollback plan per team, and a hard deadline backed by a leadership sponsor so the migration does not slip indefinitely.

Worked example

A legacy internal authentication service had three dependent teams, each using it for a different reason: one for single sign-on, one for legacy API key validation, and one that no longer actually needed it but had never removed the call. The cost case: an overdue security patch, a handful of on-call pages per quarter tied to it, and a real chunk of an engineer's time each quarter spent keeping it alive.

I proposed a different path per dependent rather than one plan for all three. The single sign-on team got a one-line swap to the supported identity library, which I wrote and opened as a pull request on their repository so their cost was a code review rather than a project. The team on legacy API key validation had no equivalent in the new system, so they got a small compatibility shim that kept their call signature intact, plus a parallel run of old and new for a defined window to catch behavioral drift, since that was the trickiest of the three. The third team needed no migration at all: the audit showed the call was dead, so their work was deleting it, which took an afternoon and gave the effort its first completed dependent within the first week. I funded the shared library as a small dedicated project maintained by my own team, and secured an org-level sponsor to set a firm shutoff date six months out.

Trade-offs and pitfalls

Proposing one big-bang migration date for every dependent, when their needs and urgency differ, usually stalls the whole effort because the slowest team blocks everyone else. Assuming every caller needs a real migration is the same mistake in miniature: it inflates the apparent size of the effort, which makes it easier for a sponsor to defer, and it wastes the credibility you get from an early, genuinely finished dependent. Framing the case as "this is old and I don't like it," rather than the concrete cost and risk, reads as taste rather than a business case and rarely moves anyone with competing priorities.

Direct answer

Lead with the decision you need and its business impact in the first sentence, then put everything else, including a written TL;DR (a too-long-didn't-read summary of one short paragraph) and a fuller appendix, into follow-up material the leader can ignore unless they choose to dig in.

Structured elaboration

Include in the live pitch: the one-line ask, the business consequence in terms the leader already tracks, revenue, risk, timeline, customer impact, and the specific decision or resource you need from them. Exclude from the live pitch: methodology, model or system internals, alternative approaches you already ruled out, anything answering a question they haven't asked. Prepare a short written follow-up as backup, a TL;DR paragraph plus an appendix with the reasoning, data, and technical detail, so if they want more, or want to forward it to someone who does, it's ready without another meeting. Anticipate the one or two questions this kind of audience usually asks, typically "how sure are we" and "what does it cost to wait", and have those answers ready verbally even though they're not in the opening pitch.

Worked example

I needed a vice president to approve a two-week launch delay because of a security gap in how customer payment data was being logged. My opening line was: "I need a two-week delay on the launch. Here's why: we found a log line that captures full card numbers in plaintext. That's a compliance and breach-risk issue, not a nice-to-have fix." I left out the specific logging framework, the code diff, and the alternatives I'd already ruled out. Afterward I handed over a one-page follow-up with a TL;DR at the top and a technical appendix below it, for the security and engineering leads who did want the specifics. The vice president approved the delay in the room based on the opening framing alone, and later used the follow-up document to answer their own leadership's questions without needing me present.

Trade-offs and pitfalls

Cutting too much can read as hiding uncertainty; if you genuinely don't know something the leader would care about, like your confidence level, say so briefly rather than omit it entirely. Don't let the follow-up document become the only place the real substance lives, since a leader can approve based on the opening pitch alone and never open the appendix.