On this page
Where the platform team sits in your org chart will predict whether it succeeds more reliably than any technical decision you make about it.
This is uncomfortable, because reporting lines tend to be the part of the organisation that feels most fixed. They are the result of historical accident, executive politics, and the way headcount was originally funded. Nobody designed them with platform engineering in mind, because in most cases, the structure pre-dated platform engineering as a discipline.
But the reporting line shapes what the platform team is funded for, what it is evaluated on, and what decisions it has authority to make. Those three things determine whether the platform investment compounds over time, or whether it slowly drifts into operational maintenance.
If the platform team in your organisation is technically strong but somehow keeps under-delivering, the org chart is the place to look first.
What the Reporting Line Actually Does
When a platform team reports to a particular leader, three things follow:
- It inherits that leader’s mandate. A team reporting to an infrastructure leader will be measured on infrastructure outcomes. A team reporting to a product engineering leader will be measured on product engineering outcomes. Neither team can easily operate outside that frame.
- It inherits that leader’s authority. Platform teams need to make decisions that affect other teams - deprecating patterns, enforcing standards, refusing exceptions. The reporting line determines whether they can credibly do that.
- It inherits that leader’s funding logic. Whoever owns the cost line owns the trade-offs. A platform team funded out of an infrastructure budget will be evaluated as infrastructure cost; one funded out of an engineering capability budget will be evaluated as engineering capability investment. These produce very different conversations.
These three things compound. Over two or three years, the reporting line drifts from a structural detail into the dominant force shaping what the platform team can do.
The Four Common Reporting Lines
In practice, platform engineering tends to end up in one of four places. Each one produces a recognisable pattern.
Under the VP of Engineering or CTO
This is the most common arrangement in organisations that have made a deliberate investment in platform engineering, and the one that tends to work.
When platform engineering reports to the leader responsible for product delivery, the team is funded as an engineering capability rather than an infrastructure cost. It is evaluated on whether the rest of engineering ships better - which is the right metric. It has the authority to set standards that other engineering teams have to follow, because the same person owns both lines of accountability.
The risk: if the VP of Engineering is overloaded with delivery commitments, the platform team can become deprioritised in favour of feature work. The fix is usually a strong director-level leader running the platform function, with explicit air cover from the VP.
Under a VP of Infrastructure or Head of Operations
This is the most common arrangement in organisations where the platform team grew out of an existing operations or infrastructure function. It is also where most under-performing platform teams sit.
When platform engineering reports to operations, three things tend to happen:
- The team’s mandate narrows to running infrastructure. Standardising deployment patterns or shaping how teams build software is not part of the operations remit, and the team has no authority to do it.
- The team’s incentives align with stability rather than enablement. Uptime, ticket throughput, and incident response become the dominant measures.
- The team is funded as operational cost. When the budget gets tight, the conversation is about reducing cost, not about increasing engineering capability.
The technical work may still be excellent. The strategic outcome is usually weaker than the investment justifies.
Under the CTO directly, as a peer to product engineering
This works in some organisations and fails in others. The key variable is whether the platform team has the authority to enforce standards on the product engineering function.
If the CTO has clearly delegated that authority, the arrangement works well. The platform team operates as a strategic function, with the CTO as a credible sponsor for decisions that affect other teams. The risk of dysfunction is low.
If the authority is ambiguous - if the platform team is technically equal to product engineering but politically required to negotiate every decision - the arrangement creates constant friction. Platform standards become recommendations. Exceptions accumulate. The team’s leverage slowly erodes.
This arrangement is more sensitive to executive style than the others. It works well under decisive CTOs and badly under consensus-oriented ones.
Under the CIO
This is more common in larger enterprises and almost always produces a difficult outcome.
The CIO’s mandate is typically enterprise IT, vendor management, and corporate systems. These are real and important functions, but they are not the same as enabling product engineering. When platform engineering sits under the CIO, it tends to be evaluated through procurement, risk, and compliance frames rather than engineering productivity frames.
The practical consequences:
- Vendor decisions take longer because they go through enterprise procurement rather than engineering evaluation.
- Standards are framed as policy compliance rather than engineering productivity.
- The team’s funding is competing with corporate IT spend, which is usually growing for unrelated reasons.
- The platform team’s relationship with product engineering becomes mediated through a leadership layer that does not own product outcomes.
Some organisations make this work, but it requires unusually strong executive coordination. The default outcome is that platform engineering becomes a slow, defensive function.
Signs the Reporting Line Is Wrong
You can usually tell within a quarter whether the reporting line is helping or hurting:
- The platform team cannot enforce standards across product engineering. Every decision is negotiated, and the team’s authority depends on the goodwill of individual engineering managers.
- The platform team’s budget conversations are about cost reduction, not investment. The framing is consistently defensive rather than capability-building.
- The platform team’s outcomes are evaluated against uptime and tickets, not engineering throughput. The metrics that get reported up are the operational ones, and the strategic ones get lost.
- Senior platform engineers leave for organisations with similar technology but different structures. This is a strong signal that the structure, not the work, is the problem.
- The platform team is in scope for decisions that shouldn’t involve them, and out of scope for ones that should. Both are symptoms of an unclear mandate.
If three of these are true, the reporting line is producing a meaningful drag on what the platform team can achieve.
What “Right” Looks Like
The right reporting line for platform engineering in most organisations has four properties:
- It puts the team under a leader whose mandate is engineering productivity, not infrastructure operations or enterprise IT.
- It funds the team out of an engineering capability budget rather than an operational one.
- It gives the team explicit authority to set standards that other engineering teams have to follow, with executive air cover for decisions that produce friction.
- It evaluates the team on outcomes the rest of engineering recognises as valuable: throughput, time-to-production, infrastructure consistency, on-call burden, and engineering retention.
The specific title of the leader matters less than these four properties. A platform team reporting to a Head of Engineering with these conditions met will outperform a platform team reporting to a CTO without them.
How to Change It
Restructuring a reporting line is harder than restructuring anything else in an engineering organisation, because it touches on cost ownership, executive accountability, and the political shape of the senior team. Most engineering leaders try other interventions first - hiring more people, restating the mandate, running offsites to align on priorities - because those feel safer.
In practice, those interventions rarely move the underlying outcomes. The structural problem keeps reasserting itself.
The conditions for changing a reporting line successfully are usually:
- A senior executive willing to sponsor the change, typically the CTO or a senior product engineering leader.
- A clear articulation of what the platform team will be funded to do under the new structure, in terms the affected functions can evaluate.
- A transition plan that addresses what the receiving function will and will not own going forward, since the change often involves moving accountability for things like security, compliance, or operations.
- An acknowledgement that some people will resist the change because it reduces their scope. This is normal; planning for it makes the change tractable.
The change is uncomfortable. It is also one of the highest-leverage interventions available to engineering leadership, because it changes the conditions under which every future decision about the platform will be made.
The Takeaway
The reporting line is not a detail. It is the structural decision that shapes what the platform team is funded for, what it is allowed to do, and how its work is evaluated. Three years in, it will have done more to determine the success of your platform investment than any of the technical decisions taken along the way.
If your platform team is technically strong and somehow under-delivering, the org chart is the first place to look. If your platform team is reporting to operations, infrastructure, or corporate IT, the reporting line is probably constraining the outcomes you can produce.
The fix is rarely procedural. It is structural.
If you are not sure whether your platform team is in the right place in your organisation, we can help you work that out.