Most leadership teams blame governance when data delivery slows.
It is an easy diagnosis. A new data product needs approvals, access must be configured, service accounts have to be created, catalogue entries must be registered. Additionally, security and compliance checks appear late, usually through tickets, documents and meetings. From the outside, governance looks like the brake.
The question, then, is not whether governance should exist, in a serious data platform, it must. The real question is whether governance exists as a platform-native control system or as a recurring tax on every release.
Key takeaways
- Data teams are not slowing down because governance exists, but because governance is still manual.
When security, access, cataloguing and compliance live in documents, tickets and review meetings rather than in the platform itself, every new data product triggers the same delay pattern. The real problem is poorly embedded governance. - Guardrails-as-code is a speed enabler - not "a compliance tax".
The business value lies in embedding policy-as-code, data contracts, automated checks, catalogue integration and standard access patterns directly into delivery workflows. That shifts teams away from rebuilding infrastructure and towards delivering business logic faster, with less operational risk. - The winning board-level argument is throughput plus risk reduction.
For a CFO, CEO or CTO, the strongest case is measurable improvement in time-to-production, fewer iterations before release, fewer bugs and incidents, and lower audit overhead. That is the point where platform engineering becomes a business performance lever.
Governance gets blamed first because it is the most visible friction
When teams complain that “governance is slowing us down”, they are rarely objecting to the existence of standards. What they are reacting to is the way those standards are enforced.
If policy enforcement happens through manual reviews, if access depends on ticket queues, if metadata registration is treated as a separate administrative task, and if deployment controls appear only at the end of the process, then governance becomes something teams experience as interruption.
That is exactly why so many organisations get the diagnosis wrong. They see friction around compliance and conclude that compliance itself is the culprit.
But our reports point to a more structural problem: only about a third of companies enforce cost tagging through automated policies, and only 29% of developers have optimisation tools integrated into their development workflow.
The consequence is predictable – governance turns into waiting:
- for approvals,
- for access,
- for someone to interpret a policy document,
- for a platform team to recreate the same standard pattern for the fifth time this quarter.
That is not strong governance, but a weak platform design with governance symptoms.
More people will not fix a platform that creates the same friction every time
When delivery slows, management often reaches for the most familiar answer: hire more people. That works only when the bottleneck is genuine lack of capacity; it does not work when the bottleneck is structural repetition.
If experienced engineers keep hitting the same setup work for every new data product, adding more engineers simply scales the same waste. More people end up creating more tickets, more handovers, more duplicated platform effort and more waiting states.
The real issue is not weak onboarding or managerial problems, but a platform that forces even experienced teams to rebuild the same enabling mechanisms every time. Market reports reach the same conclusion from a different angle: 62% of developers want greater control over cloud spending and 77% say complexity prevents it.
That matters beyond engineering efficiency. The same reports note that 72% of organisations exceeded their cloud budgets in the last fiscal year. When a platform forces teams into repeated manual setup and late-stage review, it does not just slow delivery, but also makes cost behaviour harder to predict and harder to attribute.
Ensuring instant data availability and 90% time savings on reporting with Microsoft Fabric SLA automation
The real bottleneck: rebuilding access, controls, and setup work for every new data product
The time loss does not usually happen in the part executives like to talk about: the clever model, the transformation logic, the analytical insight, the shiny dashboard.
It happens in the repeat work around it. For many teams, a “new data product” still triggers the same hidden checklist:
- define permissions and access paths
- create service accounts and secrets
- register metadata and catalogue entries
- translate policy requirements into technical controls
- wire deployment rules, observability and rollback
- repeat approvals for a pattern the organisation has already seen many times
This is the moment where leaders often underestimate the damage. Because the work is fragmented, it looks small. A day here, half a day there, a few back-and-forths with security, another round with the platform team, a last-minute catalogue task before release.
However, this design flaw leads to a deterioration in the pace of implementation, and the consequences become increasingly apparent over time. Teams should receive a prepared boilerplate or solution skeleton that lets them move straight to the business requirement.
What guardrails-as-code means in a modern data platform
Guardrails-as-code is a simple idea dressed in technical language. In executive terms, it means this: the rules stop living in PDFs and start living in the platform.
Instead of asking teams to remember standards, interpret them manually and apply them late, the platform encodes those standards directly into infrastructure, templates, and delivery workflows. Security requirements, access patterns, tagging rules, policy checks, and deployment conditions become machine-enforced defaults rather than optional human tasks.
Guardrails should be embedded into Infrastructure-as-Code and CI/CD pipelines, with automated tagging enforcement, anomaly detection and budget gates built into the delivery flow. That is the right mental model – guardrails-as-code is not extra governance layered on top, but governance moved into the path where work already happens.
That shift changes the character of control – well-designed guardrails do not slow teams down – they remove decisions that should never have been re-made at product level in the first place.
Gain control over your data and AI costs - reduce waste, improve efficiency, and make better decisions based on trusted data.
The minimum foundation: policy-as-code, data contracts, automated checks, catalogs
Not every organisation needs a grand redesign before it can move faster, but it does need a minimum foundation: policy-as-code, data contracts, automated linters and checks, integration with the data catalogue, and standardised permissions plus service accounts baked into the solution skeleton.
In practice, each one solves a different source of delay:
- Policy-as-code turns broad governance intent into executable rules. That matters because vague standards create interpretation cycles, and interpretation cycles create delay.
- Data contracts reduce the ambiguity that leads to downstream rework. They define expectations around schema, ownership, freshness and change, which makes handovers cleaner and failures earlier.
- Automated checks move validation left. Linters, policy tests and deployment checks exist to catch predictable failures before they become release blockers or production incidents.
- Catalogue and metadata integration make discoverability part of delivery rather than a clerical task after delivery.
- Predefined identities and access patterns remove one of the most stubborn sources of friction. Teams should not negotiate the same service-account and permissions model product by product if the organisation already knows what “good” looks like.
How reusable platform boilerplates cut time-to-production without weakening compliance?
The most practical expression of guardrails-as-code is the reusable boilerplate.
A good boilerplate does not just create a repository and a folder structure – it carries the organisation’s operating assumptions with it. It includes the default access model, approved identity pattern, tagging rules, catalogue hooks, policy pack, CI/CD path, test scaffolding, observability defaults and rollback logic.
Future Processing proposes an operating model with guardrails that balance cost control, risk management, and data quality, without slowing engineering teams, by embedding them directly into IaC and CI/CD.
Typical implementation targets include automated tag coverage above 90%, monthly forecast accuracy targets and preventing a large share of regressions through embedded guardrails. Those are not universal benchmarks for every organisation, but they do show the direction of travel.
The KPI story a CTO can take to the board
The board does not need a lecture on policy engines, but a clean story about why the platform can deliver more business value, with fewer surprises, at lower operational drag.
A sensible KPI set should include:
- Time-to-production – how long it takes to move from approved request to first production release.
- Iterations to production-ready – how many cycles are needed before a product is releasable.
- Defects and incidents – especially in the first weeks of a product’s life.
- Change failure and rollback rate – because safe automation matters more than nominal release speed.
- Audit and evidence effort per release – how much manual overhead compliance creates.
- Cost-per-data-product and forecast accuracy – because velocity that cannot be linked to economics will not survive board scrutiny.
That final pair is where the argument becomes strategically stronger. Based on our reports, only 43% of large enterprises can calculate cost-per-data-product, largely because operational and financial context remain disconnected.
So, a CTO who can show faster delivery and better economic attribution is no longer asking for investment in platform hygiene, but for investment in a better operating model.
That is the board-level story: shorter time-to-production, fewer iterations, fewer incidents, less audit drag, clearer ownership and a cleaner link between platform spend and business output.
