Technical Leadership and Influence Questions

Direct answer

When priorities shift out from under a strategy, the discipline is re-scoring the backlog against the new constraint explicitly, not silently reprioritizing by gut feel, and being willing to say which committed work is paused, not just which new work is added.

Structured elaboration

• Get the new hard constraint stated precisely, in writing, from whoever owns it (legal, a regulator, an acquirer). "Compliance" and "explainability" mean different specific things to different people, and building against a vague version of the requirement wastes the pivot.
• Re-score every active and planned initiative against a small, explicit, written set of criteria weighted toward the new constraint (regulatory impact, reach, effort, and confidence in the estimate, adapted to the moment). The same test works whether the forcing constraint is a regulator, an acquirer, or a hard performance target like sustaining 10x throughput under a fixed budget. Writing the score down is what makes the "what got abandoned" conversation defensible later, rather than looking political.
• The same re-scoring discipline applies even when the shift is internal rather than external: three stakeholders each request a different initiative for the same cycle and there is capacity for only one; an explicit-criteria comparison is what makes that choice defensible instead of a popularity contest.
• Sequence the response across time horizons instead of one big-bang change: an immediate 0-3 month slice covering the non-negotiable, hard-deadline work; a 3-12 month slice building the durable capability (real data lineage and access control, not a one-off report); and a 12-36 month slice for restoring the paused strategic work once the mandatory floor is met.
• Get explicit sign-off from whoever controls funding and headcount (finance, a CTO, or equivalent) on the reprioritization itself, not just on the technical plan. Reallocating people away from committed roadmap items is a resourcing decision, not only a technical one.
• Keep a visible "paused, not cancelled" list. Initiatives dropped for the mandatory work need an owner and a resume trigger, or they quietly become permanently cancelled without anyone deciding that on purpose.

Worked example

A company gets acquired and a new regulator-driven requirement (data retention and explainability of reporting) becomes non-negotiable, on top of an existing roadmap built entirely around growth-facing dashboards. Rather than absorbing the new work as one more backlog item, you convene the people who actually own the requirement, translate it into concrete deliverables (an auditable reporting view, retention automation, documented data lineage), and re-score the backlog against a deadline-driven weighting, pausing lower-urgency growth experiments explicitly rather than letting them slip silently. You phase the response: the auditable view and retention work ship first because they carry the hard deadline; lineage and access-control work that makes future audits cheaper follows once the deadline is met; the paused growth analytics work gets a resume date once the mandatory floor is in place, coming back with a smaller footprint that reuses automation built for compliance rather than restarting from the original scope. Getting explicit funding sign-off matters here specifically because analysts had to move off committed growth work, and that is a resourcing call that needs to be made on purpose, not absorbed silently.

Trade-offs and pitfalls

The main failure is treating a hard external deadline as just another high-priority ticket instead of restructuring the whole plan around it, which produces a roadmap that stays busy but still misses the deadline. The second is never explicitly un-pausing the deferred work: once a strategic initiative is quietly shelved for a mandatory one, it tends to stay shelved unless someone owns bringing it back. The third is picking the requirement's minimum literal interpretation to move fast and then having to redo the work once the fuller requirement is clarified; it is usually cheaper to over-clarify scope with the requirement's owner up front than to guess and rebuild.

Direct answer

Without formal authority, the lever is technical credibility built through artifacts other people can independently check: a written proposal grounded in real data, a working prototype, and a track record of small delivered wins, not persuasion technique. Leading through influence differs from direct management in exactly this: you cannot assign the work, so every step has to make it easier for someone else to say yes than to say no.

Structured elaboration

• Diagnose before proposing. Collect the evidence (incident data, latency trends, where teams keep colliding) before writing anything. An undiagnosed proposal reads as an opinion; an evidence-backed one reads as a finding.
• Write it down concretely. A short design document with a specific problem statement, two or three named milestones, and a measurable success criterion for each (a target latency or error-rate range, not a vague goal) lets someone evaluate the idea without trusting your judgment on faith.
• Build the smallest thing that proves the idea, not the whole thing. A scoped prototype against a single team's workload is cheap to say yes to and gives you a concrete result to point at instead of a projection.
• Pull in the people who would implement or be affected, deliberately. A proposal with co-authors from outside your own team is harder to dismiss as one person's pet project. This is also the mechanism that keeps direction from becoming siloed inside your own team's worldview: without deliberately involving adjacent teams, "technical direction" quietly becomes "what my team already wanted to build."
• Keep it visible. Regular short updates and a shared tracker mean momentum does not depend on you personally chasing people down.

Worked example

A platform initiative is expected to eventually support on the order of a million users, and teams currently ship changes ad hoc with no shared plan. As an individual contributor, you spend several weeks pulling incident and latency data into a few named failure themes, then write a short design proposal with milestones for an observability baseline, a prototype for the highest-risk theme, and a backward-compatible rollout, each with an explicit success measure. You pilot the riskiest piece with one team first, because a single team's result is concrete evidence rather than a projection, then bring that data back to the wider group before asking anyone else to adopt it. The honest result of this kind of effort is usually partial: some teams adopt the pattern quickly because the pilot removed their specific pain, others wait for a second team to prove it first, and the plan itself gets revised once a stakeholder objects to a milestone you had not stress-tested. That is expected, not a failure of the approach; the goal was to make the direction adoptable, not to force it.

Trade-offs and pitfalls

The dependency on artifacts cuts both ways: a proposal or prototype that turns out to be wrong is now visible and attributable to you in a way a vague opinion never was, which is uncomfortable but is also what makes the influence real. The bigger failure mode is over-investing in the write-up and under-investing in the pilot: a well-argued document with no working proof is easy to admire and easy to ignore. Influence exercised entirely within your own team's technical culture is the other common trap: it produces direction that only makes sense to your team, which is exactly the siloing this approach is meant to avoid.

Direct answer

I design this as a federated model: a small central group owns cross-cutting guardrails and a short published list of guiding principles, teams own day-to-day decisions inside those guardrails, and a lightweight decision registry says up front, per type of decision, who has to sign off so nobody has to guess or default to "loop in everyone." I keep it from becoming bureaucracy by making the default path fast (most decisions clear automated checks with no meeting) and reserving actual human review for the decisions that are genuinely novel or high-risk.

The structure

• A small central group (five to seven people) sets platform-wide guardrails: reliability standards, core shared tooling, and incident response expectations. It doesn't approve individual team decisions; it sets the boundaries those decisions have to stay inside.
• A rotating review group (drawn from the teams themselves, not permanent gatekeepers) reviews the decisions that fall outside the automated guardrails: genuinely novel architecture, high blast-radius changes, anything crossing a regulatory or compliance boundary.
• Teams decide everything else themselves: their own service-level trade-offs, rollout pacing, runtime tuning, and day-to-day technical calls, as long as they stay inside the published guardrails.

flowchart TD
  C[Change request] --> D{In decision registry?}
  D -- Yes, routine --> G["Automated guardrail check"]
  G -- Pass --> M[Merge and canary rollout]
  G -- Fail --> X[Blocked, revise]
  D -- No, novel or high-risk --> RC["Reliability review committee"]
  RC --> APV{Approved?}
  APV -- Yes --> M
  APV -- No --> X
  M -.emergency path.-> E["Post-hoc review within 48h"]

Who signs off, and when a lighter record is enough

I publish a decision registry: for each recurring class of decision (a change to shared infrastructure, a new service touching customer data, a schema change to a shared data model), it names who decides, who has to be consulted, and what artifact is required, a full write-up for something high-risk, or just a short note in a decision log for something routine. Each entry lists this explicitly, so "how much process does this need" is answered once per decision type, not re-litigated every time it comes up. Teams with materially different regulatory environments (a team handling data under a jurisdiction with stricter requirements than the rest of the org) get their own registry entries reflecting that, rather than either exempting them silently or forcing the strictest rule on everyone. The default for anything not flagged high-risk is a lightweight record: a short decision log entry, not a formal document with a review meeting.

Keeping it from becoming bureaucracy people route around

• Automate what can be automated. Guardrails enforced by automated checks in the deploy pipeline (sometimes called policy-as-code, tools like Open Policy Agent are one example) catch the routine violations without a human in the loop, so most changes never need a meeting at all.
• Build in an emergency path. A genuine emergency gets a fast lane: a documented exemption with a mandatory post-hoc review within a couple of days, so people aren't incentivized to quietly work around the process under real time pressure.
• Publish principles, not just rules. A short, named list of guiding principles that teams can cite and apply themselves, without filing a request, covers the many situations a fixed rule can't anticipate; a purely prescriptive rulebook can't keep up with a fast-growing org and becomes exactly the kind of thing people route around.
• Evolve the balance deliberately as the org grows. What's centralized at fifty engineers usually needs to loosen by two hundred; I'd revisit the centralize/delegate split on a fixed cadence rather than letting it drift by inertia in either direction.

The same registry-and-guardrail pattern extends past pure architecture: a standard event taxonomy or a canonical definition for something like "active user" benefits from the identical approach, a working group proposes it, a lightweight registry entry records who owns it, rather than either an unenforceable style guide or a top-down mandate nobody consults before diverging anyway. And when a team wants to add a capability into a shared platform, that's just another registry entry type: it needs the same explicit answer to who decides and what evidence is required, whether the platform is core infrastructure or a set of shared platform interfaces with their own contributor guidelines.

Worked example

A team wants to upgrade the container runtime on shared cluster nodes, a change with platform-wide blast radius. The registry says: decider is the central platform group, consulted parties are the owning team and site reliability engineering, and the required artifacts are compatibility test results and a rollback plan. An automated check blocks the cluster update from merging without a passing canary result. If it's not an emergency, it goes through the normal path with those sign-offs. If it is (a critical security patch), the emergency path allows a fast merge with a mandatory postmortem-style review within 48 hours, so speed under real pressure doesn't require bypassing the record entirely.

Trade-offs and pitfalls

• Centralizing too much. Slows every team down and turns the review group into a bottleneck people learn to route around by making decisions look smaller than they are.
• Delegating too much. Produces inconsistent reliability and duplicate half-built infrastructure across teams, the failure mode the central guardrails exist to prevent.
• A rulebook with no principles behind it. Can't keep pace with a growing org and becomes exactly the bureaucracy the process was supposed to avoid.
• No emergency path. Guarantees the process gets quietly bypassed under real pressure instead of used correctly, since a process with no fast lane teaches people that following it is incompatible with urgency.

Direct answer

I separate the decision into what's actually unknown, what's knowable in the time available, and what we simply have to accept as risk, then I get stakeholders to state their risk tolerance in concrete terms instead of arguing about the plan in the abstract. I make the recommendation defensible by documenting the assumptions and the trigger conditions that would make us reverse it, so the reasoning survives even if the outcome doesn't.

How I structure a decision with incomplete information

• List the knowns, the unknowns, and what each unknown costs if it goes the wrong way. Not every unknown is worth resolving; the ones worth spending time on are the ones whose failure mode is expensive.
• Turn "how much risk is acceptable" into a concrete question. Instead of asking stakeholders whether they're comfortable with risk, I ask what specific loss they can tolerate and what signal would tell us we crossed the line. That turns a values disagreement into a measurable threshold people can actually agree on.
• Pick the option whose worst case is recoverable, not the option with the best expected case, when the unknowns are large. A decision that can be cheaply undone is worth more than its expected value suggests, because it buys time to learn the thing you don't currently know.
• Write the recommendation down with its assumptions and its reversal trigger, before the rollout starts, not after. If I'm wrong, the paper trail should make it obvious what changed, not just that it failed.

Worked example

A team was migrating a sharded datastore to a new partitioning scheme ahead of a growth push, and the traffic pattern for the new user segment driving that growth wasn't fully characterized yet: we had projections, not production data. Product wanted to cut over before the segment launched to avoid a second migration later; the SRE team wanted to wait for real traffic data before committing to a partition key, worried about a bad key choice causing hot shards that would need a second, more disruptive migration to fix.

I laid out the actual unknowns: how skewed the new segment's access pattern would be, and how expensive a second migration would be if the first key choice was wrong. I asked the SRE team to state the concrete failure mode they were protecting against (sustained P99 latency degradation on the hottest shard) and asked product what loss was acceptable if we waited (a fixed number of weeks of delay to the growth push). Both were quantifiable once stated that way. I recommended a phased cutover: migrate on the best-available projected key, but keep the old sharding scheme's routing code live and instrument shard-level load so we would have real signal within the first two weeks of the new segment's traffic, with an explicit threshold (sustained shard imbalance past a set point) that would trigger a second, corrective repartition rather than an emergency one. I documented the projection we used, why we chose it over waiting, and the exact signal that would tell us it was wrong.

Trade-offs and pitfalls

• Treating "we don't have enough data" as a reason to wait indefinitely. Waiting has a cost too; the discipline is comparing the cost of waiting against the cost of a wrong guess you can detect and correct quickly.
• Letting the loudest stakeholder's risk tolerance become the default. Stating tolerance in concrete, comparable terms is what prevents the decision from just reflecting whoever argued longest.
• Skipping the instrumentation that would tell you if you were wrong. A phased decision without a real signal to watch is not actually phased, it's just a delayed all-at-once bet.
• Documenting the decision but not the trigger for reversing it. A record of "why we chose this" without "what would make us change it" doesn't actually reduce risk, it just explains the risk after the fact.

Direct answer

Decompose by consumer dependency, not by internal code structure: the sequencing question is which piece can be extracted with the fewest teams needing to change anything on day one, not which piece is architecturally cleanest to pull out. Before committing to a multi-year effort at all, get an explicit answer to whether incremental refactoring or wrapping the existing system buys most of the benefit for a fraction of the cost, because a full rewrite into microservices is not always the right call even when the monolith is genuinely a problem.

Structured elaboration

• Decide the type of change first. There are three real options for a system that is slowing delivery: refactor it in place, wrap it behind a stable interface (the strangler pattern: new functionality goes to new services, old functionality routes to the existing system until it is incrementally replaced), or fully replace it. Full replacement is usually the most expensive and riskiest option and should be the fallback once the first two are ruled out for a documented reason, such as the existing system's internals being unsafe to touch, not merely unpleasant to touch.
• Decompose along consumer boundaries. Map every internal and external consumer (which teams, which APIs, which downstream jobs) before deciding what extracts first. A domain with few consumers and low criticality, notifications, say, is a safer first extraction than the domain most core to the business, even if the core domain is more architecturally interesting, because the first extraction is also where you prove out the migration mechanics (deployment pipeline, dual-write pattern, rollback path) with limited blast radius.
• Keep both systems correct simultaneously during the transition, using change-data-capture (CDC, a mechanism that streams row-level database changes as they happen) to replicate data into the new service asynchronously at first, moving to a stricter consistency guarantee only where eventual consistency is genuinely unacceptable, such as financial balances, not most read-heavy views.
• Maintain an explicit contract with consumers: versioned, documented APIs, a deprecation timeline for the old path, and adapters for consumers who cannot move immediately, rather than letting the two systems drift silently out of sync.
• Gate promotion between phases on real numbers, not on calendar time: replication lag under a stated bound, error rate under a stated bound, and a minimum share of traffic or consumers actually cut over, so "next phase" is a decision, not a default.

flowchart LR
    A[Map consumers and criticality] --> B[Choose refactor, wrap, or replace]
    B --> C[Extract lowest-risk domain first]
    C --> D[Dual-write plus CDC sync]
    D --> E{Gates met: lag, errors, adoption}
    E -- no --> D
    E -- yes --> F[Cut traffic to new service]
    F --> G[Next domain by consumer risk]
    G --> H[Decommission old path]

Worked example

Picture a migration triggered by an acquisition: two companies' data platforms need to become one, with well over a hundred consuming teams and thousands of downstream API clients between them, some internal, some external. Rather than a single cutover, the first extraction is the lowest-risk shared domain, say a reference-data service used read-only by most teams, validated with change-data-capture and shadow traffic before anything routes to it live. Each subsequent domain is chosen by consumer criticality, not architectural neatness, until the last of the five original business units still reading from the legacy warehouse migrates off and it can finally be decommissioned. For at least one domain along the way, the honest answer to "should this be a service migration at all" is no: a batch reporting job moving to a streaming architecture only pays for its added operational complexity if the business genuinely needs sub-hour freshness, and where it does not, refactoring the batch job in place is the right call, not migrating it because the rest of the platform is migrating.

Trade-offs and pitfalls

Big-bang cutovers fail because the blast radius of a mistake is the whole system at once; the strangler pattern trades that for a longer timeline and the real cost of running two systems and a synchronization layer simultaneously, which itself needs monitoring and can become a permanent fixture if nobody owns retiring it. The second common failure is sequencing by architectural interest rather than consumer risk, extracting the domain engineers find most interesting first and leaving the actual blockers to team velocity for last. The third is skipping the refactor-or-wrap option entirely because a full rewrite is the more exciting project to propose, when the organization may not need to pay for one.