Advocacy and Constructive Dissent Questions

Direct answer

When a product leader wants to bypass a security control to move faster and I believe the risk is unacceptable, my approach is to reframe the conversation from "security versus speed" to "which specific risk are we choosing to accept, and does anyone with the authority to accept it actually know that," because most of these conflicts resolve once the real decision is made explicit and assigned to the right owner.

Step-by-step approach

1. Get specific about the control and the risk: name exactly what protection is being bypassed and the concrete way it could be exploited, in terms a non-security stakeholder can picture, for example "this removes the check that stops one customer's account from reading another customer's data," not an abstract "it's a security risk."
2. Bring in the people whose job it is to own that risk: security (to confirm and quantify the exposure) and legal (to state any regulatory or contractual exposure, since some bypasses aren't just risky, they're a breach of a signed commitment). I do this early, not after I've already lost the argument alone.
3. Propose an alternative minimum viable product (MVP, the smallest version of the feature that still delivers value) that gets most of the speed benefit without the bypass, for example gating the feature behind an internal or beta-only flag while the proper control is built, rather than presenting "ship as-is" and "don't ship" as the only two options.
4. If the product leader still wants to proceed, I state an explicit escalation threshold in advance: for example, "if this ships without the control, I will document the risk and escalate to the chief information security officer or engineering leadership before it goes to production," said directly to the product leader, not behind their back.
5. If it does escalate, I bring the same specific framing, the concrete exploit, the alternative that was offered and declined, and let the escalation-level owner make the final call, since at that point the decision genuinely isn't mine to make unilaterally either.

Worked example

A product leader wanted to ship a feature that skipped an authorization check for one endpoint to hit a launch date. I named the exact exposure (any authenticated user could query another user's records by changing an ID in the request), brought in a security engineer who confirmed and estimated the exposure, and proposed shipping to an internal beta list only until the check was added, which took three extra days. The product leader initially resisted, but agreed once legal confirmed the exposure would violate a specific clause in our largest customer's contract, a concrete cost that outweighed the three-day slip.

Trade-offs and pitfalls

Naming an escalation threshold upfront can read as a threat if delivered poorly, so I frame it as protecting both of us, "I want to make sure whoever can actually accept this risk knows about it," not "do this or I'm going over your head." I also make sure my proposed alternative MVP is genuinely faster than the full fix, not a thin disguise for "just don't ship," or I lose credibility the next time I raise a concern.

Direct answer

I'll draft the actual short message: acknowledge the real goal first, name the specific risk plainly, and offer a safe alternative with a measurable success criterion, addressed to both the customer and the internal product manager.

Structured elaboration

Acknowledge the real goal, faster onboarding, first so the response doesn't read as a flat no. Name the specific risk concretely, what bad input could get through and what it could cause, rather than a vague "security concern." Offer at least one safe alternative that recovers most of the speed benefit. State a measurable success criterion for the compromise so both sides agree on what "resolved" looks like.

Worked example

"Hi [customer] and [PM], thanks for flagging the onboarding friction, that's a real problem worth fixing. I want to flag a specific risk with removing server-side validation entirely: it's the only check that runs no matter which client submits the request, so removing it means a malformed or malicious payload, for example an oversized field that breaks downstream processing, or an unescaped input, could reach the database directly. Tightening the web form later doesn't close that, because the form isn't the only thing that calls this endpoint: our own mobile client, the partner integration, and frankly anyone with a terminal hit it directly, and none of them run the browser's checks. Instead of removing it, I'd propose two changes that should recover most of the speed you're after: first, relax the specific field-length rule that's causing the friction you described, since that one looks overly strict; second, move validation that isn't security- or integrity-critical to run asynchronously (in the background, after the user has already moved on) so the user isn't blocked waiting on it. Success criteria I'd suggest, with one gap to close first: we've never actually written down what "fast enough" means here, so tell me the number you're measuring against and I'll hold us to it rather than to one I picked. Then, over the following two weeks: median onboarding completion under that stated target; zero increase in records failing the checks that stay synchronous, which are the security and data-integrity ones; and, for the checks we move to the background, under 1 percent of new records getting flagged and corrected after the fact, with an alert if it goes above that. Worth being explicit about that last one rather than burying it, since it is the part you're actually being asked to accept: moving a check behind the write does mean some bad records land first and get cleaned up afterwards, and that is precisely why the security and integrity checks stay in front of the write and only the cosmetic ones move behind it. Happy to pair on the specific fields if that's useful."

Trade-offs and pitfalls

Don't let "we can't remove this" be the whole message, always pair it with something you can do, or it just reads as blocking. If the customer's real complaint turns out to be confusing error messages rather than actual validation speed, the fix might be far cheaper than either removing validation or making it asynchronous, so ask a clarifying question before assuming which problem you're solving.

Direct answer: Treat a chronic blocker as two separate problems: the immediate decision that needs to move, and the underlying credibility or trust gap that keeps producing the pattern. Solving only the first one means you'll be back here next quarter.

Short-term tactics to unblock a decision

• Diagnose whether the dissent is substantive or relational: is this person actually catching real risk repeatedly, or is this about not having been consulted early enough? The fix is different for each.
• If the diagnosis comes back substantive, the correct short-term move is to change the recommendation, not to route around the objection. Say plainly in the review that the objection landed, amend the decision record to name the alternative you are now taking and why, and credit the person by name in it. This is the branch most people skip. Every tactic below is for unblocking a decision you still believe is right after looking honestly at the objection, and running those tactics on an objection that is actually correct is how a team ships a known-bad design with a paper trail saying everyone agreed.
• Write a short architecture decision record, or ADR (a one-page document naming the recommendation, the alternatives considered, and the specific objection raised), and time-box the discussion to it. This stops the conversation from re-litigating the whole design every time and forces the objection to be concrete enough to evaluate.
• Narrow the disagreement to a specific, testable risk and de-risk just that piece (a small prototype or load test on the exact concern) rather than re-arguing the architecture in the abstract.
• If consensus genuinely can't be reached after that, escalate to a named accountable decision-maker with the ADR as the input, rather than letting the disagreement stall indefinitely.

Long-term strategies for the relationship, credibility, and influence

• Loop them in before the recommendation is drafted, not after, so their input shapes the proposal instead of arriving as an objection to something already decided.
• Find and publicly credit the times they were right. If a past objection prevented a real outage or cost overrun, say so; this is the single fastest way to convert "the person who always blocks things" into "the person who catches real risk," which changes how the whole team hears their input, including you.
• Deliberately incorporate their feedback on smaller, lower-stakes decisions first, so trust is built before you need it on something big.
• Understand what they're actually protecting (operational load, security exposure, an incident they lived through) and address that specific concern directly in future proposals instead of treating every objection as generic resistance.

Worked example: A staff engineer on a peer team, with no formal authority over your roadmap, keeps blocking a migration to a new message queue, citing operational risk. Short term: pull the specific failure mode they're worried about (say, message loss during a broker restart) into a scoped spike, and bring back a concrete answer instead of a general reassurance.

Say the spike finds the broker acknowledges a write before that write has been replicated to a second node, so a restart at the wrong moment really can drop an accepted message. That is the substantive branch: the objection is correct, so the recommendation changes. You amend the proposal to require acknowledgement only after replication, note the added write latency that costs, and record in the ADR that the change came from their objection.

Now take the other branch. Suppose the spike instead shows the failure mode is already covered, because the producer retries on a missing acknowledgement and consumers deduplicate on message ID, so a dropped acknowledgement costs a redelivery and not a lost message. That is the relational branch, and the objection does not survive contact with the specific test. You take that result back to the same review, time-boxed to the ADR, and ask for a decision on the amended document rather than reopening the whole design. Long term, in both branches: loop them into the next two infrastructure proposals at the design stage, and when their earlier concern about broker restarts turns out to matter for a different service, name that in front of the team.

Trade-offs and pitfalls: The failure mode on one side is letting one person become an informal veto over every architecture decision, which erodes the team's ability to move. The failure mode on the other side is steamrolling someone who has a legitimate, recurring concern that nobody is actually addressing. An ADR plus a named escalation path protects against both, because it makes the disagreement visible and time-boxed instead of personal and indefinite.

There is a third failure mode sitting between those two, and it is the one the substantive-versus-relational fork exists to catch: running the unblocking machinery without ever finishing the diagnosis, so the spike and the ADR become instruments for winning rather than for finding out who is right. The honest test is whether you can name, before the spike runs, the specific result that would make you change your own recommendation. If no such result exists, you are not de-risking, you are collecting evidence for a verdict you already reached, and a stakeholder who has watched you do that once will block harder next time and be correct to.

Direct answer

When a vice president (VP) uses organizational authority to force a technical direction that violates established architecture principles, my first move is not escalation, it's making the specific long-term risk concrete and written down, because most of these situations are won or lost on whether the risk was ever actually documented before the decision was locked in, not on who argued loudest.

Immediate actions

I document the specific architecture principle being violated and the concrete long-term risk it creates, in terms tied to a real consequence (for example, a specific future scaling limit, a security exposure, or a maintenance cost), not an abstract "this isn't how we do things." I raise it directly with the VP first, assuming they may not see the long-term cost the way the architecture team does, and I propose a scoped mitigation, for example isolating the violating piece behind a clear boundary so it doesn't spread the same pattern elsewhere, rather than only objecting.

How I escalate

If the direct conversation doesn't resolve it, I loop in peer architects first, both to sanity-check that I'm not overweighting my own preference and to make sure any escalation carries more than one voice. If the risk is significant and the VP is unmoved, I escalate to the chief technology officer (CTO) or an architecture or risk review council if one exists, framed around the documented risk, not around the VP personally, and I do this transparently, telling the VP I'm escalating and why, rather than going around them quietly.

Documentation I prepare

A short written record: the principle at stake, the specific technical risk and its likely trigger condition (for example, "this breaks down once we exceed roughly this transaction volume"), the alternative that was proposed, and the decision that was actually made and by whom. This exists regardless of outcome, both to inform whoever inherits the consequence later and to make clear the concern was raised through proper channels at the time, not manufactured in hindsight.

Long-term strategies to prevent repeat overrides

I push to get architecture principles formally tied to a lightweight review gate for decisions above a certain size or risk threshold, so a similar override next time requires an explicit, recorded exception rather than a unilateral call, which changes the default from "authority wins by default" to "authority can override, but has to do so visibly and on the record." I also invest in building a track record: each time a documented architecture risk turns out to be right, that evidence makes the next warning easier to act on, which is a genuinely slow strategy, but the credible one.

Managing political risk while doing this

I keep every step focused on the technical risk and never frame it as a challenge to the VP's authority, since a VP who feels personally challenged is far less likely to reverse course than one who feels a genuine risk was surfaced in good faith. I also accept that even with excellent documentation, the VP's call may stand. My job is to make sure the risk was seen and recorded, not to guarantee I win every disagreement with someone who has more organizational authority than I do.

Trade-offs and pitfalls

Escalating past a VP is a real relationship cost even when done well and even when I'm right, so I reserve it for risks I've concretely documented, not for every architecture disagreement, and I'm honest with myself about the difference between "I'd have done this differently" and "this creates a specific, serious, documented risk," since conflating the two is what erodes credibility for the next time I actually need to escalate.

Bottom line: map a short checklist directly to what each person on the committee actually measures success by, then run a live demo that shows a real failure mode being caught, not just a design diagram.

Checklist, mapped to the room:

Demo plan (roughly 20 minutes): two minutes stating the problem being solved; five minutes live, showing an actual attack attempt succeed against the old model and get blocked by the new one in a staging environment; five minutes comparing runtime overhead side by side; three minutes on the migration and rollout path; the rest for questions. Leave a one-page written version of the checklist table so anyone who missed the meeting can review it async.

Worked example: proposing OAuth2/OIDC-based service authentication instead of a legacy shared-secret model. OAuth 2.0 is the industry-standard framework for issuing short-lived, scoped access tokens; OpenID Connect is the identity layer built on top of it that carries who the caller is. Be precise about what the demo proves, because the obvious version of it proves less than the room will assume. A plain bearer token is replayable in exactly the way a shared secret is: whoever holds it is accepted. What the new model changes is the window and the scope, not replayability itself, so the demo has to show that and nothing more. Capture a credential from a service-to-service call in a staging environment where you terminate TLS at a proxy you control (say so out loud, since on the wire both credentials are protected and the realistic capture paths are a leaked log, a compromised sidecar or a misconfigured proxy, not passive sniffing). Replay the shared secret against the old model and show it still works, because a shared secret stays valid until someone rotates it, which in practice is rarely. Then replay the captured token against the new model twice: once after its lifetime has elapsed, where it fails, and once against a service it was not issued for, where the audience check rejects it. That is the honest claim, a credential that is useful for minutes to one service instead of indefinitely to everything. If the committee wants replay resistance rather than a shorter window, name the mechanism that actually provides it, mutual TLS or a sender-constrained token bound to the client's key, and demo that instead, because it is a materially bigger migration and they should choose it deliberately rather than believe it arrived for free with the token model.

Trade-offs and pitfalls: the specific overclaim to avoid in this demo is implying the new model defeats replay outright; a live token captured inside its validity window replays fine, and a committee member who knows that and hears you say otherwise will discount everything else you presented. Don't let the demo turn into a sales pitch, be explicit about what the new model does not cover (say the gap out loud rather than let someone find it later, which costs far more trust). Keep the demo narrow and rehearsed; a live demo that breaks in the room undermines the whole pitch faster than a slide would have.