How would you make cost a routine engineering concern without slowing delivery?

What is being tested

Whether you can design a practice that engineers adopt, rather than a control function they route around.

The principle

Make the cost of options visible at the moment of choice, and let the team that owns the outcome decide. A practice that vetoes decisions on cost grounds without weighing them against delivery speed and reliability will be circumvented, and the shadow infrastructure that results is both more expensive and invisible.

The mechanisms, in order

1. Allocation first. Mandatory tags enforced at creation, account boundaries per team, shared costs allocated by a published rule. Nothing else works without this — every conversation otherwise stalls on "whose is this?"

2. Unit economics, not totals. Cost per order, per user, per transaction, shown to each team next to their spend. Total spend should rise with a growing business; unit cost should fall. Reporting totals punishes growth and teaches the wrong lesson.

3. Cost in design review, as an estimate alongside latency and availability. Deciding cost before it is spent takes minutes; remediating it afterwards takes quarters. This is the highest-leverage intervention and costs almost nothing in delivery time.

4. Anomaly detection within a day. A misconfigured job can spend a quarter's budget over a weekend. Month-end discovery is far too late, and this control is entirely automatic — no friction at all.

5. A paved road that is also the cheap road. Pre-approved, correctly-sized templates that are the easiest path. Compliance and efficiency become the default rather than an obstacle, which is the only form of governance that survives deadline pressure.

6. Preventive policy on the expensive and irreversible only. Instance types above a threshold, unapproved regions, untagged resources. Everything else is detective. Approval gates on everything produce shadow infrastructure.

What makes it stick

• Continuous, not periodic. A quarterly review produces a spike of activity and nine months of drift.
• Engineers see their own numbers, in a form they can act on. Reports that go only to finance change nothing.
• Paired with reliability targets, so cost is not optimised at the expense of availability. A cost target alone produces the team that removes a replica and causes an outage.
• Someone accountable for the number — a person, not a committee.

What to avoid

• Cost reviews without allocation, discussing unattributable totals.
• A central team optimising other teams' workloads without context, and being correctly resisted.
• Data reported monthly in arrears, too late to connect a change to its effect.
• One-off cost projects with no mechanism to prevent recurrence.

What a strong answer adds

That the framing matters as much as the mechanism. "Cost per order fell from £0.006 to £0.004" is an engineering achievement teams take pride in; "reduce your spend by 15%" is a tax. The same work, presented differently, gets a different reception — and the first framing survives the next deadline.