Technology Strategy and Business Alignment Questions

Direct answer

Pick a handful of principles from the places where inconsistency is actually costing the organization, word each one as a decision rule with its reason and what it means in practice, and measure change by watching what design reviews decide, not by counting how many teams read the document.

What an architecture principle is

An architecture principle is a short, durable rule that guides design choices, such as "prefer managed services over self-operated ones". It is guidance with reasons that requires judgment. A guardrail or standard is a rule that is checked or enforced (for example, a policy that blocks public storage buckets). Principles guide, guardrails enforce, and a few mature principles are turned into guardrails once they are clear and testable.

How I decide which to write

1. Read recent design reviews, incident reviews and cost reports for recurring costs of inconsistency (many different ways of doing messaging, mixed identity approaches). Messaging means services passing work to each other through a message broker, a shared system that queues and delivers messages between services. An identity approach is how a service proves who a user or another service is (for example, each team building its own login instead of using one shared sign-in service).
2. Interview a sample of teams on where they feel they are guessing.
3. Keep the ones where choices differ widely, the cost of difference is real, and teams would accept a shared answer. A handful is enough; a long list will not be remembered.

How to word them

A design record is the short written description of a design that a team brings to a review (the proposed approach, the alternatives considered, the decision). A usable principle has four parts: a name, a statement, the rationale, and the implications (what teams do and do not do). It names a trade-off rather than a platitude, and a reviewer must be able to say yes or no to it.

Weak: "Systems should be scalable." Applicable: "Prefer managed services to self-operated ones unless a documented requirement cannot be met. Rationale: operations effort is the scarce resource. Implication: a team running its own message broker on virtual machines must file an exception stating which requirement the managed option fails."

Worked mapping

Decision in a review: a team proposes running its own message broker. The principle gives the reviewer a question ("which requirement does a managed service not meet?"), and the answer is either a documented gap, which approves an exception, or no gap, which sends the team to the managed option.

Telling whether they are changing decisions

• Share of design records that cite a principle, and the number of recorded exceptions with reasons. To compute it: count the design records reviewed in a period, count those that name a principle, and divide. Illustratively, if 30 records were reviewed in a quarter and 12 name a principle, the share is 12 / 30 = 40%. Track it each quarter, and read it alongside how many records ended in an exception with a stated reason.
• Variety: the number of distinct approaches in use for the same need (illustratively, from 7 messaging approaches across 30-plus teams to 3, so 4 fewer approaches to support).
• Review time and rework: do repeated questions disappear?
• A short survey asking teams whether principles helped or blocked them.
• If a principle is never cited or always excepted, it is wrong or unclear and I rewrite it.

Enforcement versus guidance

Guidance explains and invites exceptions. Enforcement automatically blocks. Use enforcement only where a violation is clearly harmful and detectable, and keep the exception route open.

Direct answer

I would design measurement before launch, not after: a short chain from adoption to process outcomes to business outcomes, a baseline taken in advance, and a rollout staged so some teams adopt later and act as a comparison group. That staging is what lets me separate the program's effect from seasonality, pricing changes and market shifts. Finance owns the money model (the spreadsheet that turns measured effects into dollars); my job is to supply credible measured effects and say how sure we are.

1. Build the measurement chain

1. Adoption (leading indicator, one that moves early and predicts later results): percent of target users active weekly, data quality in the new system.
2. Process outcomes: lead response time, quote-to-close days (sales cycle), manual re-keying hours.
3. Business outcomes (lagging indicator, one that confirms results only months later): win rate, revenue per salesperson, customer retention.
   Each metric has a named owner, definition and source, written down at the start. Take at least two to four quarters of baseline.

2. Separate the program's effect from everything else

• Stage the rollout: teams or regions switch at different dates. Compare the change in switched groups with the change in not-yet-switched groups over the same period (difference-in-differences). Seasonality (predictable calendar swings, such as a year-end buying rush) and market changes hit both groups, so they cancel out, provided the groups would have trended alike without the CRM. Check that with the baseline quarters: if A and B went 64, 63, 62 days and C and D went 62, 61, 60 (illustrative), both pairs were falling about 1 day a quarter beforehand, which supports the comparison.
• Keep a log of other changes (pricing, hires, reorganizations) and check the result against it.
• If staging is impossible, use a trend comparison: pick similar units that did not adopt (matched on size and starting sales cycle) and compare their trend with the adopters'. State the lower confidence, for example "the CRM shortened the sales cycle by about 5 days, plausible range 3 to 7; about 2 of the 7 days we saw would have happened anyway."

3. Worked example (illustrative)

Regions A and B get the CRM in Q1; C and D wait until Q3. Median sales cycle: A and B go from 62 to 55 days (-7); C and D go from 60 to 58 (-2) with no CRM. Estimated effect = (-7) - (-2) = -5 days, not -7. The 2 days is everything else changing. Repeat each quarter as rollout proceeds.

To connect it to money (Finance builds the real model; this is the shape): if the company closes 400 deals a year worth $20,000 each, that is $8M of bookings. Closing 5 days sooner pulls cash forward by 8,000,000 x 5 / 365, about $110k, a one-time timing benefit. Value from reps handling more deals in the same time is modelled separately, with the assumption that reps are limited by time rather than by leads stated explicitly.

4. Decision velocity (a measure of how fast decisions get made)

Define it measurably, for example the median hours from a discount-approval request being raised to it being decided, for one defined class of decisions. Instrument it (build the measurement in) with timestamps in the workflow tool. Illustrative: the median goes from 30 to 18 hours in staged teams and from 30 to 27 in not-yet-staged teams, so the estimated effect is (18 - 30) - (27 - 30) = -9 hours. Attribute causally the same way: compare staged groups. Watch for the measure falling because decisions are being rubber-stamped (approved without real review); pair it with a quality check such as approvals later reversed, say 4.0% before and 4.5% after.

5. Over three years

Quarterly benefit reviews with owners, each ending with a one-line statement of the estimate and its range; a year-1 view dominated by adoption, year-2 by process outcomes, year-3 by business outcomes. Expect lag: do not judge revenue effects at month 6.

Trade-offs and pitfalls

• Adoption is not value; people can log in and change nothing.
• Staged rollout delays benefits for later groups, a real cost that executives must accept.
• Do not credit the program for improvements already trending before launch; the baseline shows this.

Direct answer

I would move the architecture team from approving designs to making the right path the easy path. Standards that truly must hold become automated guardrails and a small number of mandatory rules. Everything else becomes recommended patterns, with a quick, advisory conversation instead of a gate. After a year I would judge it by whether product teams move faster and whether the standards are actually still met.

Step 1: Understand why it feels like a gate

Interview six or so product teams and look at review history: how long does a review wait, how late in the project does it happen, how many reviews end in a change? A gate is usually slow, late and applied to everything equally.

Step 2: Evolve the model

1. Tier by reversibility (how easily the decision can be undone) and blast radius (how much can break, and for how many teams or customers, if it goes wrong). For example, a team choosing a charting library is easy to undo and affects only that team, so it needs no review. A team creating a new store of customer addresses that other teams will read is hard to undo and affects many, so it gets a short review. A guardrail is a rule enforced automatically (for example, storage must be encrypted: a deployment that creates unencrypted storage is blocked automatically, with a message naming the one setting to change) so nobody has to ask. Easy-to-reverse, local decisions need no review. Hard-to-reverse or cross-team decisions (data ownership, shared interfaces, anything touching customer data) get a short review.
2. Build the paved road. Ready-made templates and reference designs that already satisfy the standards. Teams that use them skip review.
3. Embed architects with teams. Closer to an enabling team in the Team Topologies sense (Team Topologies is a published model of how to organise software teams; an enabling team's job is to help others adopt good practice), rather than a separate approval body.
4. Write decisions down. Short ADRs (architecture decision records: a page stating context, decision and consequences) so teams can decide and architects can review afterwards. A sample: Context: Orders and Billing both need customer addresses. Decision: Orders owns the address record and Billing reads it through Orders' interface. Consequences: one source of truth, but Billing now depends on Orders being available, so Billing caches addresses for a few minutes.
5. Keep the escape hatch. Teams may deviate with a documented reason, and the exception is reviewed.

Step 3: Worked example (illustrative)

Today every one of 40 designs a quarter goes to the review board. If paved-road designs and easy-to-reverse changes cover 60%, 24 skip the board and 16 receive a focused review. Reviewers spend the same effort on fewer, harder decisions.

Step 4: Knowing after a year

• Median time from design submission to decision (target agreed up front).
• Share of designs that used a paved road or needed no review.
• Compliance with the mandatory standards, measured automatically.
• Number of exceptions and their outcomes.
• Incidents traced to a missed standard.
• A short survey of product teams: is architecture helping or blocking? Ask the same questions as at baseline.

Pitfalls

• Removing review without guardrails lets standards erode.
• Paved roads that nobody maintains become the new bottleneck.
• Measuring only speed hides erosion; measuring only compliance hides friction. Use both.
• What would change my call: if compliance falls while speed rises, tighten the guardrails, not the gate.

Direct answer

I would not decide on enthusiasm. I would ask whether the capability is something customers choose us for and competitors cannot easily copy. If yes, differentiate, but contain the risk by keeping the unstable part replaceable. If no, use a commodity option and spend effort elsewhere. Before committing I would want evidence on our own tasks, not a vendor demo.

Step 1: The differentiation test

An "LLM architecture" choice here ranges from calling a vendor's hosted model through its API (the commodity end), through tuning a model on our own examples (fine-tuning), to building or self-hosting our own model (the differentiated end, with more control and more cost and upkeep).

Differentiate means building or tuning something so customers prefer us for it. Commodity means using what everyone can buy. Ask:

1. Does this capability change why a customer picks or stays with us? (Evidence: customer interviews, win/loss notes, meaning sales records of why we won or lost each deal.)
2. Is our edge in the model itself, or in what surrounds it: proprietary data, workflow integration, trust, distribution? The model layer changes monthly; the surroundings last longer.
3. Could a competitor reproduce the effect within a quarter using the same commodity option?

Usually the durable advantage is the data and workflow, not the underlying model, which argues for a commodity model with a differentiated product around it.

Step 2: Contain the instability

Put a thin interface (one small piece of code that is the only place the product talks to the model) between the product and the model so swapping is a configuration change, and keep an evaluation set of real tasks so any new model can be compared in hours. Time-box exploration (for example, six weeks) with a stop condition.

Step 3: What I need to see before committing

• A labelled evaluation set from our own use case (a collection of real tasks, each with an agreed correct answer, such as 200 real customer questions for a support assistant) and a score for the commodity baseline, meaning the hosted model everyone can buy.
• A measured gap between the custom option and the baseline, large enough to be real.
• Unit cost per task (what one answered question costs to run) at expected volume, and the cost to switch away.
• A customer signal: pilot users prefer it and use it again.

Worked example (illustrative numbers)

On 200 labelled tasks the commodity option gets 78% right and the custom one 84%. The gap is 6 points. With 200 tasks, chance alone moves each score by roughly 3 points, and a 95% interval on the gap runs from about -1.7 to +13.7 points.

Where those numbers come from: a score measured on n tasks has a standard error of sqrt(p x (1 - p) / n), the typical size of the chance wobble. For the commodity option that is sqrt(0.78 x 0.22 / 200), about 2.9 points. For the custom option it is sqrt(0.84 x 0.16 / 200), about 2.6 points. The two errors combine into sqrt(2.9^2 + 2.6^2), about 3.9 points, for the gap. A 95% interval is the range that would contain the true gap in 95 of 100 repeated tests, roughly the measured gap plus or minus 1.96 x 3.9, that is 6 +/- 7.7, or -1.7 to +13.7. Because the range includes 0, luck alone could explain the 6 points. So this result does not yet separate the options. A note on method: the interval above treats the two scores as independent, which is the conservative case. If both options were scored on the same 200 tasks, as an evaluation set normally does, a paired comparison (counting the tasks where only one option is right) can give a narrower interval, so I would first redo the interval on the paired results. If it still includes 0, I would enlarge the set before paying to differentiate.

Trade-offs and pitfalls

• Overbuilding on a layer that changes monthly means rework; underinvesting where customers truly decide means losing the edge.
• Betting everything on one provider's behaviour without an exit.
• What would flip my call: a regulatory or data-control requirement that commodity options cannot meet, or a measured quality gap customers notice.

Direct answer

I would move architecture oversight from a gate to a set of guardrails plus fast, lightweight review for the few decisions that genuinely need it. Teams decide by default inside agreed boundaries; review is asynchronous with a short response time; and anything that cannot be undone cheaply gets a same-week conversation instead of a queue.

Building oversight into agile delivery

1. Guardrails first. A short list of standards and a paved road (pre-approved, supported building blocks: runtime, pipeline, datastores). Staying on the road needs no approval.
2. Triage by reversibility. A two-way door (cheap to reverse, such as a library choice) is decided by the team and logged in a short architecture decision record (ADR). A one-way door (hard to reverse, such as a public API contract or a regulated data store) gets review.
3. Fit the sprint rhythm. A sprint is a fixed work cycle, often two weeks, with a sprint goal (the one outcome the team commits to for it). Backlog refinement (the regular session where the team reviews upcoming stories) flags stories with one-way-door decisions early. An architect holds weekly office hours (a standing slot when any team can drop in with questions) and reviews written proposals within 2 business days.
4. Architecture runway. The runway is the groundwork (decisions made and risks investigated) that lets future features be built without stopping to redesign. Spikes (short time-boxed investigations) for upcoming one-way doors are scheduled a sprint ahead.

A decision that surfaces mid-sprint

• Classify it in minutes: two-way door or one-way door?
• Two-way: the team decides, writes the ADR, and continues.
• One-way: the team parks only the affected story, keeps the unaffected stories moving, brings the question to the next office hours (or the same day if it blocks the sprint goal), and time-boxes a spike of one to two days.
• If it will not resolve in the sprint, the affected story moves out with the product owner's agreement (the product owner is the person who sets the team's priorities) and the reason is stated at the sprint review (the end-of-sprint meeting where the team shows what was done).

Experimenting in a regulated environment

Regulation restricts what data and which controls are used, not whether teams may learn. I would define an experiment envelope: synthetic (generated) or de-identified (personal details removed) data only, a sandbox account (an isolated cloud account with no path to production) with the mandatory controls already applied (logging, encryption, access control), and a time limit. Illustrative envelope for a healthcare team trying a new triage model: generated patient records only, a sandbox account with logging and encryption on and no connection to production, a 6-week limit, and an automatic account teardown on day 42. Inside the envelope, no review. Before an experiment touches real regulated data or production, it goes through the normal compliance path, with automated evidence (logs and checks that the delivery pipeline produces by itself, such as a record that encryption was enabled, so reviewers need not collect screenshots) so the review is short.

Worked example (illustrative)

A payments team mid-sprint finds it needs a new event contract that two other teams consume. That is a one-way door. The team keeps working on unaffected stories, submits a one-page proposal, gets a response within 2 business days, and ships the contract in the next sprint. A cache library choice the same week is a two-way door: decided, logged, done.

Trade-offs and pitfalls

• Too many guardrails recreate the gate. Review the list quarterly and delete rules nobody has needed.
• Async review fails if architects are the bottleneck; track response time.
• I would change the approach if incident data shows teams are skipping review on one-way doors.