Technical Leadership and Influence Questions

Direct answer

A written decision record needs enough context, alternatives, and reasoning that someone with none of the meeting-room context can reconstruct why the choice was made, not just what was chosen. For a decision I expect to be reversed, I keep the record deliberately lighter and add one thing most templates skip: an explicit trigger for when to revisit it, so it doesn't quietly calcify into a permanent decision nobody re-examines.

The sections I insist on

• Context: the problem and constraints as they were understood at the time, written for someone who wasn't there. This is the section people skip and the one that makes the record useless six months later without it.
• Decision: one clear, unambiguous statement of what was chosen.
• Alternatives considered, with why they were rejected: not just a list of options, but the specific reason each one lost, so a future reader doesn't have to independently re-litigate an option that was already ruled out for a reason still worth knowing.
• Consequences and known trade-offs: what got worse to get this benefit, stated honestly.
• Owner and reviewers: who's accountable for the decision and who signed off, since "who do I ask" is usually the first question a future reader has.
• Status and review date: whether it's active, superseded, or up for reconsideration, and when.

What changes for a decision I expect to be reversed

I keep it short (a couple hundred words, not a multi-page document) because a heavy record for a decision I already expect to revisit is wasted effort and discourages anyone from actually updating it later. I set an explicit review trigger up front, either a date or a concrete condition ("revisit once traffic on the new path exceeds X" or "revisit at next quarter's planning"), rather than leaving "temporary" as an implicit, unenforced label. And I mark the status plainly as provisional in the document itself, so a future reader doesn't mistake a stopgap for a considered, permanent architecture choice, which is exactly how temporary decisions quietly outlive their justification.

Making sure the record actually gets used

Writing the document isn't the same as the decision being understood. I circulate it to the teams it affects before treating it as final, not just after, and I link it from the code or infrastructure it governs so someone hits it while doing the work, not only while searching a wiki. For an organization with no existing practice, I'd introduce it on the highest-friction decision available (the one that generated the most Slack debate recently), because a record that resolves a real, felt disagreement earns buy-in faster than a template introduced in the abstract ever does.

Worked example

A team needed to decide whether a new internal feature flag should default to on or off during rollout, a decision genuinely likely to be revisited within weeks as usage data came in. The record was short: two to three hundred words covering the specific rollout risk, the two options (default-on with a kill switch vs. default-off with opt-in), the choice (default-off, opt-in, given the blast radius of the affected workflow), and an explicit trigger to revisit once a defined fraction of eligible users had opted in or two weeks had passed, whichever came first. That review date is what separated it from silently becoming the permanent behavior nobody remembered to reconsider.

Trade-offs and pitfalls

• Writing the context section as if the reader shares your assumptions. The point of the record is that they don't; skipping context is the single most common way these documents fail their actual purpose.
• Listing alternatives without saying why they lost. A bare list invites a future reader to re-argue an option that was already ruled out, wasting the exact effort the record was meant to save.
• No review trigger on a decision meant to be temporary. Without one, "temporary" decisions are the ones most likely to still be running in production two years later, unexamined.
• Treating the record as done once it's written. A decision record nobody reads or links to provides none of its intended value; distribution is part of the job, not an afterthought.

Direct answer

I require a short, focused pre-read before the meeting (the problem, the options, the data behind them, not a pitch for one answer), invite the people who'll actually operate or approve the outcome rather than everyone remotely interested, and when two attendees disagree I redirect the conversation from stated positions to the underlying constraints each of them is protecting, then settle it against evidence rather than whoever argues longer.

Pre-reads I require

A two-page document, sent enough in advance that people arrive having actually read it: the problem and current metrics, the options actually being considered (not one option dressed up as several), rough cost and risk for each, and any prototype or benchmark data available. I explicitly ask people to bring disagreement in writing beforehand if they have it, so the meeting starts from known positions instead of surfacing them live for the first time, which burns the room's limited time on restating context instead of resolving disagreement.

Who I invite

The engineers who will build and the ones who will operate the result, since design-time convenience and runtime cost are often in tension and both need a voice. A reliability-focused reviewer if the change affects availability or incident risk. A security reviewer if the change touches data access or the trust boundary, since security is easy to leave out of an architecture conversation and expensive to add back in later. A product stakeholder if the change affects what's shippable or when. If a technical program manager is involved, they typically own getting the pre-read circulated and the room booked with the right people, not the technical recommendation itself, and keeping that distinction clear avoids the meeting drifting into project-status territory. I keep the list to the people who need to decide or will be materially affected, not everyone who might find it interesting; a design review that tries to include everyone stops being a decision-making meeting.

Handling genuine disagreement in the room

When two people show up with real, substantive disagreement rather than a misunderstanding, I don't try to referee it as a personality conflict. I ask each to state the specific constraint they're protecting in concrete terms (a latency floor, an operational complexity ceiling, a data-consistency guarantee) rather than their preferred solution, because two people arguing for different solutions are often actually protecting the same underlying concern and don't realize it. Then I score the options against those stated constraints using whatever data is on the table, prototype numbers if we have them, rather than letting the debate resolve on seniority or persistence. If the data genuinely doesn't settle it, I say so explicitly and either scope a short follow-up spike to get the missing data or make the call myself as the meeting owner and document why, rather than letting the meeting end without a decision.

Worked example

A notification service was missing its latency target under peak load, and I ran the design review to replace a single-worker batch processor with something that would scale. The pre-read covered current metrics, three real options (a streaming platform with partitioned consumers, a sharded worker pool, a managed publish-subscribe service), and prototype latency numbers I'd gathered beforehand. I invited backend engineers, an SRE, a product manager, and a security reviewer given the service touched user contact data. The SRE favored the managed option for lower operational burden; backend engineers favored the streaming platform for control over partitioning and failure isolation. I asked each to state the constraint they were protecting: the SRE's was on-call load, backend's was avoiding a hard ceiling on horizontal scaling. The prototype data showed the streaming option met the throughput target with acceptable, quantified operational overhead, which resolved it on evidence rather than preference. We agreed the meeting owner (me) would write up the decision and the operational commitments needed to satisfy the SRE's concern, closing the loop instead of leaving it as an unresolved parallel objection.

This same shape scales down and up: a narrower change, like an internal billing application programming interface, might only need a focused hour with the engineers, quality assurance, and one product stakeholder; a platform-wide move needs the fuller group and probably more than one session.

Trade-offs and pitfalls

• Skipping the pre-read and using the meeting itself to build shared context. That turns a decision meeting into a status meeting and wastes the room's actual purpose.
• Inviting too many people "to be safe." A design review with fifteen attendees rarely reaches a decision; it reaches a list of concerns.
• Treating disagreement as something to smooth over instead of resolve. Letting two people leave with different unstated assumptions about what was decided just moves the conflict to implementation time, where it's more expensive.
• Ending the meeting without an owner for follow-up. A design review that produces a direction but no named owner for the write-up and next steps tends to lose momentum within days.

Direct answer

Do not frame it as centralize versus federate in the abstract; frame it as which failure mode the organization can tolerate less right now, duplicated effort and inconsistent controls, or a platform bottleneck that slows every team down. Get the groups to agree on that trade-off explicitly, propose a hybrid that keeps a thin, mandatory core centralized (security, shared contracts, a catalog) while leaving team-specific logic federated, and put governance guardrails in place so the "consistency" side does not silently become a queue.

Structured elaboration

• Separate what genuinely needs one source of truth from what does not. Identity, access controls, data contracts, and anything with real compliance exposure benefit from a single owner because inconsistency there creates real risk. Team-specific pipeline logic, feature engineering, and anything iterating fast usually does not need central ownership, and forcing it through one team just adds latency without reducing risk.
• Make the competing incentives explicit instead of pretending they don't exist. The team that wants centralization is usually optimizing for consistency, audit-ability, and lower duplicated cost. The team that wants federation is usually optimizing for speed and not being blocked by another team's backlog. Naming both incentives out loud, rather than letting one side argue "best practice" and the other argue "we need to move fast," is what makes the eventual guardrails feel earned rather than imposed.
• Propose a hybrid with a genuinely thin mandatory core: a managed core (identity and access management, standardized CI/CD templates, a shared schema or data-contract standard, policy-as-code checks that run automatically) plus federated ownership of everything downstream of that core. The core has to be thin enough that owning it does not become its own bottleneck, or you have just renamed the centralization problem.
• Put decision-quality guardrails on both sides: for the centralized core, explicit service-level agreements and a self-service path so teams are not waiting on a human for routine requests; for the federated side, mandatory data contracts between teams and automated compliance checks at the CI/CD gate, rather than a manual review that becomes the new bottleneck.
• Get agreement through a governance body with real teeth, not just a meeting. A recurring cross-functional review (platform lead, a rotating team representative, security) that owns exceptions and revisits the split as the organization changes gives both sides a channel that does not require re-litigating the whole model every time a new team joins.

Worked example

A growing data organization had eight product teams each building and maintaining their own ingestion pipelines into a shared warehouse. The platform team wanted to centralize ingestion entirely, citing three separate incidents where inconsistent schemas broke downstream dashboards. Product teams wanted to keep full ownership, citing a real case where waiting on the platform team's backlog delayed a launch by six weeks.

Rather than pick a side, I proposed splitting the decision along the line that actually mattered: schema and data-contract enforcement (where inconsistency was the demonstrated root cause of the incidents) moved to a thin, centrally-owned layer with automated validation at write time, while the ingestion logic itself, the code that actually pulls and transforms each team's data, stayed with each product team. The platform team got what it needed (consistency where inconsistency had caused real incidents) without becoming a bottleneck on ingestion code changes, and product teams kept the speed they needed on the part that was actually slowing them down before. We set up a quarterly review with one rotating product-team representative and the platform lead to handle exceptions and revisit which layer new capabilities belonged in as the platform matured.

The test that made the decision durable, and that both sides could check independently afterward, was simple: did the incident rate related to schema drift go to roughly zero (it did, because that was now enforced automatically rather than by convention), and did any team's shipping cadence slow down because of the centralized layer (it did not, because the mandatory core was thin enough to validate in CI without a human in the loop).

Trade-offs and pitfalls

• A "hybrid" proposed as a political compromise rather than derived from where inconsistency actually caused harm just recreates both failure modes at smaller scale; ground the split in evidence (the actual incidents, the actual delays), not in splitting the difference.
• A thin core has a strong pull to grow: every team's edge case becomes a request to add "just one more thing" to the mandatory layer, and left unchecked the core re-becomes the bottleneck it was designed to avoid. Someone has to own saying no to scope creep on the core.
• Federated ownership without enforced contracts degrades quietly; the incidents that justified centralizing schema enforcement in the first place don't announce themselves until something downstream breaks.
• A governance body without real authority to resolve disputes becomes theater; if the quarterly review can only make recommendations that either side can ignore, the underlying tension never actually resolves, it just gets a recurring meeting.

Direct answer

Use a small number of weighted criteria that map to what actually matters for the decision (impact, cost, risk, time-to-value), score each option against them, and let the arithmetic force the trade-offs into the open instead of hiding them in a gut call. The framework's value is not the exact score, it is that everyone can see, and argue with, which input drove the outcome.

Structured elaboration

Pick 4 to 6 criteria at most and weight them before you know the options. Weighting after you have seen the scores is how people reverse-engineer their preferred answer.

Score each option 1 to 5 per criterion, independently, ideally by more than one person, then compute a weighted total:

$\text{Total}_i = \sum_{c} w_c \cdot s_{i,c}$

where $w_c$ is the weight for criterion $c$ (weights summing to 1) and $s_{i,c}$ is option $i$'s score on that criterion.

Treat the output as a starting point for discussion, not a verdict. If two options land within a small margin of each other, that is a signal the framework cannot discriminate, either add a tie-breaking criterion, a hard constraint like team familiarity, or fall back to judgment and say so explicitly, rather than pretending the third decimal place means something.

The value is not precision, it is making the trade-offs auditable. A stakeholder who disagrees with the outcome can point at exactly which weight or score they would change, instead of arguing with an unstated gut feeling.

Worked example

Decision: build an internal API gateway in-house versus adopt a managed one, for centralized auth, rate limiting, and traffic analytics.

Criteria and weights: business impact 35%, developer experience 25%, implementation effort (ease) 20%, operational risk (lower risk scores higher) 15%, time-to-market 5%.

The managed option wins clearly, 4.30 versus 3.10, driven mostly by developer experience and time-to-market, not by a close call on any single criterion. That is useful precisely because it tells you where the disagreement would have to live if someone wanted to argue for building in-house instead: they would need to argue the effort or time-to-market scores are wrong, not just assert a preference. Those effort and time-to-market scores were themselves an input assumption feeding the table, roughly 8 weeks to integrate the managed option versus an estimated 4 to 6 months to build the equivalent in-house, which is what produced the gap between the two options above, not a result observed after the fact.

Trade-offs and pitfalls

• A weighted score can launder a biased decision behind a veneer of rigor if the person building the model already knows the answer they want and picks weights to match. Guard against this by setting weights before scoring, and by having more than one person score independently.
• Treating a narrow margin, say 3.1 versus 3.3, as decisive manufactures false precision. When the gap is inside your own scoring noise, say so and use a real tie-breaker instead of the third decimal place.
• The framework is bad at capturing qualitative, hard-to-score factors, team morale, strategic optionality. Do not force those into a number, list them separately as an explicit override consideration.
• Reusing the same weights for every decision regardless of context is a common misuse. The weight on operational risk should be much higher for a payments system than for an internal reporting tool.

Direct answer

Anchor the whole program on baselining first, not target-setting first: measure where the org actually is on a small number of leading and lagging signals, then set targets as a fraction of that measured baseline rather than an invented number, and phase in enforcement gradually so the program earns credibility before it asks for hard compliance. What keeps it from becoming a compliance exercise is that the scoreboard is outcomes, fewer incidents, faster recovery, faster and safer delivery, not activity, percentage of teams that attended training, percentage of services with a badge.

Structured elaboration

What to measure, leading and lagging, and why both matter:

• Lagging (outcomes): incident frequency, mean time to detect and mean time to recover, production bug rate per release. These are what you are actually trying to improve, but they move slowly and are easy to game by redefinition.
• Leading (practice signals that predict the lagging ones): percentage of critical services with basic tracing, metrics, and logging in place; pull-request cycle time; whether critical services have an on-call runbook that has actually been used, not just written. These move faster and tell you whether the program is working before the lagging metrics catch up.

Governance and phasing, quarterly and staged, not a big-bang mandate:

1. Baseline quarter: measure current state honestly on a couple of pilot teams before committing to any target. A program that skips baselining ends up defending invented numbers.
2. Pilot quarter: apply the practice changes, tracing, basic service-level objectives (SLOs, the specific reliability targets a team commits to), continuous-integration (CI) checks, to the pilot teams, and treat the pilot's own before-and-after change, not an assumed industry figure, as the evidence for the rest of the rollout.
3. Expand quarter: roll out to the rest of the org with the templates and tooling the pilot proved out, and introduce lightweight enforcement, CI gates for the checkable items, not a review board for everything.
4. Sustain quarter: fold the surviving metrics into normal quarterly review and retire the special program status. A program that never ends is not a program, it is a permanent tax, and teams notice the difference.

Avoiding the compliance-exercise trap specifically: tie the metrics to things a team would want anyway, fewer 2am pages, less time firefighting, and use the pilot team's own real improvement as the pitch, not a mandate from a council. Never let "percentage compliant" become the headline metric, a team can be fully compliant on checklist items and still have bad reliability if the checklist does not map to real behavior, so keep the lagging outcome metrics as the actual scoreboard and treat leading and practice metrics as diagnostic. Build in an explicit, lightweight exception path so teams with a real reason to deviate do so openly; a program with no legitimate way to say "not yet, and here's why" produces gaming instead of honest exceptions.

Governance structure: a small standing group, a rotating set of senior engineers plus one reliability-focused owner, that reviews the metrics and playbook quarterly and has authority to revise the standard, not just enforce it. A body that can only enforce and never revise loses credibility the first time a rule turns out to be wrong for some team's real context.

Worked example

Illustrative baseline-and-target methodology, shown so a reviewer can reproduce the reasoning, not a claimed historical outcome. Suppose the pilot's baseline quarter measures a current mean time to recover of 90 minutes across the pilot's critical services. Rather than asserting an arbitrary target such as "cut it 40 percent," the program sets the target from what the specific interventions plausibly buy: adding basic distributed tracing and a documented, tested runbook. If the pilot's own after-state for the services that got both changes comes in at, say, 55 minutes, that pilot number, not a projected industry average, becomes the evidence used to set the expand-quarter target for the rest of the org. The program's credibility rests entirely on that number being the pilot's real, reproducible before-and-after, not an assumed percentage stated up front.

Trade-offs and pitfalls

• Setting a target before baselining, mandating "cut mean time to recover 40 percent" org-wide on day one, is the fastest way to make this read as a compliance exercise, because nobody can tell if the number is real.
• Over-indexing on leading or practice metrics, badges, checklist completion, without ever checking whether they moved the lagging outcome metrics lets a team look compliant while reliability does not improve.
• A governance body with only enforcement power and no ability to revise the standard loses legitimacy the first time a rule is wrong for a real team's context, and teams stop engaging honestly once that happens.
• Treating this as a 12-month sprint that ends on schedule regardless of outcome, instead of sustaining the surviving pieces past the program, is how these programs regress within a year of "completion".